Bug within Attribute Name in Rhino6

Hello,
maybe someone knows a work around. I had no problems with this snipped of code in Rhino5 but in Rhino6 it makes some strange mistakes:

Rhino.DocObjects.ObjectAttributes Attributes = new Rhino.DocObjects.ObjectAttributes();
Attributes.Name = “[DEF]Area[NAME]” + Command;
var guid = doc.Objects.AddCurve(Rec.ToNurbsCurve(), Attributes);

In Rhino5 the Name is => [DEF]Area[NAME]Command => Super Duper OK
In Rhino6 the Name is => ^[DEF]Area[NAME]Command => Error

What going on in Rhino6. I never switched because of performance issues with Rhino6 but some clients want to move to Rhino6. This is a serious bug because lots of projects are based on Naming convention.

cheers
Michael

Thanks, I have logged the report as https://mcneel.myjetbrains.com/youtrack/issue/RH-51585

Hi Michael,

using the example @nathanletwory posted on YouTrack, it prints False for the equality check if the name is assigned like this:

obattr.Name = "[DEF]Area[NAME]Command"

Result:

[DEF]Area[NAME]Command
^[DEF]Area[NAME]Command
False

I can make it print True if i force some extra quotes when assigning the name like this:

obattr.Name = chr(34) + "[DEF]Area[NAME]Command" + chr(34)

Result:

“[DEF]Area[NAME]Command”
“[DEF]Area[NAME]Command”
True

_
c.

Note that now the name isn’t [DEF]Area[NAME]Command, but "[DEF]Area[NAME]Command". It may look to the eye similar, but they are hugely different. Granted, the ^-character isn’t in front of it though.

1 Like

Hi @nathanletwory,

i just found that Rhino 6 object naming conventions does not allow to assign names which begin with these symbols: () [] {}

@mi_sprinzl, maybe you can just add any letter in front as a workaround :wink:

_
c.

Thanks I think this will help.

What performance issues are these? V6 in general should have better performance characteristics than V5.

Ok It is just a feeling. But i think for example Grasshopper seems slower and also the gui in Rhino has some nice visuals which are not Helping the Performance. This is not only a think i feel but also some others. I think the custom.objects should get priority. I think its moving away from the technical perspective towards design centric tool.