Hi Richard,
No overtones intended by use of word "trying"! I should have said
"experimenting with" or similar...
I am interested though that you noted, if I understood correctly, that your
experiment showed that having two substacks with the same name didn't cause an
issue in the IDE when using the substack name with "toplevel". QC #143
suggests that (way) back in the day, there were serious issues that arose in
this situation when attempting to save changes to such stacks. Did you find
any evidence that this is still a problem?
best wishes,
Ben
On 07/11/2016 15:00, Richard Gaskin wrote:
Ben Rubinstein wrote:
Currently if I understand it correctly there are issues which seem
just too hard to fix: so instead
http://quality.livecode.com/show_bug.cgi?id=143 - the most egregious
of these issues - was 'fixed' by adding the check that Richard's
trying to remove.
In all fairness, I'm not *trying* to remove it, but have in fact removed it -
in my own copy of the IDE.
As I noted in this post, I've not closed #1061 because I recognize that the
IDE has different responsibilities beyond those of our own apps:
http://lists.runrev.com/pipermail/use-livecode/2016-November/232451.html
I'm just glad to find that the rule for looking up stacks by name built into
the engine is simple, understandable, and very useful.
We can have confidence that our standalones, which don't include IDE-specific
code, will allow stacks of the same name to run without issue according to a
fairly simple search rule.
This means that I can have a classroom of students sharing stacks without
having to impose all sorts of complicated schemes to ensure that stack names
are unique.
For standalones, the engine behavior is beautifully elegant.
But I do recognize that the IDE has a special role with special
responsibilities, and have left my original enhancement request open as we
explore ways to address that, hopefully arriving at a middle ground which
provides confidence about which stack we're working on while also giving us
the freedom to use stacks as easily as the engine allows.
_______________________________________________
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
