Advertising

I can’t help thinking that go touching the defaultStack at all is bug
or rather a bad idea in the first place that probably can’t be changed
now. Just because you opened a stack does not necessarily mean you
want to target the rest of your script to the stack you opened.

Rather than a bug or an anomaly it *could* be considered part of the
semantics of the 'go' command (whether it *should* or not, is another
matter ;))... Which has different behavior from 'toplevel', 'modeless'
etc. commands. If you do:

toplevel stack "Foo"
Then the defaultStack *does not change*. If you do:
go stack "Foo"
Then the defaultStack *does change*.

Actually that's been the whole xtalk metaphor forever and you're right
that changing it would break a lot of stacks. When you go to a stack,
it becomes "this stack", and you are on "this card" and you expect
your script to act on the controls there. It dates back to HC where
there was only a single stack open at any time and no confusion was
possible. With the introduction of multiple windows, the behavior
stayed the same and if you want to address objects in the original
stack, you need to use long object references or set the defaultstack
yourself.

I suspect that the behavior of the defaultStack could be refined to be
more 'predictable' without breaking too much - as you say, I doubt the
semantics of 'go' could be changed. However, all that means is that we
need to make sure there is a way to open secondary stacks without the
defaultStack changing semantics. I *think* the current 'subwindow'
commands (mentioned above) are probably it - but there is still
potential for refinement.