Ben Rubinstein wrote:
> No overtones intended by use of word "trying"! I should have said
> "experimenting with" or similar...
No offense taken, I just want to be sure that my glee for discovering
the soundness and simplicity of the engine's handling of this does not
mean I recommend relying on the engine alone for others.
As we've seen in this discussion, there are some workflows which can
benefit from extra scripting to introduce a prohibition on using two
different stacks with the same name during development.
> 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?
Good test case - thanks.
I hadn't tested it before because my primary interest here is in runtime
behavior.
In testing here this morning, I discovered what may well be the source
of some (if not a majority) of the issues surrounding stack name
conflicts: a bug in the topstack function itself.
Here's what I found:
I made two new mainstacks, both named "foo".
While attempting to add controls to them and saving them, I found a bug
in the topstack function.
Topstack should return the long name of the topmost stack of the lowest
mode.
Once saved, no two stacks will have the same topstack value, since it
includes the path, e.g,:
stack "/home/user/Desktop/foo.livecode"
stack "/home/user/Documents/foo.livecode"
With my IDE mod in place which allows me to open stacks which have the
same name (this could also be tested in a standalone), I found that
querying the topstack always and only returns the value of the stack
which had been opened first, regardless which one was actually topmost.
Of course, since the value of the topstack function itself is an
absolute reference that includes the path, it would seem reasonable to
expect that the engine at least attempt to take that distinguishing
factor into account when deriving the value it returns.
So I just filed a bug report on that:
http://quality.livecode.com/show_bug.cgi?id=18793
This still won't affect the subset of cases involving stacks of the same
short name in which both are newly created and have not yet been saved,
and for those the IDE prohibition on renaming/creating may suffice.
Similarly, downloaded stacks would not be distinguishable, since they
also have no value in their filename property.
But both of those are relative edge cases I'd be happy to handle through
other means once topstack is updated to at least attempt to use
available information for accurate results.
And once topstack reliably returns a more accurate reference, it would
seem many if not most of the issues we've been having would likely go away.
--
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
