COM library version mismatch

COM library version mismatch

Our application doesn't receive button clicks or barcodes when it runs on a Motion C5 with Windows 7 and version of the Platform Drivers. It works fine on a C5 with XP and version

I have tried building the application again with version [sic] (with the patch) of the SDK installed on my development PC, but I get the same result: the executable only works on the machine with the 2.0 PD.

The application is written in Delphi so it is necessary to create a Delphi type library from

The SDK2 type library had this description (from the comments in the generated Delphi source file):

// $Rev: 8291 $
// Type Lib: C:\\Program Files\\Intel\\MCA\\Bin\\IntelHealthcare_com.dll (1)
// LIBID: {491BB445-E801-41B5-A6B1-EFAD178E2279}
// LCID: 0
// Helpfile:
// HelpString: Intel Healthcare 2.0 Type Library

The SDK 3.1 type library has this description (note the "2.1" in the HelpString field):

// $Rev: 8291 $
// Type Lib: C:\\Program Files\\Intel\\MCA\\Bin\\IntelHealthcare_com.dll (1)
// LIBID: {491BB445-E801-41B5-A6B1-EFAD178E2279}
// LCID: 0
// Helpfile:
// HelpString: Intel Healthcare 2.1 Type Library

Is that expected? Shouldn't it be "3.1 Type Library" and have a new LIBID? Are SDK 2.0/2.1 applications expected to work with PD 3.1?

12 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

Hi rcopely

The application built with older MCA SDK (2.0/2.1) should work with higher version of MCA Platform Driver (3.1). We generally do not test with Delphi, so not sure if the type library extraction and usage and version mismatch is creating any problem there. We test with VB6, VB.Net and Java script as part of validation and those works fine. So we need some investigation here to check if you are missing something or from where the error is coming.

The library IDs normally get updated when we perform major changes to the interfaces. The type library version (2.1) could have matched the MCA Platform Driver 3.1 release version for readability, but that would not create any problem.

Can you please provide the MCA log file set at DEBUG level capturing the failure?

Also, would it be possible for you to provide a small Delphi example to us so we can reproduce the same error?


Thanks Steve, I will see what I can get together.

I've just noticed that our app works on my developer station (with the barcode loopback plugin) only with the version 2 SDK. With the version 3 SDK my call to "TButtons.RegisterEvent(BarcodesScanned)" fails and therefore we only get barcodes as keyboard input.

Perhaps the same issue, perhaps not. I'll try the test Delphi app with both SDKs and both PDs and send them to you.

Amusingly enough, a simple test app works fine in all four
environments (SDK2, SDK3, PD2, PD3).

I'll try to work out what's different about our application or test environment that makes it not work
under 3.1.

Thanks for the update. Let us know if you need our assistance.

The difference seems to be around the behaviour of the IButtons.RegisterEvent function.

As originally written, our application did the following for every popup window it creates:

MCAButtons.MainWindowHandle := AHandle;

If any exception was raised by that code, the application disabled the barcode functionality.

We got away with that on the Version 2.1 SDK/PD, but on Version 3.1 it seems that registering for an event more than once raises an exception with the message "Button register/unregister error".

The solution is to register the events just once. (Doesn't seem to matter which window is used for MainWindowHandle.)

If I understand correctly, RegisterEvent uses MainWindowHandle to find the application instance, and registers the events for that instance. Subsequently the events will be triggered if the active window belongs to that application instance. Is that about right?

Hi rcopley,

Our developers are reviewing the code base forthe window handle registration in the COM layer now. They want to take a close look at this to verify what should happen.



Hi Steven,
I guess you realised that what I said before was wrong. You only get events if the active window is registered. What I was actually seeing (in our real application) was that for some windows, the RegisterEvent call succeeded, and for others it failed, and I just happened to choose a window for which RegisterEvent had succeeded.

If the developers can suggest any factors that might affect whether RegisterEvents succeeds or fails, I could create a simple test application. I haven't been able to pin it down myself. (For example, it doesn't seem to matter whether the window is enabled or visible, or a popup window, or a child window.)

Best Reply

Hi rcopley,

Our developers have looked at the behavior and asked me to pass this info back to you so you are aware:

Before MCA SDK 3.1: The handle of the window where the COM object was created (Window in focus) was being used for registration. If it is registered more than once for the same kind of button/keypress then anerror would be seen for the second registration call with register/unregister error.

MCA SDK 3.1: The handle of the window where the Register event function is called, window in focus at that point of time is considered for registration. In this case, user will be able to register UI handles for child windows and popup windows easily. If it is registered more than once for the same kind of button/key press then error would be seen for second registration call with register/unregister error.

Let me know of you have questions.


That's useful, thank you all.

The documentation is out of date (see IButtons::MainWindowHandle in the COM API reference, for example).

We'll need to modify our application so that it calls RegisterEvent in
response to window activation (rather than window creation).

Actually, before MCA SDK 3.1, the window handle that was used for RegisterEvents was the one in the global variable MainWindowHandle. That's also what it says in the documentation. Perhaps the default value of that variable is the handle of the window that was in focus when the COM object was created.

Is MainWindowHandle completely unused now?
Should I depend on this new behaviour, or will the documented behaviour be reinstated in a future version?


Hi Richard,

Here is the response from our MCA devlopers:

The COM layer in most cases is used by scripting languages. In scripting languages developers tend to create global object and use this object in other windows for accessing button functionality. This will lead to failure for retrieving the data in pre MCA SDK 3.1 the window handle was being used during creating of object. This was fixed in MCA SDK 3.1 and when there is a call to Register Event, the handle of window that is in focus is used for registering the event for the required button. The COM layer is designed so that it will fetch the focused window handle and use this for registration and the handle passed from application layer is ignored. This behavior covers all the scenarios for different types of windows and there might not be changes in the future.

Let me know if you have additional questions.


It is not quite true that "in pre MCA SDK 3.1 the window handle was being used
during creating of object". As I said previously, "before MCA SDK 3.1,
the window handle that was used for
RegisterEvents was the one in the global variable MainWindowHandle". In Delphi, it's not hard to accommodate the new behaviour of RegisterEvents. You can just call RegisterEvent whenever a window is activated for the first time. However, it used to be possible to call RegisterEvent at any time after the window handle is created.

I understand the new design and I don't object to it at all, but it's a backward-incompatible change, not just a bug fix. It would be really useful to low-level language users of the COM object if this were documented. (In the FAQ for now perhaps?)

Thanks for helping us with this.

[Edited to be clearer and more polite.]

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!