Noob Stacks Questions
J. Landman Gay
jacque at hyperactivesw.com
Wed Feb 10 17:54:05 CST 2010
Andrew Kluthe wrote:
> Thank you for all of the useful info. Truth be told, I didn't really
> understand the full extent of stacks in rev.
Have you seen the scripting conference stacks yet? The first one in
particular does a good job of explaining what a stack and substacks are,
as well as other basic objects and properties.
> 1. In order to include a stack from someone else in my application, sarah's
> calendar for instance, I need to use:
> start using stack "whateverStack" ?
> So I should do this for all my substacks in my preOpenStack for the main
A stack can be very loosely associated with the concept of a "window".
For simple applications you may only need one stack, which will be all
that is in its file on disk. More complex programs usually need more
than one window or stack. For convenience, you can store additional
stacks into the same file on disk. You can only have a single "main"
stack, but it can contain any number of additional "substacks". You do
not need to start using substacks. They are always loaded into RAM along
with the main stack when it opens, and are always available.
The advantage to using substacks is that they are always there and all
you need to do is "go" to one to view it. You can use its short name to
refer to it because it is always in RAM and the engine knows where it
is. Substacks also have the advantage of keeping everything together in
one file so nothing can get lost or separated.
One disadvantage to using substacks is if you've built a standalone and
you need to save data to them. No modern OS allows a running standalone
to alter itself on disk. If you build your main stack into a standalone
it cannot save any changes to itself, and that includes changes to any
substacks it contains. So if you need to save changes to a stack, it
needs to be an independent file that is not part of the standalone. It
has to remain a Rev stack.
A common approach is to create a very simple one-card stack -- often a
splash screen -- and then have that one-card main stack open other Rev
stacks. Since stacks are just files, they can save data without any trouble.
Stacks that are independent files on disk will need to be referenced in
scripts by a file path if you want to open them, since the engine won't
know where they are. You can do this lots of ways: calculate a logical
file path in a script, assign stack names to the stackfiles property of
your app, set the defaultfolder and use relative path references, or put
up a file dialog so the user can choose it. When you get that far, ask. :)
Sometimes you may want to use the script of a stack that is an
independent file on disk (i.e., it isn't your main stack or any of its
substacks.) That's when "start using" comes into play. Any stack you
start using is inserted into the message hierarchy so that its stack
script is available to all open stacks. This is how libraries are done.
An alternate to "start using" is to "insert script of <object>", which
allows you to place any script of any object into the message hierarchy.
"Start using" only allows placing the stack script into the back of the
hierarchy. Insertion allows you to place a script in either the front or
the back. (Newbie alert: be cautious when placing scripts into the
front. You can interfere with the IDE if you do that. Wait a while to
When you build a standalone, the mainstack script is always available to
any other stack that's open; i.e., it's always in use automatically.
When you are working with it in the IDE, that isn't true. So during
development, you may need to "start using" your main stack to
artificially put it into the message hierarchy, just to simulate what
will happen when it later becomes an application. You will catch bugs
that way too if you have any script conflicts.
So at this point you should make some decisions about your stack
structure. Which stacks need to save data and which don't? If you have
some static stacks that rarely change then maybe they should be built as
substacks of your mainstack. The calendar stack comes to mind here; it
is unlikely you'll need to change it, it does a single job and is fully
functional. So it's a good candidate for a substack in your main stack.
If you will be loading data into a single card on demand, then maybe you
don't need that stack to be separate either, since it is only a
template, and it could be a substack of the main stack too. On the other
hand, if you think you'll need to change it later on, it's easier to
change an independent stack because then you don't have to rebuild the
Stuff like that should be decided early on. But as others have said, it
is very easy to make a stack into a substack at any time. You can do it
in the to-be-substack's property inspector by just choosing a mainstack
from a popup menu.
> One more very general question that I could not find answered easily in the
> user guide.
> 2. Can global variables be used between all the stacks in the application?
I think this one got answered already, but yes, globals are everywhere.
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the use-livecode