I suspect the fact that go sets the defaultStack (if it is topLevel) and neither clone stack or create stack do regardless of mode also needs to be documented somewhere. I wonder if go altering the defaultStack should be added to the bug db as an anomaly report? It’s certainly a non-obvious side effect of the command.
> On 9 Oct 2016, at 10:26 AM, Monte Goulding <mo...@appisle.net> wrote: > > Hi Folks > > I just had a look into the source and here’s the but in the go command > causing confusion: > > if (t_stack->getmode() == WM_TOP_LEVEL || t_stack->getmode() == > WM_TOP_LEVEL_LOCKED) > MCdefaultstackptr = t_stack; > > What this means is that unless the mode of the stack is topLevel (1) or > topLevel + cantModify (2) the defaultStack is not changed by the go command. > > Cheers > > Monte > _______________________________________________ > 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 _______________________________________________ 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
