Stack name conflicts resolved?

Richard Gaskin ambassador at
Mon Nov 7 11:12:57 EST 2016

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 

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 

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:

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
  Ambassador at      

More information about the Use-livecode mailing list