LiveCode Forums.

This is originally from a thread in the 'Feature requests' forum.

http://forums.runrev.com/viewtopic.php?f=6&t=17017

Ok starting to play with the standaloneSaved command

The dictionary has this:

Syntax:
standaloneSaved folderSavedIn

Parameters:
folderSavedIn is a string variable containing the folder that the standalone application was saved in.

Example app is named "CodeSave"
However if you saved the standalone in C:\MyApps\Test then folderSavedIn would report C:\MyApps\Test which is incorrect. It should be C:\MyApps\Test\CodeSave with subsequent stanalone saves should be C:\MyApps\Test\CodeSave1 , C:\MyApps\Test\CodeSave2 etc

Is this a bug or am I understanding this the wrong way?

Errr.. not sure what your point is Andy?
Are you arguing the language in the dictionary?
If so, how would you write it?

Or, would you like to know how to get what you would like?
That's easy.

Simon

Hi Simon,

Thanks for you response.

I think both..

If I use the standaloneSaved folderSavedIn command should that not return the exact destination for the standalone?

and yes I would like to know how to do this

The folder path makes more sense when you consider that it's possible to build multiple apps for different operating systems at the same time, which is commonly done for desktop apps. The "folderSavedIn" is the enclosing folder that will contain all your builds. Since each build can have several files, particularly on Windows and Linux which don't use app bundles, the standalone builder creates an enclosing folder for each OS. The destination folder that is returned in the parameter is the folder that will hold all the created subfolders.

Jacque, I think what he's looking for is somewhere between the two. If the path given was into the OS X bundle, that would be too deep, but as it is it's only going into the folder selected as the destination, yet the standalone builder will create a new folder inside that one and we can't know in advance what the name of that folder will be unless we manually open the folder to see what other build folders are already there.

For example, if you have a destination folder of /mydrive/dest/, the app will actually be built in /mydrive/dest/appname. A second build will be put into /mydrive/dest/appname1, but if you've deleted the first build folder then the third will go into /mydrive/dest/appname again, with a fourth going into /mydrive/dest/appname2.

I agree with the OP that it would be far more useful to know the actual folder the SB will create into which it will place a specific build. After all, that's the one thing we can't easily know ourselves.

The trick now is backward compatibility: is anyone actually relying on the current info given, or could it be safely changed into the more useful form suggested?

Hi Jacqueline & Richard,

Thank you both for your input on this. I'm running Win XP and Win7.

The reason for wanting to have the actual location for the generated standalone was that I was looking for a way to be able to place a copy of the source code along with the generated app via a simple plugin.
When I saw the 'standaloneSaved folderSavedIn' command my eyes lit up and thought how easy this was going to be, but the results were not as I expected with my interpretation of the dictionary explanation.

So to recap.

1. How can I accomplish this without having to result to using vbscript or cmd?
2. Is a request for this feature to be a standard LC command valid?

Many Thanks.

AndyP wrote:1. How can I accomplish this without having to result to using vbscript or cmd?

You could do it in LiveCode: dig into the standalone builder to find how it names the folder it creates, and use that in your code. Even better, you could alter your copy of LC's standalone builder to give you that foldername when it sends the build messages.

2. Is a request for this feature to be a standard LC command valid?

I think so. Some may feel that for backward compatibility this should be implemented as a separate function, but the IDE knows where's it's building the app so adding a function so we can know it too shouldn't be that hard once the tedious part of tracing through the code to find the right part has been done.