Creating an application that can have Add-Ons

[Raydr]

I've been brainstorming, and looking around, and I'm not sure how to go about doing this.

I want to write a program with which I can create add-on's to go with it.

Or maybe more appropriately, a program that does nothing until addon's are activated.

I want the addon's to be in .dll form. I was thinking maybe this is how I'd do it:

When the user of the program selects the addon's to be used, the program will call a "AddOnInit()" function or something in each of the DLLs. But I'm not sure how to go doing this....VB doesn't allow declarations to be created at runtime!

The .dlls will actually be just full programs themselves, except that they have activated by my "master" program.

Anyone have any ideas on how to go about doing this? Suggestions?

Any help or pointers would be greatly appreciated! I'm sure there are a lot of people who could use this information also!

Have a nice day!

[Raydr]

Heeeeeelp!

[Jimlin41]

You could write the declaration code but have the path of the dll as a string. Say you make several dll files and they're all in your "AddOn" folder. Let the user select a DLL from that folder through a file list box or something of the sort.
The path to the dll could be something like this:

App.Path & "\Addons\" & File1

File1 being the current selection in the file list box.
Hope this helps.

[Raydr]

You can't declare on the fly! It wants a string constant as far the file file goes.

Also, multiple dlls would need to loaded, which means if I did that I'd have to create a different initialization routine for each dll, which would suck!

[Sam Finch]

How are you at Subclassing and Other API Methods.

you need an ini file or a key in the registry with the names of your plugins as standard EXE Projects with a commandline as the hWnd of the Main Window in your app (I'm fairly sure you can add a command line in the shell command by putting a space after the file name and writing the command line there eg

Shell "MyPlugin.Exe" & " " & Cstr(Me.hWnd)

, then subclass your app and have some user messages you can send to your app, then use the user messages to get Data In and out of your app.

[Paul282]

Why bother with DLLs?

Lets say that the main program is a menubar and the addons are buttons to the add on program.

The master starts and reads a registry file of the number of addons and the button icon path and the exe path.

then dynamically creates a menu bar with that many buttons with those icons, when you press a button it shells those addons (apps)

Then when you install a new add on you increment the appCount in the registry and add the path and icon for the new add on.

have it manually configurable from the main program too as a fallback

or some adaptation thereof

[Raydr]

Just took a cold shower and some of those ideas occured to me.
I guess I wanted to have a more "professional" look, but I figure I can always rename the files on the fly.

I think what I'll end up doing is a combination of the last two suggestions.

I don't want the "addons" to be able to be run manually, so I'll probably have it require a special switch to run.

I'm not very familiar with Subclassing, and I don't know if this has much to do with it, but what is the best way in this case for two programs to communicate with each other?

Keeping in mind that these are addons, the MAIN program needs to communicate with these sub programs, such as query the subprogram's name, description, telling it to quit, etc.

Any ideas on how to do this most efficiently/effectively?

[Sam Finch]

Subclassing and sendmessage is the way that windows programms are meant to talk to each other, You should be able to find a tutorial on subclassing somewhere around here, It's something you should learn, It's very useful and it's how you should do this, when you send messages to the window you need to subclass that window in order to handle them, for example if you want to draw on the main app you should send a message with your own constant defined , something like UM_GetDC, the window procedure would then return the DC of the main window so that your plugin can write to it, unless you think of something very clever I don't think you can do this without some API Calls.

(Or you could use OLE somehow but apparantly it's really hard to get going.)

[Paul282]

Try taking a look at "Creating an ActiveX EXE Component" in the MSDN.

There are a series of examples of a Coffeepot and coffee monitor program and how to get them to talk to each other even though they run as different processes.

I remember playing with this some time ago. The tutorials are quite long but they go into quite soem depth on how to do this.

Paul

[Sam Finch]

I thought the point was to create a program that could run an addin with an unknown iterface, or attatch multiple activeX Exes/Dll without knowing their filenames at compile time.

[Paul282]

errr,

You could be right, the ActiveX Exes sort of work in the other direction really don't they...

Doh