Enumerating currently loaded plugins


#1

Is there a way to enumerate the currently loaded plugins? We’re trying to create a suite of plugins that can interact with each other without having to be known/registered with each other ahead of time, and one way to do this would be to have each of them implement some interface which we then try to cast to, but this only works if we can get a list of currently-loaded plugins to attempt the casts. All I can find is RhinoApp.GetPluginObject, which requires that you know in advance which plugin you’re looking for.

(I can’t actually even get RhinoApp.GetPluginObject to work because I can’t figure out how to set PlugIn.Name or PlugIn.Id, but hopefully that doesn’t matter.)


(Dale Fugier) #2

Rather than enumerating plug-ins to see if yours is loaded or not, it is a better practice to move common code to a shared library or DLL. This way, a plug-in is not dependent on another plug-in. Make sense?


#3

In general, yes, but it’s not just “common code” - the plugins are actually exchanging state information. In broad strokes, what’s happening is that one “master” plugin is exposing a command that, when invoked by the user, grabs state from the other plugins and serializes it. (There’s a corresponding deserialization command.) The plugin “dependency” isn’t a flaw to try to work around, it’s a feature of the whole suite.

I got this to work if the various “client” plugins are known to the “master” ahead of time (by figuring out how RhinoApp.GetPluginObject actually works), but it would be nice to not have to rely on this.


(Dale Fugier) #4

From what you describe, I would think registering delegate functions with some common library would be a clean solution.

See if this example gives you any ideas.


#5

Oh, that’s perfect. I don’t know why I didn’t think to do it that way.