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