Understanding 'the defaultStack'

[Mark Waddingham]

On 2016-10-09 07:19, J. Landman Gay wrote:
> On October 8, 2016 7:06:15 PM Monte Goulding <monte at 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
> 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.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps