path of a 'closeStackRequest'

[Dave Cragg]

At 1:51 pm +0000 16/1/03, Graham Samuel wrote:

>In the absence of a path-tracing feature in the debugger, I
>therefore put this handler into my mainstack:
>
>on closeStackRequest
>   answer (the short name of the target)&&"is trying to close the Anchor stack"
>   pass closeStackRequest
>end closeStackRequest
>
>and went back to testing. I found that when I closed a substack by
>clicking on its close box, the handler in the mainstack got called,
>with the target being the first card of the substack. There is no
>stack script in the substack. What's going on? It looks as if the
>'closeStackRequest' for the substack has got into the message path
>for the mainstack and is being applied to the mainstack, but why? If
>I want to allow closing of some substacks, either by scripting or by
>my user without affecting the mainstack, what do I do?

Messages not handled in a substack will pass to the stack script of 
the mainstack. While it can be annoying when you forget about it, it 
allows you to put a lot of common application handlers in the 
mainstack script. So I think it counts as a useful feature.

Here are two possible ways to avoid unhandled messages getting passed 
to the mainstack.

1.  In the stack script of the substack, include "empty" handlers for 
messages you don't want to pass or handle.

For example:

on closeStackRequest
end closeStackRequest

on closeStack
end closeStack

and so on

2.  In the handler in the mainstack, check the target before handling 
the message. Something like:

on closeStackRequest
  if not matchText(the long name of the owner of the target, "of 
stack.+of stack") then
   ##not from a substack so do stuff
  end if
end closeStackRequest

The regular expression checks for "of stack" occurring more than once 
in the long name of the owner. This will only match if the target was 
in a substack.

Cheers
Dave