I understand, but discussing three things in one thread can get confusing. So I was first concentrating upon the “Name” issue, formally numbered 3 (now renumbered 1?, which is confusing.)
This is what the definition name property is meant for, and labeled “Definition:” in the EntityInfo.
The only drawback is that you cannot prevent users from changing them for the “InModel” definition. But you could watch when it happens (with a definition observer,) scold the user with a messagebox, and restore the previous definition name from a hidden DC attribute (begins with an underscore.)
I’d argue that is a description, and “butt-backward”, but that’s just nitpickin’.
No, “Name” is supposed to be blank, so that the user can assign the instance use-name, that only has meaning to what that instance is used for, or where it is used.
Example: “Summer Beam, Right Side”
Trying to redesign how SketchUp and users fundamentally use components and their instance names is a recipe for disaster. Other plugins will not likely do this, creating two modes of using SketchUp. The User Guides will be telling users to use the field in a way different then your plugin.
You understand that when the user does this, the instance’s old definition was cloned, and made the definition for the “uniqued” instance, and then the definition’s name was “differenced” with a “#n” where n is either 1, or the next successive available “differencing” number, for that definition name.
There were some bugs in older versions where more than one object in a collection could have the same name. It might have applied to the definitionlist at one time. It applies to the Materials list in v15 at least. A differencing number will be added if you add a new material with a name already used, but afterward you can change the name explicitly to remove the differencing number, resulting in two members with the same name.
My point is that the name property for members of collections is just a string variable property. Considering it to be a unique identifier is fragile (easily broken.)
ComponentDefinition.guid, but it changes whenever the definition is modified, and very likely after a “uniqueify” operation, since a new cloned definition was created. This is also an old method dating from v6 or earlier.
Since you’'ll assign this once, to some hidden attribute somewhere, you could simply use one of the API’s guid generator methods to create an id to put in the hidden “_guid” attribute.
Open a new empty model, open the Ruby console, and type:
Then cut and paste the guid string someplace, Notepad etc. for use later with one of your components.
Hit the New model command, to load a new model. Repeat… as many times as you need guid strings, compiling a list to use with your hidden attributes.
It is likely there are guid generator utilities you can find that will run externally, from the command prompt, etc.