Best Way to do Multiple Instances of a Stack

Richard Gaskin ambassador at fourthworld.com
Tue Sep 16 17:57:00 EDT 2003


Brian K. Maher wrote:

> I have the need for my end users to be able to see multiple instances
> of a given window (substack) where each window would have a different
> title/label and would display different data from a database.  What is
> the best way to accomplish this?  Specifically ... if you use the clone
> command what is the best way to "initialize" the clone?

Here's my strategy:

I have a template window as a substack, and clone it whenever a new document
is created or opened, setting the stack name to something like "p"&the
millisecs to make it unique, and set the stack's title to something
descriptive (the file name or whatever else makes sense in your context).

After setting it's name and title, I set a custom property to the full path
of the file whose data is displayed in that window.  If you're not
displaying data from a file you could use custom props to store anything
else that would be relevant for your app.

One nice thing about this approach of using your own reference to a file is
that it lets you distinguish betweeen new and opened documents:  a new
document as an empty value in its uDataFile property.  Then you can respond
appropriately when a Save is issued, calling your app's Save As first in
order to assign it a file like most apps do.

I maintain a uDirty property for each document window, setting it to true
when any action is performd that will require saving later.  On save I clear
the uDirty property and do whatever I need to collect data from the window
and write it to disk.

Keep in mind that you're not limited to text files for data storge.  If your
data is structured you may find it helpful to use a stack file instead of a
text file for storage, tucking data away neatly in custom props.  (For more
on that see: 
<http://lists.runrev.com/pipermail/use-revolution/2002-July/006141.html>)

Whenever a stack gets a closeStackRequest message it checks the uDirty
property and prompts for a save if needed.

While this may seem like an few extra steps, I've found it's a decent way to
handle document behaviors in a HIG-compliant way while maintaining  complete
separation of the data from the  UI it's displayed in.  If I want to change
anything about how the data is displayed I just release a new version of the
app and all documents are shown in clones of the template substack.   A lot
of us HyperCard and SuperCard users used to keep data and UI in the same
stack, which seems simpler in some respects but can be hell when upgrading
your app.  There are reasons traditional programs maintain a separation
between UI and data. ;)

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge: Publish any database on any Web site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc




More information about the use-livecode mailing list