Stack name conflicts resolved?

Richard Gaskin ambassador at
Mon Nov 7 14:24:21 EST 2016

mwieder wrote:

 > Using the long id to refer to stacks works (or at least should work)
 > for all situations except for stacks that haven't yet been saved to
 > disk. And for those stacks I would suggest storing the creation
 > timestamp as a custom property on creating a new stack so that they
 > can be distinguished.

A UUID in the v9 file format could help a lot with those cases.

 > I haven't yet had the chance to implement Richard's patch, but I'm
 > looking forward to trying it out.

If/when you do, give this a whirl - in my initial tests it seems to work 
well in delivering the true topstack even when the short name is the 
same, accomplished by taking full advantage of the stack file path (just 
added to BZ#18793 as inspiration how the engine might handle this even 
better and certainly more efficiently):

function FixedTopStack
    put the stacks into tStackFiles
    put the openStacks into tStackNames
    put 0 into i
    repeat for each line tStackName in tStackNames
       add 1 to i
       put line i of tStackFiles into tStackFile
       if tStackFile is not empty then
          -- Mainstack?
          if the mainstack of stack tStackFile = tStackName then
             put "stack "& quote& tStackFile &quote into tStackRef
             -- Substack:
             put "stack "&quote& tStackName &quote& " of stack "&quote  \
                   & tStackFile &quote into tStackRef
          end if
          -- No stack filename:
          put "stack "& quote& tStackName &quote into tStackRef
       end if
       put the mode of tStackRef &tab& tStackRef &cr after tList
    end repeat
    delete last char of tList -- trailing CR
    set the itemdel to tab
    sort lines of tList numeric by item 1 of each
    put item 2 of line 1 of tList
    exit to top
    return item 2 of line 1 of tList
end FixedTopStack

If the topstack took the stack file path into account, most conflicts 
would go away.

If the file format were extended so that stacks include a UUID property 
at creation, that would provide distinction so complete that I'm unable 
to think of a case where identifying the true topstack would fail.

For backward compatibility, topstack might first check the filename and 
return that as it does now, e.g.:

   stack "/home/rg/something.livecode"

When the filename is empty, an enhanced topstack could return something 

   stack uuid c5087287-7884-49a0-95e5-a4a3009221c2

This is similar to other cases where attempting to get the long name of 
an object returns the long ID when the name is empty.

Since it only comes into play when stacks are unsaved, it would rarely 
ever been seen.  And even then, topstack is commonly used in momentary 
contexts so it would be rarely seen even then.

But would it would provide is a way of referring to all stacks that 
would always work regardless of their short name and regardless if 
they've ever been saved.

For now, just making sure topstack has checked the file path info it 
delivers will by itself move things forward in a big way.

  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