Strange variant behavior

[Aitor Solar]

Now I feel puzzled. I'm obtaining an OLE variant from an ActiveX method. That variant is (for example) an integer, so if I convert it to I32 with the "Variant to data" function all works fine. And if I connect this OLE Variant wire to a variant indicator, the indicator shows the data: "OLE Variant, Variant Type -> VTR_8, Value -> 60.000E+0".

But now I need to get that OLE Variant from another LabVIEW application, using the VI Server and the "Get control value [variant]" method to retrieve the variant indicator value. Well, it doesn't work. All I get is an empty variant, even if I'm still seeing the correct variant value in the first application's front panel. All other kind of values (for example LV variants) are retrieved correctly .

Maybe this sounds too convoluted. There is a more simple (and really surprising) way to see it. I create a constant from this OLE Variant (you can see it in the first image attached). All seems OK. Now I just close the VI with this constant and reopen it. And, miraculously, the variant constant has lost it's value and type (the second image) .

Does anybody know what's wrong here?

Saludos,

Aitor

[didierj]

I've also seen that variant data isn't kept after closing the vi. It already gave me quite some work to redo twice.

I didn't check, but it came to me right now: Would it work if you flatten-to-string your ole-variant and read it with the second app? What does the flattened variant contain (whole data, only a pointer, ...)?

Didier

[Aitor Solar]

I didn't check, but it came to me right now: Would it work if you flatten-to-string your ole-variant and read it with the second app? What does the flattened variant contain (whole data, only a pointer, ...)?

No, it doesn't work. In fact, if I apply a "flatten to string" to the OLE Variant and (inmediately after) an "unflatten from string", I don't recover the original, the variant value is lost. The flattened string looks just "\00\00\00\00...". The only function that works is "variant to data", anything else can't get the variant type and value. :headbang:

I've tried to convert OLE variant to LabVIEW variant, using the "to variant" function, but the outcome it's still the same OLE variant .

I don't know what to do. I can only see the possibility of converting the OLE Variants to their respective types and then to LV variants. The problem is:

1) That is redundant, because if I want to get a generic variant in the first program, is to convert it in the second. This way it would be: [get OLEvariant] -> [convert to type] -> [convert to LV variant] -> [get from 2nd program] -> [convert to type] :thumbdown:

2) It seems there's no easy way of knowing what type is an OLE variant, and the conversion isn't one-way. For example, an int variant can be converted to an int, to a double or to a string (I suppose it just takes the pointer and tries to adapt the memory to the data type given).

Saludos,

Aitor

[didierj]

2) It seems there's no easy way of knowing what type is an OLE variant, and the conversion isn't one-way. For example, an int variant can be converted to an int, to a double or to a string (I suppose it just takes the pointer and tries to adapt the memory to the data type given).

Acutally I'm stuck with a similar problem, having to deal with excel in quite a heavy manner. I help myself by having open firefox with msdn (to find what the methods/attributes might be), delphi (to find out what datatypes/values the attributes are), an uncounted number of excel-sheets (due to all the tests till it works) and of course LV.

(same as you)

Didier

[i2dx]

i experienced that, too.

i detected that first, when i tried to flatten a variant, which i got from a database query, to a string and send it to my client via tcp-ip. i simply did recieve nothing. i detected that a second time, when i tried to save special variant values in my block diagram as constants. after closing and opening the vi, the values were gone.

im following entropy with my explanation: (beat me, if i am wrong)

the values of a variant are pointers to memory segments, and the variant data conversion simply gets the pointer, and tries to fit the bits and bytes found at that address into the specified labview datatype. when the vi is closes (e.g.) the data, which belog to another application are deleted. And it seems, it is a a real "call by reference", when you use an indicator to see the values

[Aitor Solar]

the values of a variant are pointers to memory segments, and the variant data conversion simply gets the pointer, and tries to fit the bits and bytes found at that address into the specified labview datatype. when the vi is closes (e.g.) the data, which belog to another application are deleted. And it seems, it is a a real "call by reference", when you use an indicator to see the values

Yeah, that seems correct. If OLE variants are just pointers, it's logical that closing the VI would free the memory zone. But I'm still surprised it fails trying to get the variant through the VI Server. Maybe the first application reserves that memory zone and, because of that, the second application can't read it. Or maybe just the VI server can't retrieve the pointer, the same way the flattening can't get anything.

I have created a real simple dll to get the OLE variant type, and a VI to understand that type or composed type (array of whatever, for example), cast it and convert it to a usual variant, like a new "to variant" function. In fact, LabVIEW has to do something very similar in the background: if you connect the OLE variant to an indicator and select the "show type" option, you get it... but I haven't found any method to get that info programmatically. Anyway, this works great so far, though I would hope an easier solution .

Saludos,

Aitor