Mark Waddingham wrote:
> The engine has always been 'okay' (I believe) with substacks of the
> same name when they are owned by *different* mainstacks - the only
> rule you must follow in your code is that if you are referencing a
> substack when the 'defaultStack' is not the main stack owning it,
> then you must use:
>
> stack ... of stack ...
>
> Just as you would if you have two controls with the same name in two
> different groups.
>
> There is still the general problem of having multiple mainstacks with
> the same name, or multiple substacks with the same name with the same
> owner. Unfortunately, I'm not sure there is a general solution to
> that (mainly because we use stack <name> as the reference for a
> specific stack in script, and when you start making cross-stack
> references, any search order is likely to cause 'surprising' results
> at unexpected times).
In my ongoing tests it seems to be even better than that.
Apparently referring to a stack by short name will cause the engine to
resolve it somewhat similarly to how it resolves other universal
references like image IDs:
1. It looks for the stack in the same stack file as the script
referring to it.
2. If not found, it searches other open stack files in the order
in which they were loaded into the environment.
This appears to work well for both substacks and mainstacks (easy enough
to explore once I commented out line #3199 of revbackscriptlibrary,
worth doing at least temporarily to see how things run).
Given the apparent simplicity and consistency of how this works, I read
Ben's post earlier this morning with great interest, which pointed me to
cases where the engine appears to get confused by stacks with the same name:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232505.html
Since I'd already disabled the IDE's same-name check, I was empowered to
explore those issues and found what seems to be the heart of at least a
big chunk of this:
The topstack function returns a value that includes information it isn't
checking when it attempts its resolution to derive it.
Or more simply, topstack only checks short name, apparently using the
same load-order search path other stack-name-resolution methods rely on.
E.g.: if I have two stacks both named "foo" but saved to two different
files, no matter which one is on top "topstack()" will only return the
long name of the one opened first.
Since topstack includes the path, it would seem reasonable to expect
that the path would be checked as part of the resolution process, and
indeed useful if it were.
I included other notes related to this in my other post this morning:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232514.html
...along with the link to a new bug report for topstack:
http://quality.livecode.com/show_bug.cgi?id=18793
This won't handle all possible cases (caveats noted in report), but will
make the topstack function more reliable across a broader range of
circumstances, perhaps eliminating a majority of issues relating to
stack name conflicts.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
