Creating ADD ONS
in [Visual Basic]
|
From: mayayana on 13 Feb 2010 09:13 Other options: * I wanted to split off my settings functionality into a separate applet at one point and put it all into a DLL. It worked out well. * I use Olaf's 20KB DirectCOM.dll for no-reg loading on all Windows versions. * While a text file listing classes might be fine, it's also feasible to just have a "plugins" folder. An add-on installer would put new plugins there. You can read the typelibs directly (with oleaut32.dll functions) to find creatable objects, load them with DirectCOM, and "ask them" their names, functions, etc. -- no reg., no extra files. (Then there's just the "little" issue of how the main program integrates unknown plugins. :) > Make ActiveX DLL's and let your app read a text file containing their names, > then use CreateObject() to load them. Example: > > StockChartAddon1.Class1 > StockChartAddon2.Class1 > StockChartAddon3.Class1 > >
From: C. Kevin Provance on 13 Feb 2010 11:48 "Larry Serflaten" <serflaten(a)usinternet.com> wrote in message news:%23yFw4TIrKHA.6064(a)TK2MSFTNGP02.phx.gbl... | I did something similar with VB4. I'd have to play with it again to | get the specifics on how it all fit together, but from the best of my | recollection: | | You'd use LoadLibrary to get the module into your address space | You'd use CreateObject to get the object you wanted to use | You'd release the object(s) and use FreeLibrary when done | | If all the add-ins had a class named Info, you could use that class | to give the main app the information needed to use the library | (menu item text, descriptions, class names, etc). I think in my | own project the info class was actually an implemented interface | by a class called 'System' so that all add-ins were accessed in the | same way, as far as getting the info details. | | If all the add-ins are deployed to a predetermined location, you | could loop through that folder to pick up the information at | start-up.... Nice. Very cool. I'll have to try that sometime. <g>
From: GS on 13 Feb 2010 12:32 This is pretty close to what I'd be looking to do! I already do use a 'Plugins' folder for my MS Office addins that support plugins, and just load each one directly from the folder. Thus, I don't see much point in using a text file for listing their names but that might be a good option for someone else. I'd have to weigh whether to use ActiveX EXEs or DLLs, but I would be very interested knowing where I can obtain the DirectCOM.dll you mention. That sounds like a handy tool! <<Then there's just the "little" issue of how the main program integrates unknown plugins>> Any suggestions would be greatly appreciated. What I'd like is to have each addon add their own menus to the host app's menubar. I suspect a structured methodology should be used and so suggestions on that are certainly welcome and appreciated. Kind regards, Garry
From: GS on 13 Feb 2010 13:17 Hi Larry, Thanks for your input! This sounds like an interesting approach as it's similar to how I accomplish using plugins with my MS Office addins. I'd like to be able to do the same thing with some VB6 apps. I suspect you developed some kind of structured methodology for this; --can you elaborate any further regarding the specifics as to how it all fits together? Do you know of any example projects I can study? Kind regards, Garry
From: Nobody on 13 Feb 2010 14:38
"GS" <GS(a)discussions.microsoft.com> wrote in message news:%230aZAKNrKHA.5940(a)TK2MSFTNGP02.phx.gbl... > where I can obtain the DirectCOM.dll It's part of RichClient Toolset here: http://www.thecommon.net/3.html There is a description when you click on "DirectCOM" on the left menu. |