Organizing Component Data in Component Libraries

[ash]

I have created a component library that has three main attributes that need to be a part of the component for processing purposes.

1. A unique component ID that changes everytime a component is made unique. For this I have used “Description” so that everytime the user hits “Make Unique” the component ID number in “Description” automatically gets appended with #1,#2 etc ensuring that every unique component his it’s own unique number.
2. A constant lookup ID that stays the same no matter whether the user hits “Make Unique” or not so that when a report is generated, this number can be used to VLOOKUP another Excel master list to find the additional info for the component irrespective of how it has been changed by the user. I have put this constant ID as a DC attribute because “Name” seems to get wiped everytime I bring a component from the library into a new model (very frustrating).
3. A common name so that the user can immediately see a description of what they are dealing with - I don’t want this to be a DC attribute as that would require the user having the DC dialogue open which is unnecessarily complicated. However, putting this information as the component’s “Name” under ‘entity info’ results in the info getting wiped everytime a bring the component into a new model via the components browser.

Does anyone have experience with this and can give me advice how to simplify things and make it as user friendly as possible?

[DanRathbun]

I have put this constant ID as a DC attribute because “Name” seems to get wiped everytime I bring a component from the library into a new model (very frustrating).

There are two separate “features” here that have the same names. Ruby object properties “Name” and “Description”, and “dynamic_attributes” AttributeDictionary attributes that are used as DC dialog labels.

Are you confounding the two ?

---

##Ruby-wise

Both ComponentDefinition and ComponentInstance have a separate and distinct name property. But only the definition has a description property. (The instance’s property “getter” method is a wrapper to it’s definition’s property, and only the definition has a “setter” method.)

• In the EntityInfo inspector, the instance’s name property is labeled “Name:”, the definition’s name property is labeled “Definition:”.

• In the Components inspector, the top editbox is the definition’s name property. The editbox just below is the definition’s description property. (They do not have labels, but do have on hover tooltips.) Note, both definition properties can be edited model-wide in these editboxes.

Whenever you insert a new instance into the model, the instance’s name property (in the EntityInfo inspector,) will be blank. All ready for the user to enter some particular identifier for the specific instance.

---

##Dynamic Component-wise

The attributes (in the “dynamic_attributes” AttributeDictionary) labeled “Name”, “Summary” and “Description”, only appear (in that order) at the top of the “Component Options” webdialog (which is created by the DC extension.)

They will be (or should be) the same for all DC instances.

[ash]

Dan, thanks for the comprehensive reply.

My challenge relates to the instance’s name being blank:

Whenever you insert a new instance into the model, the instance’s name property (in the EntityInfo inspector,) will be blank. All ready for the user to enter some particular identifier for the specific instance.

In my component library, I need three different pieces of information associated with each component in the library:

1. A human-readable name that the user has ready access to through Entity Info so they know what they’re dealing with. For example, “150 x 100 roughsawn timber”. “Name” in Entity Info would be ideal for this but it comes in blank (as you pointed out).

2. A unique identifier number that appends whenever the user hits “Make Unique”. The Definition in Entity Info is perfect for this because it automatically appends “#[number]” everytime the user clicks “Make Unique”

3. A constant reference number that doesn’t change so that the type of component always has a reference number and pricing info, supplier name, strength characteristics etc can be looked up (VLOOKUP) from the bill of materials generated from Sketchup (File > Generate Report). This number can simply be a Dynamic Component Attribute as the user doesn’t need to see it and it doesn’t need to change (See “Code” in the image below).

So my issue is having both a human-readable name and a unique identifier code that self-appends.

It seems that “Name” (in Entity Info) would be perfect for this but, as you say, it always comes in blank.

I do wonder if this can be done through Dynamic Components as it seems that the name of the component listed in the Component Attributes dialog is essentially the Definition name from Entity Info without any appending (see image). Is this correct?

Does anyone have any good ideas of what I am describing can be achieved?

[DanRathbun]

In my component library, I need three different pieces of information associated with each component in the library:

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.)

A human-readable name that the user has ready access to through Entity Info so they know what they’re dealing with

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.)

For example, “150 x 100 roughsawn timber”.

I’d argue that is a description, and “butt-backward”, but that’s just nitpickin’.

“Name” in Entity Info would be ideal for this but it comes in blank (as you pointed out).

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.

---

A unique identifier number that appends whenever the user hits “Make Unique”.

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.)

---

A constant reference number that doesn’t change so that the type of component always has a reference number …

There is 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:
Sketchup.active_model.guid
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.

[ash]

Hey Dan,

Thanks for your interest in this.

I’m not actually writing a plugin, I’m just setting protocol for a library of components.

To get to the nub of the issue:

• The constant number can be a Dynamic Component Attribute so we can ignore that.

• The human-readable name can be the Definition

• How then, can I add a unique identifier number that will, as you say, “uniquify” every time the user hits make unique without having additional plugins etc installed? Is there a way to do this through Dynamic Components? Or should I make the human-readable name and the unique identifier one field (Definition) and eliminate all this confusion?

PS: Sorry for the scatter-brained way of presenting things

[DanRathbun]

How then, can I add a unique identifier number that will, as you say, “uniquify” every time the user hits make unique without having additional plugins etc installed?

SketchUp already does this natively, for all components, not just DCs. You cannot prevent it from happening, but you can detect it via a Ruby observer (which means an extension.)

Being based on API core components, Dynamic Components also will do this when the user does a “Make unique.” But also the DC engine does it whenever it determines that the instance needs it’s own definition.

Ie, instances do not have entities collections, so they cannot have a differing set of entities than their “sibling instances.” But some DCs, like the example picket fence section, create copies of sub-components (pickets) when the parent DC is scaled longitudinally. Fence sections are usually sold here in the US in 10 foot sections, so it makes sense to create the library DC at 10 feet wide (or whatever the standard width is,) with the full complement of pickets. Then for any short span, the modeler would scale a narrower section. The DC engine will detect this scaling, and “unique-ify” the instance by cloning the definition.

Is there a way to do this through Dynamic Components?

After looking through all the DC functions, I do not think you can.

Neither the Ruby definition name property nor the Ruby instance name property are reflected in the “dynamic attributes” dictionaries.

So, for example you cannot even use the DC text functions like =IF(FIND('#',NAME)>0,'unique','original')
to detect a unique’ing operation, because the NAME attribute is just for display in the Options dialog, and is not a copy of the Ruby name properties (either definition or instance.)

[ADD: It is also a weak test because the user can manually change the Ruby definition name property at will adding the pound symbol and or numbers, which does not clone a new definition, nor assign any instances to a new definition.]

And the DC functions cannot query the underlying Ruby objects for properties.

So you are stuck. It must be Ruby code implementing an observer.

[ash]

OK, I have a workable solution - its not perfect but it is simple. For something like this that many people will be using - I prefer to go for simplicity - less “moving parts” means less to break.

As you pointed out Dan, what can be confusing in this process is the fact that “Name” when you create a component actually becomes the “Definition” for that component later.

“Description” when you create a component becomes a little tagline in the component browser (although, outside of “generate report” I’m not sure how else to easily access this information).

In this instance we can use this description as the “Human Readable” info, “Definition” is the self-appending unique code and a DC attribute is added to each component that remains a master reference.

The only way I can improve on this is to make “Description” more accessible to the user but right now it is workable.
The image below makes things a little clearer.

[DanRathbun]

[ash]

Cool,

I’ll just have to put a note to users to have the “Components” dialog box turned on.

Thanks very much Dan.

[ash]

I just noticed that, in SU 2016, it doesn’t actually shown the Component Description in the Component Browser even if you have “In Model” selected…and way around this?

[DanRathbun]

Let me be more clear. (The purple text in the image was terse.)

The definition must be selected, in the “In Model” definition list, in the Components Manager, for the “name” and “description” fields to be populated.*

This is because they are edit fields, not just display boxes. The user can globally change the definition’s name and / or description at any time. (I said this in the thread above. You cannot stop them from changing these fields, but you can detect the change via a Ruby observer.)

It would be a good feature request for the definition’s description to appear (as READONLY) in the EntityInfo inspector, when a component instance (and maybe a group,) is selected.

* Why? Because, selecting a component definition interrupts the current tool, and activates the component placement tool with the selected component attached to the cursor. This can be annoying if the user is only in “inspection mode” and not really wanting to place more components. (Get used to hitting the ESC key alot, to throw away the component, and return to the SelectionTool.)

In the EntityInfo inspector, if the two shadow checkboxes were moved down to the left under the other two (Hidden & Locked,) there’d be a nice place for the description display.

---

Groups are a bit special in that their definitions are hidden in the UI, but programmers can change their definition’s names and descriptions via code. (The group instance’s description methods are proxies to it’s definition’s description.)

[sigasiempre]

To be honest, while SketchUp has a variety of good features, the component library system is quite poorly conceived. The design invites all manner of confusion and difficulty. A well-organized library of images is not forbiddingly difficult to design. Unfortunately SU appears to be wedded to the existing system perhaps in part because so many people use it. It might be difficult to migrate to a better system.