Is this a bug?

[Tereza Snyder]

On Jan 20, 2007, at 4:57 PM, Phil Davis wrote:

> Mark Wieder wrote:
>> Chipp-
>> Saturday, January 20, 2007, 6:57:21 AM, you wrote:
>>> 'avoid time wasting confusion', then why even allow controls or  
>>> objects with
>>> the same name?
>> Yep - this has bothered me for a long time, too. I'd certainly  
>> support
>> a referendum to disallow objects with the same name, but I'm  
>> afraid it
>> would break backward compatibility. VB supports object instancing in
>> the form of group "America"[2], but I don't care much for the syntax.
> But the same-named object thing can sometimes be used to advantage.  
> Consider this:
>
> on mouseUp
>   put the groupIDs of this cd into tGroupList
>   repeat for each line tTargetID in tGroupList
>     switch (short name of grp id tTargetID)
>     case "Section"
>       doSectionStuff tTargetID
>       break
>     case "Page"
>       doPageStuff tTargetID
>       break
>     case "Chapter"
>       doChapterStuff tTargetID
>       break
>     end switch
>   end repeat
> end mouseUp
>

I use Phil's suggested strategy - of having multiple objects with the  
same name, and using the name as a kind of visible and easily  
scriptable 'type' property - all the time. I find it a great  
convenience. In addition, when I deploy compound objects that I want  
to update and refine (like Chipp's AltFldHeader), I append a suffix  
to the control name of each instance, e.g. MyComplexGroup_1, and  
update the groups with a utility script that locates and replaces all  
the groups in a project stack. The tricky part was getting the layer  
right, preserving the size, and transferring custom properties. But  
now that the work is done, I just click a button in the stack where I  
develop the group and presto! all instances are updated.

It does take a bit of discipline though, to be strict about naming.

I too long for the day when we have real custom controls!

t

-
Tereza Snyder

    Califex Software, Inc.
    www.califexsoftware.com