Stack with the same name loop

Brian Milby brian at
Thu Oct 7 14:11:38 EDT 2021

I was not aware of the rename possibility, so it would be possible to produce a plug-in that would use your code snip to allow a duplicate named stack to open.

The only time I’ve really run into this is with “Untitled 1” stacks.  I’ve done something quick and saved it without changing the stack name.  Then opening two of those such stacks is an issue.  This is about the only time I would want to have two same name stacks open (and would probably rename them anyway once both were open).

I think this falls in the realm of something that could be done but there isn’t much real reason that it is needed.  That does assume that the engine isn’t changed to remove the options that currently exist.  I only really started looking at it due to the old bug reports that come up every year or two.

Thanks for your comments Mark!  Very enlightening.


Sent from my iPhone

> On Oct 7, 2021, at 12:44 PM, Mark Waddingham via use-livecode <use-livecode at> wrote:
> On 2021-10-07 17:25, Brian Milby via use-livecode wrote:
>> I would be more of a fan of lowering the engine check to just a
>> warning vice a hard error/prohibition.  Like you said, if you don’t
>> use the long name then most of the time you are going to reference the
>> earliest opened version of the stack (based on the linked list of open
>> stacks).  But if you reference an object within the same stack (or at
>> least the visible card), it can reference by short name.  I guess I
>> should expand my test stack to check that.
> I'm not quite sure how the engine would give a warning - the behavior being discussed in this thread is the way the IDE deals with how the engine deals with a specific case...
> In general, the engine will either let something happen or it won't. In this specific case, it doesn't let implicit opens of stacks (which is what all initial openings of stacks are when you use a 'stack <name>' chunk are - given the potential disconnect between what <name> is, and what stackfile might actually be loaded) proceed if there is already a stack with the same name in memory...
> However it *does* send a message 'reloadStack' that can be handled so script can decide what to do.
> Indeed, this handler could happily let things go ahead:
>  on reloadStack pStackName, pPath
>    local tOldFilename
>    set the name of stack pStackName to (pStackName & "~")
>    put the filename of stack pStackName into tOldFilename
>    set the filename of stack pStackName to "this is a unique name"
>    go stack pPath
>    set the name of stack "this is a unique name" to pStackName
>  end reloadStack
> The IDE chooses not to do this to stop the large number of other issues which could arise from having multiple stacks in memory with the same name (in an environment where it might happen 'by accident', rather than for any particularly controlled reason as might be the case in a standalone environment written to cope with it).
>> I can see a couple of ways to implement this where it would not impact
>> existing code.  First would be a global flag to enable opening of
>> files with the same name (default to off/false).  The second would be
>> a “force” parameter to the open command which would bypass the check.
> I guess my real question here is what would be the purpose of that? i.e. What problem does it solve?
> Warmest Regards,
> Mark.
> -- 
> Mark Waddingham ~ mark at ~
> LiveCode: Everyone can create apps
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the use-livecode mailing list