Problem calling VB activeX dll from Labview

[hspec]

I am trying to use methods of a VB activeX DLL. I have registered the dll and am able to see the methods via the Invoke node, but the USB device the activeX method was designed to control is not being updated. I see no errors, and have a VB test program that has verified the device works.

Are there any tricks I need to know in order to get this to work?

Howard Spec
CMC Electronics
Canada

[Odd_Modem]

Is your ActiveX control an in-process server?

[hspec]

This is an ActiveX DLL, not a component. It is build as Single Thread model and Apartment Model. It is not in server process mode.

Howard

[Lycangeek]

What version of LV are you running? What version of VB was used to create the DLL?

[hspec]

Brian,

I am using Labview 7.1 and the VB application was written in version 6.0 SP5

Howard

[Lycangeek]

Well, you are up to date...I really don't think it should matter, but you might try setting the VI execution property to run in the UI thread (the VI that calls the COM object). That should avoid any apartment marshalling.

However, I think the first step is to try to reduce the unknowns. If you can put in some debug calls (log to disk for example) to make sure that you are reaching the COM object from LV, and the parameters are what you think they are. Then make sure the return from the method the same way (right before you actually return to LV).

If all that works, it may be that there is an error but it isn't being caught in the VB code.

[hspec]

Brian,

I got the VB developer to produce a simpler ActiveX DLL for me with all methods exposed. When I try to invoke one (or any) of his methods I get the following error:

Error -2147312566 occurred at Error loading type library/DLL.

I have registered the VB DLL and placed it in the system32 directory, as well as in the same directory as the vi.

Any ideas?

Howard

[Lycangeek]

Is that the same error you get with the first one?

The message after the number is the key. You can also convert that number to hex (Windows calc can do it) and then look it up in winerrors.h. In this case, here is what we find

//
// MessageId: TYPE_E_CANTLOADLIBRARY
//
// MessageText:
//
// Error loading type library/DLL.
//
#define TYPE_E_CANTLOADLIBRARY _HRESULT_TYPEDEF_(0x80029C4AL)

Because it is a windows error rather than a LV error, it makes me think that the error is coming from CoCreateInstance(). When you say you register the VB DLL and then put it in directories, why? If the DLL is an COM class, then when it is registered, the path to the location of the DLL at registration time is stored in the registry. If you move the DLL after that, COM won't be able to find it.