Writing a plugin system
-
I am doing research for a potential product that my company is thinking of starting on, and one of the features we would like to implement is plugin capability. I have looked around the web and haven't found much information on different ways to implement such a system. Does anyone know of an article or book that can explain the basic steps on doing this? Our main goal would be to have this "dummy" application that would keep track of what plugins are registered and execute a users commands on those plugins. Any information would be greatly appreciated. Thanks Zac
-
I am doing research for a potential product that my company is thinking of starting on, and one of the features we would like to implement is plugin capability. I have looked around the web and haven't found much information on different ways to implement such a system. Does anyone know of an article or book that can explain the basic steps on doing this? Our main goal would be to have this "dummy" application that would keep track of what plugins are registered and execute a users commands on those plugins. Any information would be greatly appreciated. Thanks Zac
If you're into COM, define an interface for the plugin and check all DLLs located in some predetermined plugin directory (a plugin is simply added to the system by copying its DLL to this directory). If you don't lean towards COM, substitute the interface thing with:
-
An abstract class defining the functions a plugin has to implement (important: define the destructor as virtual.)
-
A common "creation point" all DLLs are supposed to provide accessed with
GetProcAddress, just like this:typedef CPluginInterface * (WINAPI * PLUGIN_CREATOR)();
...
PLUGIN_CREATOR * plugin_creator=(PLUGIN_CREATOR *)GetProcAddress(hPluginDll,"Creator");
CPluginInterface *plugin=plugin_creator();
... // use the plugin
delete plugin;Internally, creator functions just create plugins with
new.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
-
I am doing research for a potential product that my company is thinking of starting on, and one of the features we would like to implement is plugin capability. I have looked around the web and haven't found much information on different ways to implement such a system. Does anyone know of an article or book that can explain the basic steps on doing this? Our main goal would be to have this "dummy" application that would keep track of what plugins are registered and execute a users commands on those plugins. Any information would be greatly appreciated. Thanks Zac
for my stuff, i just defined a COM interface and told plugin writers "implement this interface, name it thusly and put your plugin DLL in this folder". then, to see which plugins are available, i just scan the folder and attempt to Create an instance of each DLL. it works well. people can write plugins for my stuff using any language that can create an IDispatch interface (this includes the biggies, VB and VC). it is somewhat ugly to have to scan a folder, but it was the easest way to go. there is some COM interface that you can implement that tells the system "yes, i implement this other interface". that would have allowed me to use yet another interface to query the system to see which components implemented my plugin interface, but there were difficulties getting VB to implement a non-IDispatch interface. so, i went with the scan-the-folder option. -c
Conscience is what hurts when everything else feels good. Smaller Animals Software, Inc.
-
If you're into COM, define an interface for the plugin and check all DLLs located in some predetermined plugin directory (a plugin is simply added to the system by copying its DLL to this directory). If you don't lean towards COM, substitute the interface thing with:
-
An abstract class defining the functions a plugin has to implement (important: define the destructor as virtual.)
-
A common "creation point" all DLLs are supposed to provide accessed with
GetProcAddress, just like this:typedef CPluginInterface * (WINAPI * PLUGIN_CREATOR)();
...
PLUGIN_CREATOR * plugin_creator=(PLUGIN_CREATOR *)GetProcAddress(hPluginDll,"Creator");
CPluginInterface *plugin=plugin_creator();
... // use the plugin
delete plugin;Internally, creator functions just create plugins with
new.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I have no objections to using COM, though, some of the plugins may need the ability to add menus or views to the application -- is there an easy way of implementing that? Thanks again Zac
-
-
I have no objections to using COM, though, some of the plugins may need the ability to add menus or views to the application -- is there an easy way of implementing that? Thanks again Zac
Well, that very much depends on the structure of your app. Usually, it is better to have the plugins provide the functionality and data and let the app itself control the GUI (for instance, the plugin can provide a command name and a command callback and it is the responsibility of the app to insert the command into the main window menu). If you're after a full-fledged doc/view architecture, I guess you're heading a lot of work for it to function based on a plugin system. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
-
Well, that very much depends on the structure of your app. Usually, it is better to have the plugins provide the functionality and data and let the app itself control the GUI (for instance, the plugin can provide a command name and a command callback and it is the responsibility of the app to insert the command into the main window menu). If you're after a full-fledged doc/view architecture, I guess you're heading a lot of work for it to function based on a plugin system. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Okay, here is the idea I came up with. Since we do not want to have to recompile the app everytime we add support for a new hardware product we produce, we have this "shell" app that simply scans for plugins/ActiveX controls in a certain directory (or you select them from the app . . .) And the app will then make the features available in the plugin available to the user (ie if it is a communications plugin for the serial port, a menu would be appended to the top-level menu called "Communications" with options like "Configure", "Connect", and "Disconnect"). The whole idea is that we would only have to redistribute the application if we found a bug in it somewhere (making it easy to upgrade by simple adding new features via plugins that can be made available). The other benefit is that the application itself is worthless without one or more plugins (since it only functions via plugins), which would also make it very easy to give out demo versions (of some of the plugins) and give them the full-fledged application to evaluate. Thanks again Zac