| Author |
Message |
bdi Nobody
Joined: 21 Oct 2004 Posts: 1646 Location: Chicago
|
Posted: Wed Oct 25, 2006 12:28 pm Post subject: Designing an add-in framework |
|
|
| I'm thinking about creating an add-in framework for my application. I'm not looking at something that 3rd parties can come in and add stuff in, but I want to be able to integrate new features. There are lots of features that would apply to some of my customers, but not all of my customers, and it would be nice to make them optional. Anyone dealt with this before? What types of things do you need to handle to make a modular application such as that? What part goes in the main application, and what goes in the add-in itself to make the link? Thoughts? Brainstorming is welcome. |
|
| Back to top |
|
 |
aschenta *narf*
Joined: 07 May 2003 Posts: 548 Location: Windsor Ontario Canada
|
Posted: Wed Oct 25, 2006 1:14 pm Post subject: |
|
|
I would start object-oriented. Define a class/classes/interfaces that have the outline of what you want to be able to do. Decide what you want to be able to do and what you will need to do it.
If you make the object library available then you can basically do anything you want with a separate library. Provide a way of showing a form (i.e. preferences, settings, options, etc.), a way to execute on demand, a way of using the feature (i.e. a menu item). Possibly a way to define where the feature can be used (which part of the menu it is in).
The only part i'd put in the main application is the stuff needed to track the add-ins (what the user wants) and where to put them. The main app would call the appropriate routine (defined in my first paragraph) and the rest would be handled by the plugin itself. You may see that having a way of giving some type of feedback would be a good idea. |
|
| Back to top |
|
 |
bdi Nobody
Joined: 21 Oct 2004 Posts: 1646 Location: Chicago
|
Posted: Wed Oct 25, 2006 3:35 pm Post subject: |
|
|
So basically we have 2 major functionalities for the main application it seems:
1) Register/Unregister the add-in.
2) Provide a standard interface to the functionalities within the application.
I was thinking 1) might be enough if you passed enough info, but the more I think about it, it would seem that is incorrect. I wouldn't know today what functionalities in the main application I might want to use, and therefore I would need to allow for interfacing to a broad range of them. The big issue that could arise is if I later decide I want to change something in the interface, I will have to fix it in all the add-ins as well. |
|
| Back to top |
|
 |
WannaBe Wiggles
Joined: 22 Oct 2004 Posts: 714 Location: CA
|
Posted: Wed Oct 25, 2006 4:31 pm Post subject: |
|
|
.net http://www.developerfusion.co.uk/show/4371/
vb6 http://www.devx.com/vb/Article/15767
I'd read up on some articles, even if it isn't the right langauge, look at other apps that use plugins see how they work.
Basically You'd have an template interface for each plugin; To make things easier, you could create your Main app in a class form so when you start a plugin you pass it a reference of the main class that could add/remove menu items, query the database, etc.
An app i'm creating is plugin based, but It was hard to figure out an interface to create where vb.net and vb6 could have event hooks, and database access, as well as creating a settings window for each plugin loaded. (my template is hacked to death)
Which reminds me, you could have events when something is changed on the main app through the main class. One of the greatest things with .net is 'Addhandler'
paper is your friend on this subject
When a plugin is loaded I first create the object (they are vb6 class dlls)
then It calls a Start function, passing variables, and return if it failed to start as well as what hooks to be active for itself (its a server app); I couldn't really make hooks from the vb6 class to vb.net functions else I did some functions pointers from winapi, so I skipped that wasn't really needed.
When you want to view the settings it calls the SettingsWindow function, which returns an array of *crap* text defining controls and there positions, etc. (I'd show you the code example but you'd laugh) after that when an event happens on one of the settings controls it passes it to SettingsEvent function on the plugin where it parsers the event and what to do with what.
this was only because vb6 can't access vb.net forms/controls
anywho after that you have many "function_xxx"s which are called with 'CallByName' which are fired for clients connected to the server
the last thing is the Shutdown function. guess what it does  |
|
| Back to top |
|
 |
|
Powered by phpBB © 2001, 2002 phpBB Group
|