Plugins

[Seth DK]

Untill now I have been suing a quite awkward way of communicating between my Program (Stadard EXE) and a plugin (ActiveX DLL). I't not a good way I am currenctly using and I want to make it better.

Recently I studied how to make plugins for VB etc.
It seems you can create a VBIDE object and then use many various functions, properties etc. etc. through that plugin.

I can do that too in my Plugin system but it's only one-way communication and only "first level".

Fx. I want the plugin to be able to bind an object, say "MainProgramObjectThingie" to the Standard EXE (does it help if it's a ActiveX EXE?) and thereby be able to issue commands like...

MainProgramObjectThingie.Menus.Add "Test plugin"
MainProgramObjectThingie.GetCurrentFileName

...and so on

As for now it only works the other way around. The main program can call the Plugin and issue commands like

PluginObjecjThingie.ShowAboutBox

I would like to have it work in both directions so that I don't have to use the SendMessage API each time the plugin will send information to the Main Program.

HELP ANYONE?!?

[Edneeis]

Here is the method I used, it'll be a little hard to explain:
I made the application an ActiveX Exe that runs like a normal exe but has some classes exposed. The classes allow me to share the running instance of the application with any objects that connect to it via the exposed classes. Basically there is a Manager/Connector class that all the objects go through and then they communicate with the app via a plugin class they all implement. This allows them to receive events raised by the app. I also used an index scheme to have the plugin add menu items and then from the dll it can map a function to the menu click event using callbyname. So basically if someone goes to make a plugin then just add a reference to the Application exe and then add the plugin manager object to whetever class they are making and they can communicate with it.

PS: I like the way your app does the options for the plugins, current I just had mine set to show a form from the dll itself, but yours looks better.

[Seth DK]

I forgot to say that I found out myself too! Thanks for the help anyway! I did it almost the same way you did :-)

PS: I like the way your app does the options for the plugins, current I just had mine set to show a form from the dll itself, but yours looks better.

So you downloaded SpeedEdit? How did you know I was referring to that one? Perhaps it's actually the only program I have uploaded to my website yet? lol

It basically works this way (i fegured you might wanted to know):
In the DLL I make the Form with no borderstyle, caption etc.
Then I do like this (code goes in the EXE)

lHandle = objPlugin.OptionsEntry.Show

This way I get the hWnd of the options Form from the plugin

Then I create (at runtime) a picturebox with no border and use some API calls to make the options window "belong to" the picture box.

Piece of cake (admitted it took some time figuring it out)

[Edneeis]

Cool, thanks for the options code.

[Seth DK]

You're most welcome!

I can give you the exact APIs if you wish!?

BTW, I just took a look at your website and I think it is interesting. Especially the drop-down autocomplete class.
I myself have been working a little on a similar feature for SpeedEdit but I never succeeded. Perhaps I can get some inspiration from your work
I'm going to try it out for sure...

Also, the docking form thing looks great! Too bad it's not downloadable yet..

You rock man

[Edneeis]

Thanks, is it the SetParent API?

I have the code for the dockable forms but you could only have one dockable form so I took it off to fix that.

[Seth DK]

Yes it is the SetParent API.

I also use the SetWindowLong API to prevent that the options window looses focus when the other form is activated:

lWindowStyle = GetWindowLong(lWindowhWnd, GWL_STYLE)
SetWindowLong lWindowhWnd, GWL_STYLE, lWindowStyle Or WS_CHILD

[Edneeis]

Ahh thats cool I didn't know about the Child issue thanks.