At 11:23 AM +1100 10/9/2016, Monte Goulding wrote:
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.
Hmm. I actually would have expected stack C to still be the
defaultStack on returning to stack A. defaultStack is a global
property, theoretically.
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.
Not sure how that makes it impossible to set it to the topStack...?
(Although I agree with Jacque that there's code out there that relies
on the current behavior, possibly without the writer even really
being aware of it.)
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
