Two stacks with the same name [was: Re: REALLY close stack - no, really]

Graham Samuel graham.samuel at wanadoo.fr
Fri Jun 18 05:22:17 EDT 2004


On Tue, 15 Jun 2004 22:53:36 -0700, "John Rule" 
<johnrule at rcsprogramming.com> wrote:

>[snip]
>Why doesn't the engine
>check the window ID anyway rather than the name? Why shouldn't I be able to
>have two main windows with the same name? Is this off topic?

I don't know if it's OT, but it's a good question. IMHO the reason you 
can't do this is because Rev's name scoping scheme is flawed, so that names 
are not unique when they could be. I'd rather NOT use the ID, but rather I 
would have Rev implicitly qualify each name with the name of the file it 
came from - or some scheme like this.

I find it a constant problem during development that I can't load bits 
(stacks and substacks) of old apps in order to copy parts of them if they 
just happen to have the same name as a new stack I'm trying to construct. 
Usually I start off with a well-ordered idea: I load an old stack and 
adjust its coding to a new situation, save it and go on from there. Then I 
find I've deleted something I'd rather keep, so I want to nip back to the 
original version to get the deleted bit of script, object or whatever so as 
to paste it into the new version, and I find I can't because of the name 
clash. In principle I could change the name of the modified stack (and all 
its substacks if it has them) when I do this 'cannibalizing', but this is 
not so easy as there will be references to the stack's name built into the 
code. Thus if I refer to 'stack A' from within a specific file containing 
'stack A' I don't want this to be confused with a reference to 'stack A' 
from within a completely different file containing **another** 'stack A'.

However I don't expect this to change any time soon as it seems to be a 
fundamental property of the engine rather than the IDE.

Graham

---------------------------------------------------
Graham Samuel / The Living Fossil Co. / UK & France  




More information about the use-livecode mailing list