Hi all,
I’m writing a custom analysis plugin that is intended to store its data in an object (the geometry of which is significant in the analysis), but I’d like this object to be inaccessible if the 3dm file is opened by a user who doesn’t have the plugin installed. Here in my early phase of development I see that if I don’t add a callback to the EndOpenDocument event that would cycle through all the objects in the document to possibly convert any custom objects (described here), the custom object is still visible as its base type.
Is it possible to have this base object not appear if the associated plugin is not loaded?
Also, I suppose the only location to store my analysis data is in a RhinoObject.Attributes.UserData entry, since this is what helps me find the data later (using Find(typeof(MyCustomUserData)) )? Perhaps not, as indicated in this thread. (Though I don’t have a compelling reason for doing it this way rather than using the UserData interface, except perhaps that the analysis data is attached only to the custom object and to no other objects.) It’s not clear to me, though, how the custom class written to the 3dm file would be found in order to be loaded again, unless the BinaryArchiveReader is only allowing access to the data created by the plugin with my own GUID? (Is this the answer to my first question above?)
Thanks!
Also, keep in mind that the Serializing non-Rhino classes to a Rhino File thread outlines an alternative method to user data. And this method isn’t how most developers implement user data (IMO).
That said:
Why. Why do you want to do this? What problem does this help you solve?
No, sorry.
User data can be store on either the geometry or the attributes of a Rhino object.
All you do is just iterate through the document until your find the objects that have your data. Let me know if you need help with this.
Hi @dale ,
Thanks very much for the really quick reply.
I’d like to add a(n admittedly thin) layer of protection to proprietary information in case a 3dm file is accidentally shared. So it’s definitely not a necessity.
I’ve seen several examples of doing this, thanks. Though I wonder what the difference is between adding an event to RhinoDoc.EndOpenDocument and overriding PlugIn.ReadDocument - I see the ReadDocument has a BinaryArchiveReader, and I suppose I could cycle through the DocObjects in that function override - is there any particular advantage to iterating through the objects in an EndOpenDocument delegate?
Thanks again, also for helping satisfy my curiosity.
Dan
If you attached user data to an object per this method, then your plug-in will be the only tool that has access to this data, as you are the only one who knows the format of how the data was written.
PlugIn.ReadDocument is only called if your plug-in writes document user data. It will not be called if your plug-in writes object user data.
If you are looking to collect your user data when a file is opened, best to do this in a RhinoDoc.EndOpenDocument handler.