Saving Data in Standalones

Mark Wieder mwieder at ahsoftware.net
Sun Jun 6 22:41:36 CDT 2010


Pete-

Sunday, June 6, 2010, 2:53:37 PM, you wrote:

> Help!

You covered a lot of issues there. I see Mark S. has addressed one of
them already. Here's some more.

One of these is easy: if you want to prevent a rev script from being
loaded, poked into, and modified then set a password on the stack
before distributing it. I don't recommend doing this during normal
development work because it's a PITA to have to enter a password every
time you want to look at a script. But doing that before sending it
out into the world will keep it from prying eyes.

You can't save a running application. This isn't a limitation of rev,
but of the OS. There's no modern OS that will let you modify a running
app. I realize you've internalized that already, so here are some
ramifications of that concept: you can modify global and local
variables and save custom properties all you want, but you can't save
them to disk because they're part of your application; if your app is
resizeable you can resize it but the changes aren't sticky - the next
time you launch it will be the same size as the previous launch.

If you want to make changes that are persistent for the next launch of
the app you have some options. You can save the preferences to a text
file and read them back in at launch time. This is easy to do
(remember to save the file somewhere you have write permissions for)
and allows for editing the preferences file with a text editor outside
the IDE if the need arises. You could also save the preferences in any
other format you wanted (xml, xls, etc): it's just a file. For Windows
and OSX systems you can use specialFolderPath("Preferences") to find a
safe place to store preferences.

You can save custom properties in a substack *as long as that substack
is a separate file from your mainstack*. This gets around the OS
limitation of modifying the running application because you're not;
you're modifying a different file. If your substack is part of your
mainstack and not a separate file then your changes won't be
permanent.

I use both of these approaches (saving a prefs text file and saving a
prefs stack) in different situations. As far as I know, there's no
Best Practices pattern for one over the other.

You *can* tell the standalone builder to make the substacks separate
files in the build phase. This will get around the problem sometimes.
You do have to remember to load the substack into memory in order to
have access to it.

And that's why I don't recommend that approach.

A better approach would be to have the substacks separate files to
begin with - in that case the way you use substacks during development
is the same as the way you use them in your standalone. You don't have
the situation of a stack/substack system working fine in the IDE and
then failing in a standalone because you haven't loaded the substacks
properly. I do think it's a good idea to try to avoid surprises when
you deploy a standalone application, and having a stack in the IDE
behave like a stack in a standalone is one way to stay out of trouble.

-- 
-Mark Wieder
 mwieder at ahsoftware.net




More information about the use-livecode mailing list