Jump to content

ActiveX variant to LabVIEW variant

Recommended Posts

Hi Ppl,

I'm reading ActiveX data from an application(TestStand) in LabVIEW. The data I get is of the type ActiveX Variant. When I use variant to data node I'm able to convert the data to the corresponding data type. Howevere in my application the data type varies dynamically and I cannot use the variant to data node.

I will have to flatten it to string. But the flatten to string node does not work with ActiveX variants. It only works with LabVIEW variant types. So is there any way that i could convert ActiveX variant types to LabVIEW variant. I tried the to variant node too. I too does not convert it as expected.

To throw more light on why I want the ActiveX variants to be flattened to string:

I'm actually storing the control values of a VI in TestStand Properties(locals/file global). I use Get/SetValVariant TS API to get/set these values. So when I retrieve these values stored in the TestStand properties I actually get them as ActiveX/OLE Variants as I have mentioned. When I set the value as variant(using value property in LabVIEW) for basic data types like boolean, numeric, string these work fine. But for Arrays and clusters I actually get the reference to the container. So I'm having to get the indivdual elements of the container as variants and build this individual variants into variant cluster, so that this variant cluster can be set to the control using the value property.

 I tried using the OpenG\lvdata\lvdata.llb\Array of VData to VCluster__ogtk.vi that converts array of variant to varinat cluster. But realized it does not work with ActiveX variants as this function internally uses variant to flatten string which doesn not work with ActiveX variants.



Here is how both the variant types differ

Activex variant (boolean):

'': OLE Variant

Variant Type -> VT_BOOLValue -> FALSE

LabVIEW variant(boolean):

'Boolean': boolean (TRUE or FALSE)


Edited by lordsathish
Link to comment

Just thought I would chime in on this topic. To my knowledge, LabVIEW does not provide a way to obtain the type descriptor of "OLE Variants" also known as "ActiveX Variants". Regardless of the OLE Variant type (VT_BSTR, VT_I4, ...). The type is returned as "External Data" from the LabVIEW Get Type Descriptor and "Reference" from the OpenG toolkit. This is due to the primitive flatten to string function provided from LabVIEW.

There are a few related threads:



The only work-around I can think of is to pass this data to an external library (DLL) which can obtain this information. However, I have not done this and am not sure of the limitations or implications of passing by-reference OLE variants to external code...

It would be great if someone that has created a work-around could provide advice...

Link to comment
  • 1 year later...

I haven't really the time to look at this right now, but I think Variant to Flattened String would allow to do what you need.

Basically it returns as type for ActiveX variants the value 0x84 and then another int16 that is the actual VT_ value. So it should be not to difficult to extend the OpenG Variant tools to also be able to identify the subtype of ActiveX Variants.

Link to comment

Well you are right that Flatten Variant doesn't work. I was mislead by a quick trial and had no time to verify further as I had to leave for private obligations. However I can't accept defeat so I remembered another post where someone wanted to have an VT_NULL Variant and investigating into the solution I have come up then showed an easy and totally official way to do it. The VARIANT memory layout is fully documented on MSDN and the LabVIEW Call Library Node supports explicitly the ActiveX Variant type. So simply passing the Variant as ActiveX Variant pointer to a C function that looks at the first two bytes in the structure is all that is needed to get at the VT_ values.

Enclosed are the VI to create specifically a VT_NULL variant and the VI to read the VT_ type. I haven't entered the entire range of VT codes into the enum and since those codes are in fact not continous it is probably better to use a Ring control instead but that is an exercise left for whomever is wanting to use this VI.

Very impressive. Thank you!


For others interested in rolfk's solution, check out the DevZone article on MoveBlock here.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.