On 2016-10-09 07:19, J. Landman Gay wrote:
On October 8, 2016 7:06:15 PM Monte Goulding <mo...@appisle.net> wrote:

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

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.

Warmest Regards,


Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to