Control Value.get doesn't read variants quite right

[Matt_W1]

If you use get use "control value.get all" on a VI reference. Any variant controls read with have their data wrapped in an extra variant layer.

If you run the below the variant will keep changing value.

The workaround (if you use OpenG) is to check if it is a variant, and unwrap the extra layer.

[UliB]

I think this is expected behavior:

LabVIEW2009 Help:

Control Value:Get Method

Gets the value of a named control or indicator as variant data. Use the Variant to Data function to convert the data to another LabVIEW data type.

Get Method doesn't check the data type of the control. The developer have to.

Uli

[Intaris]

Hmm, shoould the read / write functions automatically create / destroy the extra variant level as appropriate?

We know the read does, but the fact that the write doesn't automatically strip one level of variantness (?) seems to be counter-intuitive in my opinion.

I would have thought it would be a symmetric operation (the extra variant only existing between the two property nodes) but apparently it isn't.

Shane.

[Matt_W1]

If the write stripped a level of variance, then from the users perspective it would be unsymmetric in a different way.

Say for instance I want to set the integer ctrl "index" to 1.

I would pass a string "index" to the name and an integer 1 to the value (where an implicit "to variant" happens).

So I can wire the value I want by directly wiring to the value input,

But if I wire a variant in there won't be an implicit "to variant" and it would error if it stripped a level of variance. Or if I wanted two level's of variance one would be stripped away.

I have a feeling that my solution of stripping it off on the read side breaks another symmetry, but I haven't thought of a good one yet. The best I have is that you can't use a "to

data" node on every result type of get ctrl with the proper data type going into it. But in that case the programmer knows the data type so not stripping off the variant isn't too

big of jump in logic. And since "to data" with strip of as many layers as needed to convert something to a none variant type, so the amount of layers of variance is something

that can usually be ignored.

The closest to an ideal fix I can think of is a new type of variant where that other values don't get implicitly converted to and the layers can only be stripped off one at a time.

While being logically more consistent this removes some of the convenience of variants (needing explicit conversion nodes, and probably some other reasons).

[Matt_W1]

I ran accross another issue, and another solution to both issues.

The new issue is that I cannot set a variant control to an empty value. My orignal work around example errors if the variant is empty, the other one just wraps the empty variant.

The only work around I've found to setting a varaint to null is to use the deprecated set ctrl function. Which also fixes the wrapping issue. But using a deprecated makes it hard to suggest this as a complete solution.