lordsathish Posted August 24, 2011 Report Share Posted August 24, 2011 (edited) 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. Thanks, Sathish 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) FALSE Edited August 24, 2011 by lordsathish Quote Link to comment
lvb Posted August 25, 2011 Report Share Posted August 25, 2011 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: http://lavag.org/topic/12182-database-toolkit-variants-vs-ordinary-labview-variants/ http://forums.ni.com/t5/LabVIEW/How-to-Get-OLE-Variant-Type/m-p/1334434 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... Quote Link to comment
lvb Posted August 29, 2012 Report Share Posted August 29, 2012 Just to follow-up on this topic, I added an entry in the idea exchange to provide access to the OLE Variant Type: http://forums.ni.com...s/idi-p/2140336 Quote Link to comment
Rolf Kalbermatter Posted September 1, 2012 Report Share Posted September 1, 2012 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. Quote Link to comment
lvb Posted September 2, 2012 Report Share Posted September 2, 2012 Rolfk, My attempts at using the Variant to data function are detailed in the NI forums post above. In my testing, every OLE variant type had the same type string values... (null) Quote Link to comment
Popular Post Rolf Kalbermatter Posted September 2, 2012 Popular Post Report Share Posted September 2, 2012 Rolfk, My attempts at using the Variant to data function are detailed in the NI forums post above. In my testing, every OLE variant type had the same type string values... (null) 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. Get OLE Variant Type.vi NULL Variant.vi 4 Quote Link to comment
lvb Posted September 3, 2012 Report Share Posted September 3, 2012 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.