Repairing the amnesia of standalones

[kresten]

Can I develop a launcher to enable my standalone to
a) accumulate usertext in textfields

b) remember script-supported substack user-preferences
script-supported substack button placements
script-supported substack new card creations
script-supported substack card labelling

The tutorial on how to save custom properties in standalones does not explain whether all this can be understood as custom properties.

[bogs]

Yes you can do that, in a couple of ways.

Create the launcher as the lesson says, and use that to launch your 'working' stack.

Code: Select all

   // launch the main application stack, then close this launcher...
    open stack "myStack.livecode" // put the name of the working stack
    close stack "launchMyStack"    // "hide" works as well...

If you want the working stack to save everything as it is when it was closed, put something like the following

Code: Select all

on closeStack
 // saves the entire stack with all settings as they were left
     save this stack
     pass closeStack
end closeStack

If you need something changed on reopening the stack, make sure you put those specific changes in either the preOpen or open handlers of the working stack.

Code: Select all

[myStack.livecode]
// can also do this more generically in the openStack method if multiple cards need changes...
on openCard 
     put "" into field "thisFieldShouldBeCleared"
     set the textColor of label "cardOpened" to "red"
end openCard

[kresten]

Thank you for giving me hope
Do you expect that this will work for my LC 6.7.8 version ?
I would be grateful if you would repeat the scripting including the second option, and without its //comments.
Best regards
Kresten

[kresten]

Thank you for giving me hope
Do you expect that this will work for my LC 6.7.8 version ?
I would be grateful if you would repeat the scripting including the second option, and without its //comments.
Best regards
Kresten

[bogs]

Well, I use Lc 6.5.2, and tested down to 6.0.1, I expect it will work with 6.7.8 (and pretty much any other version)

Not really sure what you mean by the 2nd option without the comments, since you could easily do that yourself, but I hope this is what you were asking for.

Code: Select all

[ launcher standalone stack ]
on openStack
    open stack "myStack.livecode"
    hide this stack
end openStack

Code: Select all

[ working stack ]
on closeStack
     save this stack
     pass closeStack
end closeStack

[kresten]

Dear Bogs
Thank you for your efforts, but I am coming to understand, that the launcher can only help in relation to a mainstack in livecode, not repairing the amnesia of a mainstack standalone, (which is what I meant with the title of this topic).This seems to imply, that any potential user of my mainstack will have to install livecode and download alle the ressources/special folders. (As my mainstack has no problems in saving custom properties the launcher is useless)
How sad !

best regards
kresten

[FourthWorld]

I am coming to understand, that the launcher can only help in relation to a mainstack in livecode, not repairing the amnesia of a mainstack standalone, (which is what I meant with the title of this topic).This seems to imply, that any potential user of my mainstack will have to install livecode and download alle the ressources/special folders. (As my mainstack has no problems in saving custom properties the launcher is useless)
How sad !

I don't know how you arrived at that conclusion from the content in this thread. Perhaps there are additional details about what you want to accomplish which would help us understand why the IDE is required for your app's deployment.

The "amnesia" you speak of is a feature of all modern OSes. Not since Mac Classic, with its bifurcated file system, have apps had both executable code and savable data in a single file. Pretty much all apps on all modern OSes save their data externally from the executable that works on the data. Whether made with LiveCode, C++, or just about anything else, data can be written to and read from files separate from the executable.

One of the file types LiveCode is uniquely good at reading and writing are stack files. A stack file contains one mainstack, and may also contain any number of substacks within it.

A LiveCode standalone is an executable produced by combining the LiveCode runtime engine with a stack file. Such a standalone, like any executable, is prevented from saving changes to itself.

Any non-standalone LiveCode stack file can be opened and saved by any LiveCode standalone containing scripts to do that. The "open" and "go" commands can open stack files, and the "save" command can save changes made to them.

Any features you see in the IDE (making/adjusting buttons, cards, etc.) are accomplished in the IDE using the same scripting language available in the runtime engine. Given the IDE's complexity it's usually easier to write one's own tools for an app that needs capabilities similar to the IDE, rather than attempting to copy code from the IDE, with all its interdependencies. But the scripts needed to work with LC objects are usually not too difficult depending on what you want to do, and of course if you have questions about any specific task the good folks here can help.

I hope this review of the relationship between applications and documents (in this case, stack files) is useful. If not, please ask any questions you may have so we can help you get your app up and running as well as the many others that use LiveCode stack files as documents.

[bogs]

Richard puts it correctly, no standalone can save information that changed to itself, if that was your original question, then I certainly missed it all the way down the line.

However, the method I gave you does as Richard points out give you the work around without having to have your end user download the IDE to run the stacks, while allowing you to 'save' everything to your applications working stack. Don't let the terminology throw you off, even though the 'working' stack is a sub stack of the main launcher stack, in examples like these it is for all intents and purposes the 'main' stack of your program, i.e. your end users are only going to interact with that stack (and / or subsequent substacks triggered from the working stack).

I'd suggest reading through this lesson to better understand the nature of what I proposed, then complete the lesson to see how it all works together.

A second side benefit of this is that the programs you send out will often be smaller to package and distribute, as the standalone is about as small as it can be made, and the 'working' stacks weigh in in the 10's of kb's. As a simple example, you could create a custom launcher stack for your applications, which your end user would have in a folder either created by you or them.

As you write new stacks, or update older stacks, you would just send them the stack itself, easily and quickly, since they would already have your 'launcher' which as a standalone probably will exceed the size of any 'working' stack you come up with, at least initially. One of my 'working' stacks, with 5 images contained inside it, is under 300 kbs.

It also appears to me (although I could be WAY off here) to be the method the IDE itself works under, although obviously a bit more complicated in practice.

Hope that helps you out a bit more.

[jacque]

Don't let the terminology throw you off, even though the 'working' stack is a sub stack of the main launcher stack

Be careful with the terminology here, a substack of the app"s mainstack will not save. Substacks are part of the same file on disk as their mainstack. I think what you mean is a separate mainstack that is included with the distribution.

It's very common for new users to refer to any file in the distribution as a substack but that will cause confusion later when they start using real substacks.

[bogs]

It is very common, I did (and still make those mistakes occasionally, like above, thank you for the correction ) at times.

Jacque rightly pointed out the flaw in my post, with the 'splash' stack technique, your going to have the "main stack" that is your launcher for the "main stack" (and any substacks) of your 'working' stack. In the picture below, the launcher is the only stack that will be made a standalone and its only job is to start up the 'working' stack which is saved as just a plain old stack file, not as a standalone.



Hopefully despite my earlier gaff, it is a little clearer what I meant

[kresten]

Many thanks to both Richard and Bogs.
I had myself reached a kind of solution, that it should be possible to build a standalone, which could download and install the LC application from the livecode site & a compressed version of my mainstack.livecode with its resources from my homepage.
I need to understand, whether the use of a launcher would make the first step of this superfluous ?
Best regards from
kresten

[bogs]

If you use a launcher, you would not need to download the full IDE to run a stack.

[kresten]

So nice, but how can I test reliably on my own computer with its installed LC ?

[bogs]

Well, since you ask that question I will assume you don't have another computer you can just email it to. If that is the case, I'd suggest installing a virtual machine (both virtualbox and vmware player are free downloads for all desktop Os), and open it in the vm that doesn't have Lc installed

[jacque]

So nice, but how can I test reliably on my own computer with its installed LC ?

Just build the standalone and run it. A standalone is an independent app that LC won't see. The way it works on your computer is how it will work on anyone's computer (on the same OS).