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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
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
