From: GS on 13 Feb 2010 15:48
Thanks! I'll surely get into looking at this...
From: mayayana on 13 Feb 2010 17:20
Olaf Schmidt wrote DirectCOM.dll. He's a
regular contributor here. His DLL wraps
the loading of an object in a COM DLL. You
just need code like the following example:
Private Declare Function GETINSTANCE Lib "DirectCom" (FName As String,
ClassName As String) As Object
Private Obj as Server1.Class1
'-- To create the object:
Set Obj = GETINSTANCE(App.Path & "\plugins\addon1.dll", "Class1")
I put DirectCOM.dll in the program folder and
have had no problems with it from Win98 to Win7.
The download is at Nobody's link.
> <<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.
Larry Serflaten's description sounded doable to
me, but I've never dealt with creating a flexible
plugin design like that. I'm imaginging something
like the Firefox plugin manager window, where
you could load name, description, icon as provided
by the public class in your plugin DLL. I suppose
that if you always used the same class structure
then you wouldn't need a text file or the loading
of typelibs. You could just create the known class
from each DLL in the folder. And since VB DLLs use
the file name as the server string of the ProgID, it
*could* be as simple as just enumerating the plugins
folder files and then loading them by name:
plugin1.dll (public class: plugin1.AddOn)
plugin2.dll (public class: plugin2.AddOn)
From: GS on 13 Feb 2010 18:27
Thanks very much for your input! I already downloaded the RichClient
toolset (..an absolutely brilliant work!) and it looks like it'll take
some time to digest.
Yes, Larry's scenario looks very doable! I'm hoping to get enough input
to devise a structured methodology that I can apply with consistency. I
already have this figured out for my MS Office Add-ins, but that's an
entirely different context. Simply put, my MSO Add-ins support plugin
add-ins that are used to add user-specific features as used with the
core Add-in. For example, MyCoreAppAddin.xla will iterate the \Plugins
folder for other XLAs, and load any it finds. These in turn add menus to
the core's toolbar (or menubar). The host (MS Excel in this case)
manages the menuitems and which XLA they belong to.
I hope to be able to mimic this in VB6 apps! Similar to what Mozilla
does with Firefox or Thunderbird, I would include a 'Plugins Manager' to
handle installation and provide options for whether they always get
loaded at startup and so they can be manually loaded (if not already) as
needed. Olaf's DirectCOM.dll will fit perfectly here!
The major issue for me will be how to get the plugin menus working
seamlessly within the core app. I consider myself a novice at VB because
my experience with it is limited. Thus, I rely heavily on input from the
more seasoned developers, books, code samples, and my own determination
to achieve the intended result. I started with MSO VBA and so is why I
find myself trying to learn VB6. This forum has been a great resource
toward that learning process, and I'm extremely grateful to all who
contibute to that!
From: Larry Serflaten on 13 Feb 2010 19:34
"GS" <GS(a)discussions.microsoft.com> wrote
> 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?
Unfortunately, some old projects from the 16-bit era did not get transfered
to my 32-bit machine(s). While I had an interesting little romp through
some old floppies, I did not find the project that had the add-on capabilites.
Keep in mind, it was a pretty straight forward affair. You decide what you
need in your main app to present the add-ons to the user, and encapsulate
that in a class that all add-ons have. It would appear that using DirectCOM
as was suggested elsewhere, will make their use even easier than I had tried.
From: GS on 13 Feb 2010 20:09
Thanks again! Wow.., -I really appreciate that you took the time to
search for that old project.
Since I don't really know much about how VB works, how it all comes
together is going to need all of your good luck wishes. I'm afraid I
didn't express myself very well the first time I put this to everyone
and so I'm glad that it has repeated via another OP because I feel the
concept is better understood by the other readers this time around. I
can't tell you how much I wish I had gotten into this programming stuff
years ago; ..this community makes it a nice neighborhood to visit!