From: GS on 13 Feb 2010 15:48 Thanks! I'll surely get into looking at this... Kind regards, Garry
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! Kind regards, Garry
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. Good luck! LFS
From: GS on 13 Feb 2010 20:09
Larry, 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! Kind regards, Garry |