Convert library to filesystem dictionary

[Tom Cone Jr]

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?

Thanks.

-- tom

[CraigSchumacker]

Re: Convert library to filesystem dictionary

http://wiki.alphasoftware.com/~alpha...on+Control+V11

[MoGrace]

Re: Convert library to filesystem dictionary

Let us know what actually happens when you try this!

[Tom Cone Jr]

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.

[DaveM]

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:
ATESTER.old_alb
ATESTER.old_alm
ATESTER.old_alx
adb was not touched

[DaveM]

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.

[CraigSchumacker]

Re: Convert library to filesystem dictionary

Tom:

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.

[WokingJon]

Re: Convert library to filesystem dictionary

Craig,

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.

Dave,

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!

[CraigSchumacker]

Re: Convert library to filesystem dictionary

Jon:

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

If you know of benefits, please explain.

[WokingJon]

Re: Convert library to filesystem dictionary

Craig,

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.

[CraigSchumacker]

Re: Convert library to filesystem dictionary

Jon:

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.

[MoGrace]

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.

[WokingJon]

Re: Convert library to filesystem dictionary

Craig,

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.

[CraigSchumacker]

Re: Convert library to filesystem dictionary

Jon:

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!).

[DaveM]

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.