Library stack organization and standalones
chipp at chipp.com
Wed Feb 4 02:14:38 CST 2004
I've got an app which has a bunch of other stacks (25 or so) and here's how
I 'architect' it:
1) Create a startup stack which is a splash screen. This splash screen has
only few purposes:
a) To be a repository for the engine
b) To check online (if a connection is available, else silent fail) for a
new version of itself. If a new version exists, then revGoURL the executable
and quit. Don't try and install over itself. Let IE or Netscape manage this
download as it's the MOST important download of all.
c) Download and manage the versioning of ONE other MAIN stack, not ALL the
d) Reset button to clear all other stacks and prefs file and start anew
(never know when you need it)
e) Manage proxy servers
Here's why this works so well:
Once you get the splash stack working correctly, the idea is you NEVER have
to update it, thus you never have to build another installer, etc.. This is
why the Splash stack downloads and checks the version of only 1 other
stack - the Main stack. That way you can extend your application with more
stacks and never have to worry about messing with the standalone.
The Main stack manages all of the other stacks and downloading them and
checking their version. Now, all you need to do is manage a versions.txt
file on your server, and each time you update/bug fix/feature enhance any of
your stacks, they're immediately available to your users (if they can get
Of course, the first time a user logs on, they'll need to be connected to
the Internet to download your (gzipped) stacks. I show a progress bar for
these downloads. It's easy with libURL.
Each stack has a fld "vers" visible. The Main stack checks the fld "vers"
and compares it to the version.txt it got from the internet to see if a new
one is available.
2) The Main stack has a openStack handler on card 1 (not the stack script)
which among other things does:
if there is a stack "libDar.rev" then
start using stack "libDar.rev"
goGet "libDar.rev" --> YOU DO THIS HANDLER
I typically have groups of stacks with each other. Some are separate and
others are substacks of the Main stack.
A standalone can have SubStacks. Stacks not in a standalone can have
substacks. If I were to create a libray for processing socket data, I might
have two substacks associated with it, one for logging all of the data, and
another a custom dialog. So the library would have a main stack and 2
substacks (just as you said).
One thing I'm careful of, is not downloading files to the Program Files
directory. Instead I use specialfolderpath(35)
You said, "That is, the dialog stack would have the associated library stack
after it in the message path in development, but in the standalone, the
application stack and other library stacks will be in between."
I'm not sure what you mean. By using the start using command, it effectively
inserts the script of the stack below the current stack script. Check out
Richard Gaskin's excellent article:
"Extending the Revolution Message Path"
Hope this helps,
More information about the use-livecode