Changing an attribute value of a DC automagically creates a new component. Why?

There must be something I did not get right about DC.
When I change the value of an attribute in my DC (Ok, it’s a special DC, I will describe it later), a new component is created. So, the bottom line would be: don’t loose your time with DC, just create new components! I guess I am wrong, but where ?

My not-so-special component is a component that includes another one (see definition below).
I first create the child component (named “Squarre” in my sample). LenX and LenY are the two attributes of it.
Then, I create the Parent component (named “Parent”). It includes an instance of “Squarre”. It has 1 custom attribute named “Side” that is linked to LenX and LenY.

I create a second instance of “Parent” by drag-and-dropping from the component list.

Finally, I change the “Side” value of one “Parent” instance, and bouuum … a new component is created.

My concern is: in my real project, I have a bunch of instances of such DC. I cannot afford as many component copies as instances with specific value for an attribute.

And finally, for the non-believer, the skp file: DC.01.skp (78.5 KB)

Thank everybody for your mind time!

1 Like

It is likely because you are in the same file, somehow components work best if you would make them in a ‘workfile’ and then save the collection to a folder.
When opening a new file, choose the folder as a collection in the component tray. It has to do with the (internal) path assigned to the component when creating,

This happens because you are changing the definition’s entities which would affect all instances of that parent component. The DC code is written such that it will unique-ify an instance’s definition if need be.

Simple scaling or changing text attribute values do not create new definitions, but anything that changes the relations of a component’s parts to each other does. It sort of sucks. The Component Browser becomes cluttered, and if you want to make a change to the original definition, it won’t alter all the objects deriving from it. A DC ought to be a separate entity type from a regular component.

2 Likes

Actually, it’d be a subclass, so it inherits most behavior, but can redefine what behavior needs to act differently.

1 Like

Does anyone has an idea on how to work-around this situation?

It really depends on what you want your components to do. But simply wrapping your working component in another may be sufficient then using out liner to easy excess the workings may help

DC.01 wrap.skp (87.7 KB)

you can private message me with your DC, or share it here and explain what functions you require it to do, then develop any solutions

1 Like

It really sucks. I don’t really see the point of DCs when this relation is broken and you can’t edit all derived components all at once. I’ve said it before but DC had the potential to be one of the greatest features ever of SU but instead I don’t even think it looks and feels like a part of the program.

I’ve made several concept sketches of a replacement but never had the time to take on such a project. A new object type that lies between definitions and instances in the hierarchy would certainly be helpful if implemented the right way.

Thanks everyone for your inputs!
But … is there any hope that this part of Sketchup might be someday refactored?

I really do not know. Dynamic Components, the Follow Me tool, Solid tools, Sandbox tools and, partly, the LayOut application are IMO features that have been introduced half-cooked and that have received very little attention since. They are all useful but have flaws and have not the same intuitiveness as the original SU tools.

4 Likes

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.