UserDictionary only saved to file when saving twice

Hello, I’m working on a plugIn and have a bug while serializing to an InstanceDefinitions UserDictionary using the UserDictionary.Set(key, IEnumerable<byte>) method:

I am storing some custom data as a byte array during the plugins WriteDocument overload one the UserDictionary of an InstanceDefinition and read that out again after opening the file. This works fine, but only if i save twice. If I save only once, the data is not saved to the .3dm file.

I can step through the code in Visual Studio and see that the the UserDictionary is updated and if I read out my value from it before saving it is the correct and updated value. If I save and then re-open, the changes are gone. Saving twice will properly store the changes into the rhino file.

It seems like rhino finds an old version of the InstanceDefinitions UserDictionary while saving, which somehow does not happen when saving twice.

I’m a bit stumped, has someone encountered this before? Is there a flag I need to set so that rhino does not use cached values but instead does a full save?

Thanks in advance for any advice.

You may need to use dict.CommitChanges() - I’m not sure but it may help?

Hi @menno , thanks for the reply!

Sadly neither UserDictionary nor ArchivableDictionary have a CommitChanges method.
Also since I’m storing the data on the InstanceDefinition I’m out of luck there, too since this also does not have a CommitChanges method…

From the documentation it seems storing data to the UserDictionary should just work, since it is the recommended way as opposed to storing custom UserData derived classes and handling serialization myself.

It is recommended to typically use the User Strings or the UserDictionary on an object since the data is automatically serialized for you and it is easily shared between plugins and scripts.

I’m also still stumped as to why it just works when sving twice, might well be an error on my end.

Yeah, looks like CommitChanges method is something from the past, can’t find it anymore. It sounds like a bug to me, maybe @dale can help here.

just a guess: Maybe the WriteDocument is the wrong event / timing (to late) ?
did you try to use a BeginSaveDocument (documentation) handler instead ?

1 Like

Thanks so much @Tom_P !

I tried changing the timing like you suggested and it indeed now works perfectly!

Since I literally only changed the timing from WriteDocument to BeginSaveDocument and there is no way to infer this is needed from the documentation, I would still consider this a bug, at least at the documentation level @dale .

Dear @lando.schumpich
I agree that the documentation could a bit more clear about this.

There is a sample with all events - sorry i did not find it, when i first answered your question.

As fare as I understand - if you use an Userdictionary, belonging to any CommonObject for example your InstanceDefinition - this is (called) Object User Data. Seams like BeginSaveDocument is the last moment where you can change (“3dm” / Common-) Objects / “the open document and its entities”. Of course writing those Objects to the File is handled by Rhino.
WriteDocument seams more like directly allow the plugin to interact with the BinaryArchiveWriter, that is passed to the WirteDocument- Function. (and to late to modify the .3dm document Objects) - So the Plug-in can write what ever data it wants to the File. - but has to do this in an active way, with one or more of the Write*() functions.

I would not call it a bug.

1 Like