In Rhino 5, object select/deselect events did not trigger RhinoDoc.ModifyObjectAttributes. In Rhino 6, they seem to. This is problematic for my purposes because there’s no means to check whether or not that was the cause of the event - with actual attributes I can compare OldAttributes to NewAttributes, but since “Selected” is not an attribute I can’t tell that this is what has occurred. Is there a reason for this change? Is it supposed to be this way?
Seems this was reported before? Rhino Beta: `ModifyObjectAttributes` triggered on selection/deselection of NurbsCurve-like objects
To reproduce, try writing the following c# script in Grasshopper:
private void RunScript(object x, object y, ref object A)
{
RhinoDoc.ModifyObjectAttributes -= Modified;
RhinoDoc.ModifyObjectAttributes += Modified;
}
// <Custom additional code>
void Modified(object sender, Rhino.DocObjects.RhinoModifyObjectAttributesEventArgs args){
MessageBox.Show("Modified event triggered");
}
Draw a rectangle in Rhino, select it and then deselect it. If you do this in Rhino 6, you get the popup; in Rhino 5, you don’t.
as @marcsyp figured out, it’s related to the auto-points-on behavior - if you window select (and control points don’t turn on) the event doesn’t fire.
Hi @andheum,
The short answer is yes.
When “auto points on” is enabled and you pick something that qualifies for having it’s control points turned on, Rhino adds some super-sneaky data to the object attributes so it can determine what objects to turn control points off when everything is un-selected.
This this a huge problem or just an annoyance?
– Dale
If I may chime in:
I think it a non-trivial issue as there is apparently no obvious means anymore to distinguish between selecting and modifying . So it’s now up to the developer to sift through the attributes and find a change if there is any. This will generate a lot of overhead and much more tedious bug-tracking.
Could the super-sneaky data addition not become super-super-sneaky and avoid triggering.
-Willem
1 Like
We sorted this out in a very brutal way:
if ( Converter.getBase64( e.NewAttributes ) == Converter.getBase64( e.OldAttributes ) ) return;
inside the event. Full code here. There probably is a faster way…
Or, could the args object have a “ChangeKind” attribute (or similar) to specify what sort of attributes change triggered the event? This would be ideal from my point of view - in the handler I can just filter on that property and figure out if the given change was one I intended to react to.
1 Like
I agree – if the attributes data can become less sneaky (i.e., exposed) then it would allow for a much cleaner decision tree and also support the case where for some reason you need to know if the selection of an object has triggered a parallel event in the Rhino UI (e.g., GripsOn).
Distinguishing between attributes change and selection is absolute must have in my world. I’m using a pretty ugly hack right now to get around it (on the GH side, since the issue is firewalled within a non-OS plugin (Human)).
Thanks all,
Marc