Can one inherit from several subclasses of CRhinoPlugin?

Hello Rhino developers.
I would like my TRmesh plugin (which is a fast and hopefully easy-to-use tet mesher and re-mesher available on food4rhino) to be declared as

class CtrmeshrhinoPlugIn : public CRhinoUtilityPlugIn, CRhinoFileImportPlugIn {
// etc etc

(and maybe other subclasses as well) so that it can also read in tetrahedral mesh files through an official Rhino dialog, not just my own generic MFC style CFileDialog. It builds fine after implementing all required overrides of virtual functions, but I understand that the in-built Rhino plugin loader will take the singleton object, call its method

virtual plugin_type CRhinoPlugIn::PlugInType 	( 		) 	const

and then cast it to the appropriate subclass of CRhinoPlugin according to what that function thinks the plugin’s “PlugInType” is. This mechanism seems to preclude inheriting from several subclasses of CRhinoPlugin, which would be a pity because it would be great to have a few tet mesh formats added to Rhino’s read-file dialog so that it can be remeshed by TRmesh. Is there any way to make it work, by some magic?
TLDR: How to make a CRhinoUtilityPlugIn, as opposed to a CRhinoFileImportPlugIn, add file types for import, if multiple inheritance is not provided for by Rhino’s plugin loader mechanism?
Cheers, Mathias

Just derive from CRhinoFileImportPlugin. That contains all of the functionality of a utility plugin with the addition of file import.

Thank you very much for the swift answer. Doing it that way would surely solve that particular problem. However, it would make TRmesh appear with the “import file plugin” icon in the list of plugins and so on - and that will make users misunderstand the plugin’s purpose. Importing files is just a small extra functionality but the main functionality is to generate meshes, and I need to make sure it is communicated clearly. Marketing the plugin is already hard enough and I can’t afford to have wrong icons. I apologize if that seems a little peculiar.
For now, I guess I’ll just have the import/export buttons of the main plugin dialog open raw MFC style CFileDialogs where I can set the type of accepted file, unless I find a way to register file types from a general utility plugin. That way, people can import/export but not with a Rhino dialog, and not from Rhino’s “open file” dialog.
Some day, it seems I’ll then have to write an extra plugin for registering “.mesh/.meshb” file types for import with Rhino’s “open file” dialog - and yet another one for export, and those extra import/export plugins will then require TRmesh and open its dialog.

Hi Matthias,
You can change the icon used for your plug-in to a custom icon. I still recommend deriving from a CRhinoFileImportPlugIn.

Ok ok ok, I see. That means any plugin that wants to register a file type needs to be a CRhinoFileImportPlugin. Just realized that even Grasshopper presents itself to Rhino as a “FileImportPlugIn” - the C# equivalent!
All fine and good, but it still leaves me curious: what if someone wants to also export files, of all things, as in receiving an honorable mention of their plugin’s file type in Rhino’s "Export as … " dialog? It seems that a CRhinoFileImportPlugIn can’t do that. And what happened to all the other possible plugin types mentioned here? Just asking out of curiosity.

You currently have to write two plug-ins if you want import and export functionality. I’ve always wanted to modify our SDK to allow for opting in to different features, but that task has never made it to the top of the list of things to work on.

1 Like