We publish a separate version of our plugin for each major version of Rhino (6 / 7 / 8). Each RHP has its own GUID. In this scenario, how do you suggest sharing document archives between versions? PlugIn.ReadDocument() exposes only data written by a plugin of the same ID. Is there another way to access the archive chunks we need on opening a doc?
Hey @sarg what is the reasoning for new IDs between versions?
I assumed GUID duplication would be a problem, since Rhino 8 attempts to auto-load plug-ins registered to Rhino 7 (for example).
I haven’t done that yet, but I’m looking into it.
I realize that it’s not automatically called like ReadDocument(), but do you mind using
CommonObject.UserData property (rhino3d.com)
which has a Contains method by GUID to check to see if one of your other plugns has persisted userdata?
This would be easier if you always populate some data on the doc so that you don’t have to check every object to see if any object has data.
Are your plugins completely incompatible between versions? You could override the ShouldReadData in the plugin and refuse if the plugin version is different
Not sure I understand these suggestions.
@Nathan_Bossett UserData is a property of CommonObject-inheriting classes like geometry and layers, not the doc itself, no? We are trying to retrieve data that has already been written to the document via the BinaryArchiveWriter passed to PlugIn.WriteDocument().
@csykes the document data we are (de)serializing are perfectly compatible between our plugins. We simply need a way to access it.
Use the same guid. This is how Rhino knows which plugin to attempt to load and call when hitting custom user data during a file read.
As an alternative, you can use user strings and user dictionary on objects which makes the data not be tied to a specific plugin
2 Likes
Yes… I didn’t express myself very well. I don’t know what your exact use case is, for example whether you mark just about everything if the plugin is active or only a few objects in potentially large models.
One comment on the single GUID approach:
I assume you’ve put some thought into what you’re going to do down the road for versioning your own stored data, particularly if down the road you sunset the version of the plugin that supports Rhino V6 (and so on).
Vs your (I think because of the different guids?) separate projects approach for plugins targeting different versions of Rhino, I’m trying to support multiple Rhino versions with conditional compilation but I’ll see whether that continues to be realistic over time.