Closing a substack

[Ken Ray]

On 5/29/08 11:03 PM, "Charles Szasz" <cszasz at mac.com> wrote:

> 
> I have two stacks. One is the initial stack that launches the main stack,
> which is the application. I am using a substack of the main stack as a
> dialog box. In this dialog box, the user selects an option and then closes
> the dialog. Here is my problem: when the substack is closed it also closes
> or quits the main stack. I used the script: close this stack
> 
> Any suggestions?

I'm sure what's going on is that the main stack has an "on closeStack"
handler in it stack script that quits the main stack. When you close the
substack, the "closeStack" message gets sent to the substack and then
travels through to the main stack where it is trapped.

The solution is one of the following:

1) Move the main stack's "on closeStack" handler to the card script instead
of the stack script of the main stack (if it is appropriate to your
deployment). Since open/close/etc. messages are first sent to the *card*
this will allow the main stack to get the closeStack message it needs, but
also allow the substack's closeStack message to zip right past it and not
get trapped by the main stack.

2) Change the "on closeStack" handler of the main stack to include a line
like:

  on closeStack
    if the owner of the target is me then
      quit
    else
      pass closeStack
    end if
  end closeStack

This will evaluate who originally got the message; if it was the main
stack's card, then the "owner of the target" would be the main stack itself,
and it would quit. If, on the other hand, it was the *substack's* card, then
the "owner of the target" would be the substack, and so it would pass the
closeStack message and not quit.

3) In your substack, put the following handler in either the card or stack
script:

on closeStack
end closeStack

This will trap the message and prevent if from being passed, but at the same
time won't prevent the substack from closing.

On the other hand, I could be completely wrong about why your stacks are
quitting, but this is a situation I've seen many times, and it usually boils
down to the above.

HTH,

Ken Ray
Sons of Thunder Software, Inc.
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/