Strict Variant To Data function

[jandrengen]

When handling data in a Variant, I'm always interested in knowing the exact type of the data within the variant. In my own code I could add an attribute with the information, but when getting the value of a control that is not possible.

The problem is the automatic conversion done by the Variant To Data function. If the data is a double and the type parameter is set to an integer type, the double value is converted without any error.

My suggestion is to add a boolean parameter to the Variant To Data function to force it to return an error if the type parameter is not exactly the same as the data type.

[tst]

You can find the type today using <vi.lib>\Utility\VariantDataType\GetTypeInfo.vi.

If you're using an old version which doesn't support this, the OpenG data tools also include a VI which will return this data.

[jandrengen]

The posted diagram only shows one use case.

The idea with the parameter is to get an error if the types don't match exactly. It would make it possible to make better error handling.

But thanks anyway, tst.

[tst]

Actually, I didn't even look at what your code was doing. My point was that you could use that VI to get the type and then use that info to convert the variant to the correct type. No need to add anything to the V2D primitive.

[jandrengen]

So, how can GetTypeInfo.vi tell me the difference between a U16 array and a Double array? Or different clusters? It is very useful, and is often what's needed, but it is, in my opinion, not good enough then.

A variant type comparison primitive would be a very helpful supplement to the palette. 

Options for better error handling are always welcome by me, and I think the Variant To Data would be better with the option.

When the variant type is what we have in LV, missing the object reference in .NET, a few things could certainly be improved.

[Intaris]

Using the typedefs of the data can allow you to not only differentiate between U16 Array and a Double Array but also to differentiate between different control names or whether they are typedefs ot not.

I've written a nugget on it (under a different username) HERE. 

I would, however, also appreciate LabVIEW NOT interpreting what it thinks I want to convert without giving me some kind of notification.  Therefore Kudos.

[tst]

Did you try looking at the other VIs in that folder, such as GetArrayInfo.vi?

In general, I find that coercion is better than an error, at least in LV. You still haven't provided any specific use case in which this will be useful. Offhand, I can't think of a good one for comparing the exact type of variants, but I don't personally work with variants that much.

[Intaris]

Tst,

I generally don't like LV behaving in ways which MIGHT be covering up bugs in my software unless I explicitly tell it to do so.  I would favour the option to force strict comparisons for any such operation.

I hate this type of thing.

[jdeguire]

Thanks, tst, for pointing out those Variant VIs!  I have some ideas for those.

Anyway, I wasn't aware that the Variant To Data function did conversions like this for you (you can tell how often I use variants) and certainly wouldn't have expected it to.  That would probably have confused me when trying to debug code, so +1 kudos to this idea.

[tst]

I can understand wanting at least an option for having notification, but I still haven't found a use case. Do you have an example where you get an arbitrary cluster and need to convert it? I would expect that usually, you would have to know the exact data type (since you need to wire something into the V2D's type terminal), and I can't imagine a normal scenario where you would have two things which are almost, but not quite, like each other. Maybe I have a faulty imagination.

With LVOOP available, the use case presented in the nugget becomes less relevant.

[Intaris]

I don't personally have an application for this type of thing (I make type comparisons manually like in my nugget) but I think the essence of the request is to at least have the option of making LV more "strict" in interpreting its datatypes.

This I would definitely stand behind.