Pre-selection matters with Split for attribute inheritance?

Rhino Developer
1

As we’ve been testing a new data tracking tool, I have found some interesting behavior regarding object attributes (specifically user strings). We have a plug-in that assigns user strings to various geometries for a variety of custom parameters. Ideally, when a user splits, explodes, or otherwise transforms these geometries, we’d like for the resulting elements to inherit the user strings of the geometries from which they derived. We’re attaching the user strings to the object attributes as per an earlier discussion…what is interesting is that when we split an object, it matters whether we pre-select the objects to be split or not. So, if no objects are selected, and we rely on the prompt to select objects supplied by the Split command, then the geometries that result from the Split indeed inherit the user strings…however, if we preselect the same geometries before executing the Split command, then the objects that result do not. We’re not seeing this with explode, trim, or any boolean operation…

2

Hi Dave,

Just using Rhino, I am unable to repeat what you are reporting. Can you give me step-by-step instruction on how to repeat what you are seeing?

– Dale

3

Thanks for getting back, Dale.

Behavior A

  1. Assign user strings to a surface or brep’s object attributes
    2: Pre-select the brep object
  2. Execute the Split command, and select a cutting object at the prompt
  3. The resulting geometries do not have the user strings still attached

Behavior B:

  1. Assign user strings to a surface or brep’s object attributes
  2. Execute the Split command, and select first the brep as the object to be cut, and a cutting object at the next prompt
  3. The resulting geometries have the user strings still attached

The initial state of a sample object and the parameter:

blob.jpg1123×359 116 KB

The loss of the parameter value when following the first process (preselecting geometry)

blob.jpg1123×359 114 KB

The retention of the parameter value when foloowing the second process (selecting geometry upon command prompt)

blob.jpg1123×359 116 KB

Thanks!

6

Hi Dave,

Using Rhino’s SetUserText, Split, and GetUserText command, I am not able to repeat what you are reporting. Can you?

How are you determining the results have no user text?

Perhaps we need some sample code?

– Dale

7

Hi Dale-

I’ve found what’s happening…it’s a bit long winded, but I’ll have a go:

I am managing object user strings through binding to a WPF form. I also have event handlers set up for selection events: select, deselect, and deselect all. In my parameter class a “LookupValue” string is then set according to the values read from each selected object (if it’s multiple objects selected, and they share the same value, then that shared value gets returned; if it varies a string that says “” is returned, and this is shown in the field on the form). The setter for LookupValue in my parameter class also uses a “ReadLookup” bool. When setting the LookupValue for populating the form, this is set to True. When it is false (when changes to LookupValue due to its form binding occur) then my LookupValue setter assigns the new set string to each selected RhinoObject attributes.

All well and good. But here’s the rub: for my deselect all objects event handler, because no objects should be selected, I am setting each LookupValue to be a zero length string. This works very well, except in the instance I have described above. For whatever reason, when geometry is preselected prior to the split command, the deselect all event gets raised with Doc.Objects.GetSelected() nonetheless returning the geometries of the bits left over following the Split command:

Pasted image958×163 8.24 KB

So when I was refreshing my form and setting the LookupValues to zero length strings, these objects were still actually selected, the binding to the WPF form was causing their user strings to be overwritten.

What’s so odd is that the same behavior doesn’t happen when you don’t pre-select the geometry. I suspect this has something to do with the fact that if you preselect, then the command leaves with the resulting split pieces also selected. But this still doesn’t seem desirable: that the DeselectAllObjects event should be raised despite there still being selected objects…

thanks as always for the help!

8

Hi Dave,

Thanks for the update.

It sounds like you might need to watch for object modifications too.

– Dale