COM/ActiveX non-default or non-specific interface

[Rastikan]

Let say I have a non-visual activex control that implements 2 interfaces: IStuffInterface and IStuffInterface2.

IStuffInterface2 derives from IStuffInterface and adds a few more functions.

IStuffInterface2
+--Property2a
+--Property2b
+--Method2a
+--IStuffInterface
+----+Property1a
+----+Property1b
+----+Property1c

In a VC++ applications I can typically try querying for IStuffInterface2 and use it. If it is NOT available I can do plan-B and try querying for the older IStuffInterface and disable application's IStuffInterface2 related functions. Even simpler, if the VC++ application does not require anything from IStuffInterface2 I know it will run will any versions of the control.

How do you do this in LabVIEW? So far, from what I learned about LV is that if you put a control or a activex refnum on a panel it is somehow BINDED to a specific type library and interface. It seems to mean that if I create a LV application with the most up to date activex control version, the LV application won't run on a system with a previous version (even so technically the older control can fulfill the application-control contract). Even if I do make sure the LV application only uses methods and properties of the original IStuffInterface it seems incapable of using the older interface if a newer one exists on the system.

How to make sure an existing LabVIEW application will run with whatever version of the control is present on the system?

Is LabVIEW unconditionally using COM's default interface?

Can you programmatically choose a particular interface? Then how to you setup the VI wirering since the type information is unknown?

Thank you,
R.

[Robbob · Accepted solution]

Rastikan,

Tell me if I am wrong, but I believe what you are looking for is Typecasting...you can find a bunch of information on it searching around the forums and knowledgebases, but these will probably help:

"How Do I Type Cast an ActiveX Refnum in LabVIEW?

When using LabVIEW to access an ActiveX server or control, only the methods or properties that are exposed in the type library of that server or control are directly accessible. There are cases where an object (or interface) has further methods and properties that are supported by the server or control, but are not directly accessible from a LabVIEW Invoke Node.
For example, a method might output a generic object, but there exist several "non creatable" objects into which this object might be type cast. This can occur when the ActiveX server or control does not provide a strictly-typed interface. Some programming languages, such as Visual Basic, allow you to implicitly type cast an object to the desired interface refnum. In LabVIEW, you have to explicity type cast the refnum into the desired type.

Use the Variant to Data function (Functions » Communication » ActiveX) which can take an AutoRefnum (an ActiveX refnum of one class) and converts it to another AutoRefnum (of one class with a different interface). Wire the refnum that you want to type cast, such as a "non creatable" object's refnum, to the "Variant" input, and wire the desired new refnum type to the "type" input."

 and How Do I Call Multiple Interfaces from a single ActiveX (COM) Object?

In the future, please do not make duplicate threads as well. Let me know if you have further questions.

[Rastikan]

Thank you very much Rob_K,

Although what you wrote me does not exactly somes my issue, it might be useful soon. Maybe this differs from my previous reply but the problem I am experiencing now is that if I create a compiled LabVIEW application that uses an older version of a control and I upgrade that control afterward. The application won't run anymore. In C++ ( if you are NOT dropping a control on a form) it usually does not matter what is the type library version or .dll version. As long as the system can create an instance of the specified CLSID it is ok (one can argue that it is ultimatly not desirable due to usual bugs ( untested control version with application ) but in my case it is safe. With LabVIEW it seems that the application only allow to run with its know type library. Does LabVIEW uses built-in assembly like .NET ? Is it like VB6 and above (bounded to a particular .dll version)? Is it possible to de-activate that?

The base code of my control is quite stable. I would like to make sure that the LabVIEW application runs whatever the control is (opt. disabling some feature in the front panel if the advanced interfaces are not available ).

Thank you again,

Rastikan. 

[Robbob]

Rastikan,

That makes a little more sense. Is this the error you are seeing when your application runs? Does it break on both the development computer and the target computer(s)?

Sometimes simply re-registering a control with windows will repair a broken activex link, but be sure you have the latest version of the run-time engine installed on your target computer as well.

[Rastikan]

I got my suspicion confirmed from some LabVIEW R&D Engineers.

They confirmed the following answer I had:

"So you confirm that an existing .exe application created with LabVIEW that ses some activeX control will break (not be able to run anymore) if the ser of the application upgrade the activeX control to a newer version. Correct? That really seems odd to me. Could double check with your R&D engineers? I am NOT that worried about creation of the control specifying
its CLSID. What I am concern about is versioning and existing application."

They basically answered YES we confirm.