Creating Addons for my programs

[Cliff Nichols]

I am having a heck of a time trying to figure out how I would go about building a dll to add functionality to another dll that I built. But the problem is neither dll knows how to call functions from the other dll (or if they even exist) until runtime. So I am trying to figure out how to go about this process.

Can someone point me at a simple example that would accomplish this or keywords to search for? (I tried PB Addin, but all I find is compiled dlls to add functionality to PB itself)

[Kev Peel]

You'd want to use LoadLibrary to load the dll(s) and GetProcAddress to find the address of each function you want to call. The rest is easy - a simple CALL DWORD or ASM CALL can be used to execute any function in the DLL. I prefer ASM CALL as it's more flexible when passing parameters - you can specify the parameter list in any order you want, whereas CALL DWORD uses a fixed DECLARE statement. ASM CALL can be much more complex to implement though, depending on the parameter types.

Another thing, you can call LoadLibrary once to load a DLL (ie. at program startup), or you can use LoadLibrary/FreeLibrary only when you actually want to call a function the DLL. This depends on what the DLL is doing.

[Cliff Nichols]

Thanks Kev,
Currently that is what I do (or did rather back when I was adding DLL's, but it got too hectic keeping track of what I had written, and adding code to the main dll so it knew what to call from the dll).

Nowadays I usually just make the addin code an INC and add it to my project. But that means releasing a new version (and version number, so I can keep things straight) and add it to the main code as a part of a new tool (unless really special, then it gets confusing, so I have to compile as something distinguished so I know what the user is talking about when on the phone)

I was looking at adding a function or 2 that could generically loadlibrary, and know how to handle functions I have not written yet, so I can later created dll's as addons and not recompile a new version.

I have ideas, but all a bit foggy at the moment, so I thought I would ask before I try to reinvent the wheel, when the wheel already works

[Michael Mattias]

>and adding code to the main dll so it knew what to call from the dll).

Each add-on = one separate DLL

Each add-on DLL contains a user-defined resource describing the call parameters as well as the export names for each callable procedure in the add-on DLL module.

Main program can handle anything it reads from the add-on DLL.

Once it's working, it's really easy to add more 'extra feature' DLLs to your product line.

But trust me, this is NOT an "I'll knock this off after lunch" type of project. You will also no doubt also go thru several generations of "main" program until you have covered all the possible parameters the add-on resource defines.

MCM

[Cliff Nichols]

But trust me, this is NOT an "I'll knock this off after lunch" type of project. You will also no doubt also go thru several generations of "main" program until you have covered all the possible parameters the add-on resource defines.

MCM...I kinda figured that from my VB days where that is what I did, for addons, but always wondered if I was doing it the hard way or not.

And thanks for the forwarning....I figured it would become a example of "How Generic" is generic, vs just adding DLL's later and let my main app know how to handle it