From: mayayana on
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
> then use CreateObject() to load them. Example:
> StockChartAddon1.Class1
> StockChartAddon2.Class1
> StockChartAddon3.Class1

From: C. Kevin Provance on

"Larry Serflaten" <serflaten(a)> wrote in message
| 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
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,

From: GS on
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,

From: Nobody on
"GS" <GS(a)> wrote in message
> where I can obtain the DirectCOM.dll

It's part of RichClient Toolset here:

There is a description when you click on "DirectCOM" on the left menu.