Destroying cloned stacks
J. Landman Gay
jacque at hyperactivesw.com
Sun Feb 21 23:11:10 EST 2010
Jeffrey Massung wrote:
> Main Stack:
> on newDocument
> clone stack "Document"
> ## setup document stack here...
> go to it
> end newDocument
> Document stack:
> on closeStack
> destroy this stack
> end closeStack
I didn't even know that syntax worked. Apparently it works pretty well.
Anyway, what it looks like you've hit is the defaultstack issue. If your
main stack happens to be the defaultstack when the handler runs, "this"
stack is going to refer to your mainstack.
> So, my questions:
> 1. Am I going about creating a document stack the right way?
Yes. Though I usually set up all the common properties, like
destroystack, in the template before I save it into the main stackfile;
that way I don't have to worry about it, all clones will have those
properties. If you do that, all you'd have to do is trap
closeStackRequest for any cleanup work when the user clicks the close
box. The stack would not stay in RAM when allowed to close.
> 2. How can I nuke clones and not the primary document stack?
I sometimes name my clones with an identifying tag, like "clone 1",
"clone 2", etc. and then set the stack's label (also called "title") to
whatever the user should see as the window title. It makes testing for
the right stack easier.
The IDE uses this a lot to force commands to act on the right stack:
set the defaultstack to the topstack
Which will only work in this case if your clones really are the top
stack. Or you can test for a custom name tag to see if you're in the
if the short name of this stack contains "clone" then...
Or test the inverse:
if the short name of this stack is not "myMainstack" then...
Perhaps easiest, if your closestack handler is in the stack script, then
the term "me" will refer to that stack. So in your clones, you could
set the destroystack of me to true
In no case would "me" ever be your main stack, because "me" is the
object containing the running handler. Using "me" can sometimes be the
simplest solution, provided it's feasible to put your handler in the
stack script. Sometimes that can cause interference in other ways, but
we won't go there today. You've been through enough.
BTW, there is an auto-save utility in Rev's plugins menu. Just tell it
how often to save, and leave it open.
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
More information about the Use-livecode