Error -2147352562 (0x8002000E, DISP_E_BADPARAMCOUNT) on COM component

[cpschnuffel]

Hi there,

we have a self-written COM object and are trying to fix an error which occures when implementing this object into LabVIEW.

The COM object is written in Visual Studio 2017 (compiler version 15), compiled as EXE and successfully registered (using /REGSERVER switch).

Inside this COM object there are some test functions (The regular object is much bigger, we shrinked it as much as possible to focus on the error):

__interfaceIKalibOle: IDispatch
{
  [id(1), helpstring(P_EX"return true")]
  HRESULTCER_True([out, retval] VARIANT_BOOL* pbErg);

  [id(2), helpstring(P_EX"return false")]
  HRESULTCER_False_NR([out] VARIANT_BOOL* pbErg);

  [id(3), helpstring(P_EX"add two long")]
  HRESULTCER_Add([in] LONGSumA, [in] LONGSumB, [out] LONG*Res, [out, retval] VARIANT_BOOL* pbErg);

  [id(4), helpstring(P_EX"sub two long, no retval")]
  HRESULTCER_Sub_NR([in] LONGSumA, [in] LONGSumB, [out] LONG*Res, [out] VARIANT_BOOL* pbErg);

  [id(5), helpstring(P_EX"mult two double")]
  HRESULTCER_Mult([in] doubleFacA, [in] doubleFacB, [out] double*Res, [out, retval] VARIANT_BOOL* pbErg);

  [id(6), helpstring(P_EX"div two double, no retval")]
  HRESULTCER_Div_NR([in] doubleFacA, [in] doubleFacB, [out] double*Res, [out] VARIANT_BOOL* pbErg);
};

You see two types of functions: one with return value ([out, retval] for the last parameter, this should be the normal case) and one without (only [out], only for testing). These functions are part of the "KalibOle" object, so this object has to be created first. A small snippet in LabVIEW which calls two test functions (one with return value, one without) looks then like this:

VI snippet

Whereas the function without return value (CER_Sub_NR in this case) runs without any problems, the function with return value (CER_Add) returns with error -2147352562 (0x8002000E) in <error out>. This is the COM error code DISP_E_BADPARAMCOUNT (listed here: https://msdn.microsoft.com/en-us/library/windows/desktop/dd542644(v=vs.85).aspx) and means that the number of parameters is insufficient ("Unzulässige Parameteranzahl" in german).

We crawled the whole forum for hints and tricks, but it seems that

a.) LabVIEW is able to handle COM components automatically

b.) the usage of a return value is regular practice

Of course we have the suspicion that something goes wrong with the parameter handling, but we have no idea why the function with a return value fails whereas the function without a return value succeeds.

Note: VARIANT BOOL is defined as:

typedef short VARIANT_BOOL;

Any suggestions?

Regards from Berlin/Germany

Carsten

[cpschnuffel]

Hm, 75 views within a week but no reply.

No idea / hint / suggestion / guess at all?

Regards,

Carsten

[wiebe@CARYA]

I just don't think that many lv users made their own activex objects (Rolfk probably?).

Is it too late to switch to .net? I think it's much easier from both sides (lv and e.g. c#).

Why com and not a plain dll?

Snippets stopped working for now, without the com object it won't work anyway. Any change you can post both the vi and com mockup? Not sure it would help.

[cpschnuffel]

Hi wiebe,

thanks a lot for your reply.

The usage of COM has historical reasons; the EXE also includes a GUI (that's why not using a plain DLL)

In the meantime the ActiveX object is used in many internal test applications, so IMHO switching to .NET would be a hard job.

Posting the snippet had the only reason to give a starting point for the discussion, of course it can't work without the COM object.

You can download it here: https://www.pahl-is.de/transfer/OLE_TestApplication.zip

The sample project in LabVIEW 2014 is here: https://www.pahl-is.de/transfer/OLETest_17-09-14.zip

(I hope that I break no rule of this forum in publishing this download links; if so, please let me know)

 Some instructions for using the COM object:

- Extract the zip file to a local folder

- Register the <set392u.exe> manually (using the /REGSERVER switch) or by using the <RegisterApplication.bat> (does the same)

- If you start <set392u.exe>, you should see a start screen and then something like this:

 

- The other files in the zip file are required for <set392u.exe> to work properly (the functionality of most of them are not used, but remain from the shrinking process as explained in my 1st post)

- With <OLE_LabViewTest_v1.0.xls> you can test whether the COM object is working properly. It contains macros to execute the COM object. After opening it, press the "connect" button first; then you can play with the test functions which are executed when you press the corresponding button.

Now extract the LabVIEW project whereever you want and open it; the main VI <OLETest.vi> should work fine and produce the behaviour as described in the first post.

Regards,

Carsten

[wiebe@CARYA]

The links are no problem, even attaching the files is fine. For me, it will have to wait to Monday at least. It won't work on my Android tablet...

[cpschnuffel]

No solution, but a reasonable workaround: Conversion of the COM object into a .NET DLL with the Type Library Importer (Tlbimp.exe) shipped with Visual Studio, using the following additional post-build step: tlbimp $(TargetName).exe  /transform: dispret.

More details about Tlbimp.exe see here: https://msdn.microsoft.com/de-de/library/tt0cf3sx%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396

The generated .NET DLL can be called by LabVIEW without any problems using its built-in .NET capabilities, the look-and-feel of the .NET interface is the same as using the COM interface.

I have to shut down the download links from post #4; you'll find the downloads here as attachment.

Regards,

Carsten