Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook



The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic

Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.

If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.

Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.

Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Convert library to filesystem dictionary

  • Filter
  • Time
  • Show
Clear All
new posts

  • Convert library to filesystem dictionary

    This is an option on the right click menu of the Code Page of the desktop control panel.

    Can someone point me to the documentation for it?


    -- tom

  • #2
    Re: Convert library to filesystem dictionary


    • #3
      Re: Convert library to filesystem dictionary

      Let us know what actually happens when you try this!

      Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford


      • #4
        Re: Convert library to filesystem dictionary

        Thanks, Craig.

        I'm a bit confused about this feature. Haven't used it myself. If time permits I'll look into it this week.


        • #5
          Re: Convert library to filesystem dictionary

          I just tried this on a new db created for the purpose.
          It created a sub folder with 2 folders in it. atester.A5lib with resources and scripts as subs
          I looked at the one for scripts and got this.

          'Date Created: 08-Feb-2015 11:00:05 PM
          'Last Updated: 08-Feb-2015 11:00:05 PM
          'Created By : dave
          'Updated By : dave
          'Date Created: 08-Feb-2015 10:59:06 PM
          'Last Updated: 08-Feb-2015 10:59:06 PM
          'Created By : dave
          'Updated By : dave
          'this does nothing
          'this still does nothing

          resources contained:
          A5BLOBST   0 @    L      CA C contents_c contents_m vendor

          I only have one script with the line ' this does nothing
          did the filesystem dictionary
          went back and added line ' Thjis still does nothing
          Both lines then showed up.

          Not real sure why I might need this whole thing for a pure desktop app, but it seems to work as far as I have checked.
          These files were renamed like below:
          adb was not touched
          Dave Mason
          [email protected]
          Skype is dave.mason46


          • #6
            Re: Convert library to filesystem dictionary

            another note:
            There does not appear to be an honest way back from this. Make super sure you have a strong backup before you try it. The script comes up empty if the new folder is deleted and the files are renamed back the way they were.

            For me, This is one of those things that is off limits. I don't need it.
            Dave Mason
            [email protected]
            Skype is dave.mason46


            • #7
              Re: Convert library to filesystem dictionary


              In short, it seems to be a fast way to export scripts, UDF's, and toolbars to text files for the purpose of updating clients.

              As it removes passwords, and un-encrypts to raw text, I see no value over the traditional method of overwriting the ADB , ALM, ALX, etc.

              While I appreciate the effort Alpha put into this, I see no value in my world for this feature.

              Now, anyone reading this that does not know about Alpha's Encryption and creating an AEX file, that's a big hit with me. Protecting data and scripts is the wave we all need to address.

              Anyone who better understands the reason to convert a library to a filesystem directory, I am open to a change of mindset!

              Either way, I love Alpha Software.


              • #8
                Re: Convert library to filesystem dictionary


                According to the wiki (see your link above), Alpha intend this to be used with an external version management system during development and for ongoing fixes and upgrades.


                Return back to embedded code/resources is performed by reversing the original process. You need to have the current components in the *A5lib directory and the *.old_al* files in the root directory of your project. I had to work this out having discovered yesterday that I'd somehow run a conversion on Christmas day!


                • #9
                  Re: Convert library to filesystem dictionary


                  Yes, I knew that. I still see no benefits...

                  If you know of benefits, please explain.


                  • #10
                    Re: Convert library to filesystem dictionary


                    This is the first example I found to list benefits of using a version control system:

                    As a single user the main advantages are

                    Automatic backups: If you accidentally delete some file (or part of a file) you can undelete it. If you change something and want to undo it, the VCS can do so.
                    Sharing on multiple computers: VCSes are designed to help multiple people collaboratively edit text files. This makes sharing between multiple computers (say your desktop and laptop) particularly easy. You do not need to bother if you always copied the newest version; the VCS will do that for you. Even if you are offline and change files on both computers, the VCS will merge the changes intelligently once you are online.
                    Version control and branching: Say you published some class notes as a pdf and want to fix some typos in them while simultaneously working on the notes for next year. No problem. And you only need to fix the typos once, the VCS will merge them to the other versions.
                    I'm sure there are thousands of other examples and dozens of other reasons.

                    IMO one of the main problems when coding in AA is that you can't easily revert to an earlier version of a script or UDF. Forms, reports, letters etc. all have a history, but not scripts and functions. One solution to this issue is to use a VCS to manage your coding changes.


                    • #11
                      Re: Convert library to filesystem dictionary


                      I understand what a version control system is. I've been writing code since '82 - I'm getting old ;)

                      Here's my puzzlement with regard to the topic at hand.

                      1) Writing code OUTSIDE Alpha's code editor seems like an open invitation for syntax errors. It would be like writing in Notepad, yes? Since there is no XBasic aware VCS software out there, wouldn't multiple developers be forced to copy and paste as they write in Alpha, then log newer code into the VCS?

                      2) All this does is export and import a single copy of the scripts and UDF's. All of them in one shot.

                      In other words, a good way for multiple developers to collaborate would better be built WITHIN Alpha.

                      Let's look at the Import / Export on the same code tab right click.

                      1) If the export was automated to a directory of choice each time a change was made, you would have backups of each script change that could be imported to restore. (This would be similar to restoring a form to an earlier version, already available)

                      That would cover your backing up concern, too.

                      It would also allow a developer to select the version he wants to write on top of, on the assumption he is working on a freelance copy of the application. He could then export to the same community folder where others can pick up where he left off.

                      Keep in mind that two developers can never work on the same script at the same time, so parts are delved out to individuals, then they are merged when the components are completed.

                      (An simple example would be one guy writes the script, other guys write the functions used in the script - with both parties determining the arguments and results of the function before it is written.)

                      I hope this explains what I, perhaps singularly, see as a better solution. I see no value in the VCS idea, as using a generic one would be little better than writing XBasic in notepad, right?

                      If the programmers at Alpha really wanted to offer a solid solution, they could, fairly easily. They just need to allow the user to create a source folder in a place of choice in 'settings', and include the developers name in the name of the TXT file it creates. Also, the time and version number to the name of the file.

                      Again, please see import/export.

                      At any rate, I have no need, yet, for this functionality, but hope to soon. And I suspect no one is using what is there to any great success. And I doubt there will be any attempt by Alpha to address the shortcomings, so this is pretty much a dead topic.
                      Last edited by CraigSchumacker; 02-10-2015, 07:11 AM.


                      • #12
                        Re: Convert library to filesystem dictionary

                        As with most of Alpha's genie's there is an Xbasic function that can perform the same action and so it is with the export/ import of scripts and functions. How hard would it be to wrap these functions in your own code to select which scripts/ udfs you want to have back up copies of and where you want them? You could even automate these backups for all the scripts to occur in an event like the Autoexec or OnDatabaseClose while working in the development copy.

                        Discernment is not needed in things that differ, but in those things that appear to be the same. - Miles Sanford


                        • #13
                          Re: Convert library to filesystem dictionary


                          I wasn't trying to be awkward or funny - I genuinely believed you had got the wrong end of the stick when reading post #7 when you looked at the functionality as being of use for updating client systems. I too have no use for this functionality, but as I had implemented it by mistake(!) I thought I'd add my thoughts to the thread.

                          In response to your post #11...

                          1) I've no idea why anybody would want to normally code outside of Alpha, but someone must have seen a benefit or the option wouldn't exist.
                          2) No, it doesn't do an import/export, it converts all your scripts, UDFs menus and toolbars etc. to text files which can then be edited either within or outside of Alpha (at least I hope that's the case or I've lost 6 weeks work)

                          I like Robin's suggestion of using the export_scripts_and_udf() function for creating regular backups of code - I'll be implementing this on my developments in the next couple of days - as this should ensure I have at least a daily backup of any script changes.

                          What I'd really like is a combination of the 'convert to filesystem' which creates a separate file for each script and UDF and the 'export_scripts_and_udf()' function which creates a date-stamped single text file with all scripts and UDFs concatenated.


                          • #14
                            Re: Convert library to filesystem dictionary


                            You sound like you think I'm upset? I am not, rest assured!

                            I think what I would prefer over Robin's suggestion of 'export_scripts_and_udf()' would be a on_save event for whenever a script/function is saved.

                            Or even better if Alpha Anywhere saved each automatically to it's own labeled txt file.

                            Good luck with your backups. I hope it saves the day one day for you (I mean that in a nice way!).


                            • #15
                              Re: Convert library to filesystem dictionary

                              Once you have used this, any changes in a script are auto saved to the place you had alpha put the older.

                              Delete that folder and change the renamed files back and you will have nothing.

                              Before you make assumptions:
                              create a workspace in a new folder, add 2 tables with some data, then 2 forms with scripts of some kind, then 2 reports with scripts of some sort, then 2 scripts and 2 functions.
                              Now run the export and try to figure out how to get everything back to normal(reverse the procedure).
                              I went as far as I needed to find out how unimportant this is to me. That does not mean that is could not be useful to someone else.
                              Dave Mason
                              [email protected]
                              Skype is dave.mason46