I’m developing a Rhino plugin in which the user interface pane allows the user to select objects in the viewport and a listview (or something similar) will show their referenced object. I still want them to be able to manipulate the RhinoDoc and therefore possibly delete or modify the objects either via the pane or via the viewport. The pane will allow them to associated additional data with the objects, possibly either via a mapping I maintain, or via extending the rhino object with custom data. (I’m tending towards possibly adding a tag/custom data type to all the objects which I also maintain, so it’s the tag which is represented in the list view. Then when the user triggers an action I can query the rhino doc objects for anything with my tags and then extract the corresponding Geometry info)
My understanding is that a Rhino’s Object can change its guid depending on what interactions the user makes? Is this true? I.e. if a line is spilt will the original rhino object remain or is it deleted and replaced with 2 others with new guide?
My question re splitting a line was more… If a line is split does the underlying geometry become a multiline in order to keep the same guid. I did expect this was not the case though. The geometry as far as I understand is a value type (i.e. struct in many cases) so does not have a guid. The RhinoObject type which wraps the geometry (amongst other things) has a guid and it’s the relationship between it and it’s underlying geometry that is not clear. So what changes to the geometry can be made without causing a new rhinoObject to be recreated in its place (I expect a translation does not do this?)
You can create all kinds of virtual geometry without adding it to the document. Once the geometry does get written to the file, it automatically gets a GUID, that’s the only way to track it in the object table. There are ways of attaching other kinds of references to the objects but it is not certain if for example, the object is split in two by a user action outside of your control, that the reference data is transferred to both parts.
Thanks all, in the end it was enough for me to attach handlers to the Doc Events for Add, Delete, Replace Undelete events. It is maybe not the best approach, but I just track the guid during a call sequence and if before and after the events the guid is still present it remains. If the guid is removed I remove my reference, if new guids are created I ignore this and force the user to re-associated.
I think i had trouble in the past as I was storing a reference to the objects geometry and the replace removes the object but creates a new one in its place with a new guid, and I guess the geometry (especially if a struct) is removed so I was potentially hold a reference to something which no longer existed.
