Girder 3.1 changes -> Plugins

[Ron]

No I think that is it.


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

[Ron]

This is what i've written about it in the API documentation

1 New Message numbers
Girder expects to receive the following messages

static const UINT WM_HARDWAREEVENT =
RegisterWindowMessage("9FC3EB47-4ED7-41f2-BDE7-955D1BB05D8E");

static const UINT WM_ACTIONEVENT =
RegisterWindowMessage("9971BC49-2B18-428e-BFBE-D899E685F774");

The WM_HARDWAREEVENT should be sent by an Hardware plugin, the WM_ACTIONEVENT should be sent by an action plugin.

WM_HARDWAREEVENT is the replacement for WM_USER+1030.
WM_ACTIONEVENT is the replacement for WM_USER+1024.

2 New API version

Action plugins must use API version 5, Hardware plugins must use API 2.

3 New Registery location

The plugins now save to HKEY_LOCAL_MACHINESoftwareGirder3

4 Don’t use the old i18n_translate

Don’t use the old i18n_translate function anymore. Use the I18nTranslateEx function.

5 Action plugins may leave out init_dll

Action plugins no longer have to supply the init_dll export. It serves no function anymore. init_dllex must be supplied.

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

[Ron]

Thanks for the corrections, I'll add them.

It should be 'setsupportex' and 'command_execute_ex'

command_execute is depreciated.

I realise that this seems inconsistent as well, someday i'll make the naming good, not now. Don't want to upset you guys to much by renaming everything :wink:

Yes you can use the same string for in and out, BUT! sizeof(str),.. i'm not sure if that returns the allocated length of the buffer,.. you'll have to check that.

[Ron]

typedef _BOOL (WINAPI *PParseGirderRegEx ) ( PCHAR orig, PCHAR szstore, int size);

[Ron]

Well, I considered removing the old stuff, but since we have such a large amount of plugins that still depend on the old api's I'll leave it in. At least for the time being.

Are there tools to export a key and re-import the registery key ? That might solve the problem. (Regedit ?) Alternativly, if your plugin doesn't find data at the new location it could open the old key and save the data at the new key....

-Ron

[Ron]

Jo, yes that is what I said :smile:

[Mark F]

I'd like to gather all the changes required to plugins to work under Girder 3.1 in this thread. Perhaps this could be added to the developer documentation at a later time.

Action interface = 5 (some naming and functional changes for entry points)
Action message (to execute a command) value change
Hardware message (to send an event string) value change
Event strings can have an associated payload
Payload data used by Action plugins
Registry data saved to a different part of the registry


Are there more?

[Mark F]

Another question -

If "old" plugins don't execute Girder commands or send event strings to Girder, do they have to be updated or will they continue to work? Will the old interfaces still work (except the WM_* stuff) when you turn off compatibility mode for good?

EDIT: I *think* you answered this in another thread as old plugins will work as long as they are not using WM_* to execute commands or send event strings.

_________________
Mark F

<font size=-1>[ This Message was edited by: Mark F on 2002-03-23 19:36 ]</font>

[Mark F]

My questions runneth over. :smile:

I have the Serial and OSD PopUp plugins ready to go but how should I handle the transition from one registry key to the other? What should I tell the user in the readme.txt file? The data is exactly the same as before but in a new location and the plugin won't find it.

The serial plugin is ugly but doable since it supports an export/import facility for devices. The OSD Popup doesn't.

I won't tell the user to re-do all their hard work. Suggestions?

_________________
Mark F

<font size=-1>[ This Message was edited by: Mark F on 2002-03-24 18:20 ]</font>

[Mark F]

OK. I'll work on it as I get a chance. Thanks.

[Mark F]

What I am going to add:



On startup:

KEY = HKLM;
if (plugin settings not found under HKLM)
{
if (plugin settings found under HKCU)
{
KEY = HKCU;
}
}
Get settings from KEY (includes "default settings" processing)

On exit:

Save settings to KEY


I don't want to disrupt backward compatibility with 3.0. If something causes this person to have to go back to 3.0.X, it will still work.

[simonjo]

Inconsistensies in the new API doc:

1) 'command_execute_ex': the C declaration specifies 'command_execute' ???

2) the title for 'setsupportex' says 'Set_supportex", pls correct


About the action support functions: can the 'orig' and 'store' strings in TparseGirderRegEx be the same?

i.e. TparseGirderRegEx(str,str,sizeof(str));

[simonjo]

Ron,

I'm checking the new 3.1 API description dated 20/3/2002, but there are differences in section 2.5.1 and 2.5.2, TParseGirderRegEx is missing in the C/C++ declaration.

[simonjo]

I think a simple transition strategy can be following:

if (plugin settings found under HKLM) {
use these settings;
} // if
else if (plugin settings found under HKCU) {
copy settings to HKLM;
remove settings from HKCU;
} // elseif
else {
use default settings & save them to HKLM;
} // else


cu, Jo