Understanding 'the defaultStack'

Monte Goulding monte at appisle.net
Sat Oct 8 20:23:55 EDT 2016


> On 9 Oct 2016, at 10:51 AM, Jeanne A. E. DeVoto <revolution at jaedworks.com> wrote:
> 
> OK, thar seems like a bug to me. If the only stacks open are palettes, for example, then go should make the target stack the topStack (and hence the defaultStack, since no stacks of lower mode are open).

Thinking on this some more I don’t think you can do what you are suggesting here. Go currently sets the defaultStack to the target stack if it is topLevel. If it set the defaultStack to the topStack it would depend on the current state of the environment whether the defaultStack is the stack being opened by go after the command while at the moment it just depends on the mode of the stack being opened.

Indeed let’s say you have stack A that opens stack B and stack B that opens stack C in its preOpenCard handler. At the moment:

stack A - is defaultStack in its own script
go stack B
  stack B preOpenStack - stack B now defaultStack in its own script
  go stack C
     stack C preOpenStack - stack C no defaultStack in its own script
  stack B preOpenStack continues but stack C is now the defaultStack
back to stack A script and now stack B is the defaultStack

But if you change it to set to the topStack then when you go back to the stack A script then stack C will be the defaultStack.

Cheers

Monte


More information about the use-livecode mailing list