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 | [email protected] HyperActive Software | http://www.hyperactivesw.com _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
