Coping with SU2017 entity handling changes

sdmitch

Some of my plugins are having problems with how SU2017 handles entities differently and I am not sure what I need to do to over come this. I have tried using .clone and .dup but neither remedy the problem. Any guidance will be greatly appreciated.

TIG

I have also seen these issues with some of my code.
e.g. my typical problem was that in versions < 2017 I could have a group of entities, added to in order, and have an array of references to those entities, when I exploded the group later the entities' references still worked.
Now with v2017 the exploded entities are all assigned new IDs after the explosion, so the earlier references point to 'deleted_entities', so the code fails.
ents=group.explode
Will return an array of the new entities, but you need to grep it to find the entity type[s] you need, and also it's not ordered, so that is lost.
Where the ordering is critical I have been adding an incrementing integer value to a key in an attribute dictionary attached to the entities in question [typically cpoints in my case].
Although v2017 messes with the entities' IDs it does keep the attribute dictionaries unscathed.
So once I glean a list of valid entities from the exploded data I can sort them back into the original order using their attribute dictionary key/value integer.
I can see no good reason that v2017 destroys the IDs in this way - it does now keep an enduring-ID associated with any entity across sessions, but scrambling the order of exploded entities is annoying...

What is the nature of your code's error messages in the Ruby Console - typically mine have been telling me I can't do things to deleted_entities, or trying to get some value for Nil [where that entity is not found or is invalid] etc...

sdmitch

@tig said:

What is the nature of your code's error messages in the Ruby Console - typically mine have been telling me I can't do things to deleted_entities, or trying to get some value for Nil [where that entity is not found or is invalid] etc...

I'm getting the "deleted_entity" message. In Face2Frame, I need somehow to keep the selected face from being destroyed. I need to use this face in multiple subroutines.

TIG

Perhaps use my attribute dictionary key/value trick to re-find the entities from the exploded list...

fredo6

SU2017 always creates new references for entities coming from an exploded group.

In SU2016 and before, SU was keeping the entityID and object id for the first instance of a group exploded.

This has caused also some problems in my plugins (FredoScale in particular).

There is nothing you can do, except assigning attributesto entities you create in a group and then retrieving them after explosion via their attribute (since object_id, entityID and persistent_id are changed).

What SU2017 is now missing, due to this unfortunate change, is a usuable way to create geometry in a working group, explode it, while keeping references to the entities created.

In addition, I am pretty sure there is a bug in SU2017 in relation to entities.add_group with entities in argument, when the group if further exploded. This seems to mess up the model and crash in commit_operation.

TIG

@Fredo

I Agree with you, but whether or not this mess was ever intended in v2017 has never been comment upon by Trimble or even acknowledged as a possible issue...

It's a pain !

fredo6

The other issue with group.explode is that the return list contains all sort of objects, like EdgeUse, etc... which are not all pure geometry. So you need to filter the result to keep what is meaningful.

Fredo

TIG

Exactly !
Hence my earlier 'grep' comment...
It's all solvable - but to me it seems an unnecessary convolution !!!

Dan Rathbun

@sdmitch said:

I have tried using .clone and .dup but neither remedy the problem. Any guidance will be greatly appreciated.

These two methods are Ruby Core functions that rely upon specific Ruby housekeeping methods to do the copying.

The SketchUp API has not set up these "housekeeping" methods, so doing this will not work.

They have only in a few places "mimicked" a clone method (mostly in the Geom classes,) and a partial cloning in Group#copy. (It does not copy over attributes and other parameters.)