A bug in the Group and ComponentDefinition stats

Hi,

When copy a group, just after the copy operation is done, without going into the copied group, the componentDefinition of the group has two instances, the original and the copied. I don’t think this is the expected behavior for groups.
And after going into the copied group (by double click), the coponentdefinition refreshed to only one instance.

For the groups below,

Now it gives

g0 = group
#<Sketchup::Group:0x00024afc956250>
g1=group1
#<Sketchup::Group:0x00024afc9545b8>

g1.definition.count_instances
2
g1.definition
#<Sketchup::ComponentDefinition:0x00024afc9562c8>
g0.definition
#<Sketchup::ComponentDefinition:0x00024afc9562c8>

And after going into the copied groups for once, it gives

g1.definition
#<Sketchup::ComponentDefinition:0x00024afc9562c8>
g0.definition
#<Sketchup::ComponentDefinition:0x00024afc935b18>
g1.definition.instances
[#<Sketchup::Group:0x00024afc9545b8>]

Is this a bug or expected behavior?

Han

This is expected.

Groups are good for keeping objects together (grouping them) and if you do not intend to reuse them.

This is why groups are components with special behavior added:

  • do not display in the components browser (to avoid clutter)
  • changes to an instance do not propagate to all other instances, but the current instance is made unique (without right-clicking → Make unique)

One could argue whether a copied group should immediately have an independent definition (which takes extra space) or only once it is being modified.

2 Likes

Thanks, I have looked at the doc of Group::make_unique and it says,

Copying a group using the copy tool in SketchUp will create copies of the group that share a common definition until an instance is edited manually or this method is used. If multiple copies are made, all copies share a definition until all copies are edited manually, or all copies have this method used on them. This method ensures that the group uses a unique definition entry in the drawing database.

I think this is what I have encountered.

This is by design, as it would be a waste of space to have duplicated definitions for identical groups. Also it can be very nice when modeling, as you get an extra chance to convert groups to components even after having copied them (e.g. using TT’s selection toys).

For a plugin you can call the make_unique method before editing a group. I think it’s best practice to do this silently on groups as the user expect editing one of them to only affect that one. For components you should generally avoid make_unique as the user expect changes to one to apply to them all, but if you need to edit them individually (e.g. to line up their axes with the parent) I’d recommend to warn the user and give them a chance to cancel the operation. Otherwise there is a risk the user notices they were made unique way later, and have done too much work in between to be able to simply undo the change.