UserData is broken for geometries. It wasn't 1 month ago

Hi everyone,
I’m experiencing an issue with Rhino 6. I have a C# plugin that generates some information and stores it as UserData in the geometry. As you can see from the attached snippet, the data is stored into file:

problem is, when I reload my 3dm file, said data is gone

I made a new 3dm file to test this and the implementation of said class is something we haven’t touched since Rhino 5, in fact, I can tell for sure that it was working up to 6.4+. I tested this both in 6.8 and 6.9 with no avail.
Digging into your issue tracker I found this
which I believe is somewhat related. Can anybody please investigate this? I’m positive that back when the bug was reported my way of dealing with UserData was working (at least for me). Maybe something got broken around 6.4-6.7?
I do some heavy computation behind that data, which is tied to a specific surface (constrained optimization on the sampled surface), so my customers really needs it to store it.
Any help appreciated.

That happened to me once.

is save plugin data checked?


@Riccardo_Di_Lorenzo I noticed last week that RhinoObject.UserData was not writing when the document closes and created a ticket for it here. It could be that GeometryBase is having the same issue.

Does the UserData stick for you if you apply it to Attributes.UserData?

Hey, yes, I checked the box. I think the problem is more on the retrieval than the saving. Though without the source it’s of course impossible to tell for sure.

Dear Trav,
I checked what you asked and I can tell you that nothing seems to have changed, even though my UserData.Write implementation seems to call ArchivableDictionary just fine. Problem must be somewhere in deserializing it. I’m quite surprised this flew under the radar for a bit, maybe not many devs embed data in shapes afterall? No criticism here, just genuinely curious.
after saving:

after loading:

Hey @dale, sorry if I’m being antsy, but do you have any update to share regarding the issue? I’ve been looking at your issue tracker:
and I can tell it’s not being worked on. Issue is, the current state of affair breaks the workflow for my users… I’ll be glad to hear anything from you guys “on the other side”

Hi @Riccardo_Di_Lorenzo,

Is it possible to get a simple project sample that isn’t working for you?


– Dale

Hi Dale, thanks for your answer.
Not sure if you are referring to a “Rhino project” or a “C# project” I made you both. Weirdly enough with the example project I’m able to retrieve the UserData I wrote in a previous session, but to my defense, the data we write with our plugin is far larger than that. This, other than reassuring me that I’m not a complete idiot, makes me wonder if you made any changes in the serialization/deserialization from your side that broke our Read/Write, because we haven’t touched anything on our side. I don’t get any relevant exception when opening the file, so the faulty part(s) of the deserialization are invisible to me.

In the zip you’ll find:
A Rhino document with 2 explainatory pics, where you see that both objects hold UserData, but if you open the 3dm file right now only one will show its data (only the one coming from the example).
The compiled version of the example plugin.
The source of said plugin (very basic, a couple of classes).
Thank you very much (7.1 MB)

Hi @Riccardo_Di_Lorenzo,

A couple of things:

1.) If you don’t implement OnUserData.OnDuplicate, then your user data won’t be copied with the object it is attached to is copied (which happens all the time).

2.) I don’t understand why you are using an ArchivableDictionary and not just calling the Write and 'Read` members on the binary archive.

I’ve attached a project for you to review. (26.2 KB)

– Dale

Hey Dale, thanks for the project. I try to run the plugin you wrote with the following results: (6.1 MB)

Maybe I’m misunderstanding the meaning of that bool “saved in file”?
It also looks like that writing UserData without touching the object doesn’t trigger the save event, as you can see from the video, I can open a new file or exit Rhino without being prompted, you guys might want to look into that.
We have an ArchivableDictionary because our object is a collection of strings, arrays and some custom structs, so we create a dictionary of “stuff” and then upload it (pass me the term) into the object’s userdata.

Regarding my problem, I lifted your Read/Write implementation and used in my plugin instead of my version with the result you can see in the video. AKA: Writing the userdata works just fine, the problem is that the Read() function is never called! This happens with both mine and your implementation, apparently. (4.4 MB)
Am I doing something wrong?

Scratch that Dale, the problem was on my part, I did not realize that I fudged up in the implementation of the parameterless constructor of my class holding the data I wanna store. Thanks for taking the time.
I think my first point is still valid though.

RH-48844 is fixed in the latest BETA