If this is expected behaviour, forget about it! But it seems a bit strange, as in userspace, unless you actually do something with the selected object, the attributes do not change, therefore the event is not needed.
To reproduce:
add a handler to RhinoDoc.ModifyObjectAttributes
draw a curve/circle/polyline
select it, do nothing, then deselect it
watch the event trigger
For meshes, breps, etc. this does not happen.
I’ve hacked my way out of it by returning if the e.OldAttributes is the same as e.NewAttributes.
private void RhinoDoc_ModifyObjectAttributes(object sender, RhinoModifyObjectAttributesEventArgs e)
{
//Prevents https://github.com/speckleworks/SpeckleRhino/issues/51 from happening
if (Converter.getBase64(e.NewAttributes) == Converter.getBase64(e.OldAttributes)) return;
//Do other stuff
}
This behavior is also happening here ( working with Rhino 7). curves are triggering ModifyObjectAttributes event when deselected, eventUnselect.gh (3.2 KB)
code is taken from here
Edit: Ok, this has been previouly further analized. Stiil finding a solution for this “by design” behaviour. @dale has McNeel any proposal for a workaround to this? I need to avoid this event triggering when user select/unselect curves. I tried to use @idid method but, didn’t find in .net library this “GetBase64” method. Seems that is a custom implementation, and I dont know how to implement this myself. How can I compare if OldAttributes and NewAttributes are identical? Thanks
For those reading this: to find out wether the event notification re object change is warranted, we just compare the hashes of the old object and the new one. If they’re the same, skip it.