Rhinocommon: ObjectTable Deleted Objects?

In looking through the Rhino.DocObjects.Tables, I noticed that if I iterate over the LightTable LightObjects I get all of the LightObject, even the ones which have been deleted in the active Rhino Document. This behavior does not seem consistent with the ObjectTable. If I itreate over the ObjectTable, I only get back the objects currently in the Rhino Document. Where do the deleted objects go?

My intention is neither to get deleted objects, nor any other deleted objects. I found this inconsistent behavior while iterating over the ObjectTable and the LightTable to export some objects. In my resulting file I was getting all of the lights, even if they had been deleted, but I was only getting the objects in the Rhino Document.

The LayersTable also returns all layers, deleted or not. Is there a reason that the ObjectTable has different behavior than other tables (not returning deleted objects)?

Probably because the ObjectTable has more advanced functionality for finding, e.g. deleted, hidden and non-visible objects in the FindByFilter method. This “advanced” way of iterating through a list of lights has not been necessary, also because the number of lights in a document is in most cases much lower than the number of objects.


Also, using LINQ queries it is easy to select non-deleted lights:

foreach(LightObject light in lights.Where(l => !l.IsDeleted)

@menno This is clear. Just wondering if the behavior should be consistent across all tables?


So is this a bug? Can you replicate this? The RhinoObject count in the ObjectTable will change if objects are deleted, while the other tables, the count remains the same.

Sorry, I though your question was in regards to Menno’s LINQ syntax.

The Rhino object table’s “count” function always returns the number of undeleted objects. All other tables’s count functions return the number of items in the table and includes both undeleted and deleted objects.

– Dale

And this was my question, shouldn’t the behavior across all tables be the same?

Possible, but it is too late to make a change like that. It would cause unexpected behavioral breaks in existing plug-ins. Best we can do is improve documentation.

1 Like

OK, fair enough!