Question to the plugin developers

[Ron]

As some of you might know, the use of WM_USER messages can be dangerous as other application might send these and trip girder up badly. Most notiably windows itselfs uses WM_USER+# these days. I would like to switch to a RegisterWindowMessage(..) based scheme. This however means that I'd remove the old handlers in Girder and thus breaking compatibility with the older plugins. I don't want to do that without some input from you guys.

If you want to read up on this issue look at this:

http://www.codeproject.com/dialog/MessageMgmt.asp

[Ron]

Okay so I guess noone really cares what I do :smile:

Then its a decision. Action plugins that use API 5 and hardware plugins that use API 2 must use the new WM_XX messages. I'll be adding this to the API today.

For now Girder will still react to the old and the new messages BUT beware I'll remove the old style stuff around 3.1.1 somewhere.

This also means that some old unmaintained plugins will become obsolete, so if your favourite plugin isn't actively begin maintained post it here so we can get ahold of the developer for the sources.

[Ron]

I was just thinking about the compatibility mode. But this is only going to be here for a short time, I want to get rid of the old API.
So yes there will be a checkbox.

[Ron]

Okay here are the new message numbers in C/C++


static const UINT WM_HARDWAREEVENT = RegisterWindowMessage("9FC3EB47-4ED7-41f2-BDE7-955D1BB05D8E");
static const UINT WM_ACTIONEVENT = RegisterWindowMessage("9971BC49-2B18-428e-BFBE-D899E685F774");

or if you are a delphi developer


WM_HARDWAREEVENT := RegisterWindowMessage('9FC3EB47-4ED7-41f2-BDE7-955D1BB05D8E');
WM_ACTIONEVENT := RegisterWindowMessage('9971BC49-2B18-428e-BFBE-D899E685F774');



The WM_HARDWAREEVENT replaces WM_USER + 1030
The WM_ACTIONEVENT repleaces WM_USER + 1024

<font size=-1>[ This Message was edited by: RonB on 2002-03-19 11:47 ]</font>

[Ron]

BTW, this was the last change to the api. I'm creating a new download category where I'm going to put the updated Girder 3.1 plugins in.

Sorry for the inconvinience but I felt this was needed as it might have given some weird problems in the future ( or now with winXP )

[Ron]

*shrug thinking of DirectX* COM, eh not thanks. Too much hassle for our simple case.

Older APIs are now also supported the only reason that I'm breaking the API is because of the Window message number change, COM would not have made a difference here anyway.

ps. Girder has had backward compatibility for 2 years, plugins from back then still work on Girder 3.0.25. Its time to throw out the old stuff and get on with life.

<font size=-1>[ This Message was edited by: RonB on 2002-03-20 19:21 ]</font>

[Ingo]

how about disabling the old stuff by default, and adding a checkbox that enables them again?
This would allow users to see if their plugins are affected.
Maybe even add a msgbox that pop up while the compatibility mode is disabled, telling the user
1st to enable compatibility mode (and how... just to save support calls ;-( ) and
2nd what to do to be able to use the plugin in future Girder versions...

Ingo

[simonjo]

Why don't you implement plugins as COM objects, this is not so difficult to do on the plugin author side.

And for Girder it would remove the hassle of obtaining a pointer to all plugin functions.

Subsequent API versions can also be supported by additional interfaces in the plugin COM object.