Typedef Variant data in LabVIEW 6.1

[Adam Rofer]

When plugging in the value of a typedef control (for example) into a 'To Variant' function:
In LV 6i, the typedef value was not indicated at all in the 'value' section of the variant. Now when you convert any typedef values to Variant, the typedef is part of the data. In fact, when you try to view it, you cannot even see the value of the data itself, only which typedef (this is somewhat annoying for debugging).
This is probably LV coming closer to what Variants are supposed to act like (I have no idea), but I encountered an inconsistency in this regard.
When you pull a value of the same control with VI.Panel.Controls[x].Value, it does not indicate the typedef in the value. This makes a direct comparison of the data
itself to the value of the control no longer possible: they will not be considered equal (as they were in 6i).
My guess is that perhaps it was overlooked that the .Value needs to be updated in the same way?

- Adam Rofer
[WinNT v4.00.1381, LabVIEW 6.1]

[Ben]

Did you try taking refnum of the control and run it through a "to more specific" node with the appropriate type def wired to the type terminal. Then do the comparison. Your ref to the control may be getting "generic-ized" without you noticing.


Ben

[Adam Rofer]

I tried this, but it somewhat defeats the point of using variants and the controls[].value variant. If I wire it to a more specific class (with the typedef), something that I cannot pull dynamically for use anyways, then it does not output a variant but instead whatever value of type the typedef is (e.g. orange double for a double numeric typedef).
The main problem I was trying to note is that if you plug a typdef value in directly into "to variant", you should get the same variant data as if you pull it from the controls[].value property. What happens is that the controls[].value property does not appear to deal with typedefs properly and it completely ignores the fact that it is a typedef (whereas the "to variant" includes this information).
An
example: while using a strict typedef (double), observing the variant data using a variant indicator (with both type and value viewable):
Vi.Panel.Controls[0].value:
double [64-bit real (~15 digit precision)]

0.000E+0
If I plug the double data from the typedef into a "to variant" I get the following:
'typedef-numeric 1': typedef 'typedoub.ctl'
double [64-bit real (~15 digit precision)]

>
If I take the latter variant and plug it into a "variant to data" with type variant, I get this variant:
double [64-bit real (~15 digit precision)]

0.000E+0
...which is the same as the controls[0].value.
A subnote of this is that it is now impossible to view the actual data of a typedef -> variant in a variant indicator without converting it.

An example of this is included (typevar.zip: Typevar.vi, typedoub.ctl, Notes.txt):
- If you have LabVIEW 6i then the values of "A" and "B" should be equal.
- If you have LabVIEW 6.1 then the values of "A"
and "B" are not equal.
The VIs are saved in 6i format for comparison between the two versions.

- Adam Rofer

[Adam Rofer]

I should have done this in the first place: I have now attached the two example files in non-zip format.

- Adam Rofer

[Ben]

Ok I admit, lame guess.

See below.

Ben

[Ben]

Hi Adam,

I finally found myself at a LV machine and now understand what you where getting at. (I am much better with visual aides).

I have attached a zip that contains my changes.

What I saw was not what I expected at first.

After poking around I eventually did a ctrl-H and using the wiring tool discovered that the type def was actually part of the wire!

This probably explains why, when I now do the "Create sub-VI". LV can figure out what typedefs to use when building the conector pane. I seem to remember that I used to have to go back and explicitly and replace the controls with the proper typedefs).

I know, this does not help you.

Going with this info, I first inserted a "+" node and just added a "0" (dbl constant on diagram). I then notice
d a coercion dot. This got A=B=C all the way around.

I then took another approach where I used the "to variant" node and wired a dbl constant from the diagram to the type input. THis is illustrated in the attached.

II I did not realize the benifit of LV knowing the types of my wires (i.e. sub-VI) I would call this a bug and urge to notify NI.

For the time being I will alert my colleges of this FEATURE, and watch to see if you get any response from NI regarding what is happening here.

Yell if youthink I can help,

Ben

[Adam Rofer]

Okay, so now I know for sure where this is coming from:
Basically, when NI improved the wire-information to include typedef information (which is new in 6.1 as per the upgrade notes), it became imported automatically to do the same thing in a variant; the problem here is that the VI.Panel.Controls[].Value should also reflect this change.
Thanks for your insight on this, I have contacted NI about this and I am now waiting on a response.

- Adam Rofer

[Ben]

Ok but how to fix?

If the control's icon on the diagram somehow reflected it was a typedef we would at least be reminded that this is not just a DBL etc.

Please let us know what you find.

Ben