Stack name conflicts resolved?

[Bob Sneidar]

As he said, the stack ID is not really it's ID. In other words LC does not use the stack ID to identify it. Think of the stack ID as "the next ID to be assigned to a new object" much like SQL maintains a value in a master table of some sort with the next unique ID for each unique numerical column. 

So unlike any other object whose unique-ness can be determined by it's ID, a stack can only be differentiated by it's name. 

Bob S


> On Nov 5, 2016, at 11:28 , Richard Gaskin <ambassador at fourthworld.com> wrote:
> 
> I've grown weary of stack name conflict over the years, and this morning decided to take some time to assess where we're really at with that and see if perhaps there's a way to handle things more liberally than how the IDE does now.
> 
> TL/DR version:  It seems there's actually no real problem at all.
> 
> Long version:
> 
> 
> Setup
> -----
> I checked revfrontscriptlibrary and found that preOpenStack calls revIDEHandleNewStack, which resides in revbackscriptlibrary.
> 
> In that handler I found this line #3199, which I commented out:
> 
>  revCheckStackCollision tStackName
> 
> That handler is apparently the one that compares the stacks in the stack file being opened against a list of stacks already open, and if any stack of the same name is found it brings up the stack name conflict warning.
> 
> After commenting it out I made two stacks:
> 
> mainstack:  tA
> substack:  foo
> 
> mainstack   tB
> substack:  foo
> 
> On each mainstack is a button with:
> 
>  on mouseUp
>     toplevel "foo"
>  end mouseUp
> 
> Each foo substack contains an object to distinguish the stacks from one another, so I can tell which foo stack is which at a glance.
> 
> With that prep out of the way, I began my experiment:
> 
> 
> Experiment 1
> ------------
> I started a fresh session in LC, and opened tA.
> 
> Then I opened tB.
> 
> And since I'd commented out revCheckStackCollision, no warning was presented.
> 
> So then in stack tA I clicked the button, and it opened the foo substack belonging to it.
> 
> Then I clicked the button in stack tB, and it opened the foo substack belonging to it.
> 
> 
> Experiment 2
> ------------
> I created a third stack file, and added a button with the same script as above.
> 
> When clicked, it opens the foo window belonging to the stack file which had been opened first.
> 
> 
> 
> Results
> -------
> It would appear that the resolution of substack names follows a logical path that looks for matching stacks in this order:
> 
> 1. Within the same stack file as the script referring to it.
> 
> 2. Within another stack file, in the order in which they were opened during the session.
> 
> This seems more or less what I've been hoping to find for years:
> http://quality.livecode.com/show_bug.cgi?id=1061
> 
> Unless there's something here that I've missed, it would appear that stack name resolution is nearly as logical and useful across stack files as icon ID resolution.
> 
> And just as we don't need to go through contortions to ensure that every icon ID is unique across all stacks, as long as we remember the resolution rule we can safely use stacks of the same name within the current session.
> 
> That is, once we modify the IDE to allow it.
> 
> Is there something I've missed here?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode