How to get GeometryBase back from ArchivableDictionary

As in topic there is method - https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Collections_ArchivableDictionary_Set_3.htm

But how to read it back? There’s no Get equivalent?

I think the [] operator should work.

string key;
GeometryBase gb;
ArchivableDictionary dict;

dict.Set(key, gb);

GeometryBase fromDict = dict[key] as GeometryBase;
if (null != fromDict)
{
  // continue with deserialised geometry
}

https://developer.rhino3d.com/api/RhinoCommon/html/P_Rhino_Collections_ArchivableDictionary_Item.htm

1 Like

Indeed thanks i didn’t though about that :sweat_smile:

@menno If this wouldn’t be a problem for you (as I saw you know a lot about serializing/deserializing stuff in Rhino) I would like to ask you how would you approach to serializing custom structure let’s say simplified example - something where you are nesting classes - like:

class Person
{
    string Name;
    List<Car> OwnedCars;
} 

class Car
{
    int ProductionYear
    Engine CarEngine;
}

class Engine
{
    double Capacity;
}

Read/Write in each? Approach to versioning / or just simplifying to dicts? Any other tips from your know-how?

Hi @D-W,

I would…

Have a look at the SampleCsCustomClass class in the SampleCsSerializeClass.cs out in the developer samples repository. Perhaps this will give you some ideas.

– Dale

Thanks @dale for input. To be honest i dont like serialization of this kind since as soon as class definition (fields) will change byte arrays will fail. I rather wonder how to keep it in dictrionaries since lack of key can be handled without any problem but this way i guess read/write everywhere won’t work i understand that archive dict without key or same key will overwrite previous. So top level should have read / write and nested ones should return then other arch dicts to nest them in top level dict?

I agree, which is why we encourage versioning your data.

SampleCsUserDataObject.cs

Archivable dictionaries have their use. But there comes a time when you need a more control. Then it’s time to write and read your own user data.

– Dale

Yup i saw this earlier. I just wonder as sample says user data is attached to the object - should i use it as a guide also for doc data or rather lean towards simple/string doc data?

However i still cannot grasp how this clarifies my nesting “example”. Does UserData is the highest abstraction level for serializing and you just recommend it instead of operating on dicts?

Hi @dale I don’t know if I should continue this one or start new I’m occurring random issues when ReadDocument as you guided I made methods read/write for needed classes but those classes objects are registering to Doc events when created and I figured out that in most cases those registrations are lost for those objects not sure why more weird is that lets say in 20-25% of loads those are ok. Any ideas?


Solved. I lost track of events and missed the Dispose method to deregister those that’s why it failed on load. Reminder for future adventurers - be 100% sure you keep track of all registered events!

Yes please.

– Dale

No need my fault. As i updated above i didnt unregistered objects of one class from events so i had issues when those handlers cumulated. Fixed and its doing great and again thanks for tip on read/write inside classes it is doing its job perfect and is easy to maintain :slight_smile: