Noob Stacks Questions

[J. Landman Gay]

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.

<http://www.runrev.com/developers/lessons-and-tutorials/tutorials/online-scripting-conferences/>


> 
> 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
> one?

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 
try it.)

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 
standalone.

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