COMPLAINT: Labview 'value' property does not propagate data type consistently

[sbus]

I recently submitted (as a bug) the fact that, when I have a control that is type defined (or strictly type defined), the 'Value' property node does not propagate the type definition. The documentation for the 'Value' property states that the data type is "Labview Variant". But... when I use the 'value' property, the data type is always the type of the underlying control, *except* for that, if the control was a type-defined (strict or non-strict) control, the resulting value (indicator, control, or constant) is disconnected from the typedef.

I *never* get the purple line and data type 'variant' that the documentation would suggest.

It's my belief that the disconnectiion from the type definition is both incorrect behavior, and a bug... and that the correct way to document the value property is that it returns a data type that matches the underlying control, not the Labview variant data type.

This is especially egregious when you pass a control reference to a SubVI and create a local copy of the indicator, constant, or control that you can use in the SubVI, perhaps with the intent of updating the control passed by reference before returning to the caller. If the control happens to be a cluster that is strictly type defined, and the structure of that contents is changed, the created controls, indicators, and constants derived from the reference will have the OLD cluster definition if the 'value' property disconnected from the strict type definition. This means that the SubVI not only needs to have it's logic updated to match the new cluster definition (if required, it could use elements that didn't change in the cluster definition), but it also means that you have to go back and update each and every control, indicator, and constant because even if the 'value' property now returns the correct contents, the containers you created to hold those contents are now incorrectly typed.

I was told by Labview tech support that:

"this is the way LabVIEW is currently programmed to function. Because of the generality and flexibility of property nodes, they do not maintain their strict type definition once passed through the property node. While the strict type definition and the characteristics of the front panel control/indicator may not be maintained by the property node, the integrity of the data is still intact. The property node coerces the data to fit a type it understands and then writes the data to the control. The data will still be the correct type, will have the correct data, and will have the same looking controls/indicators."

This supports the notion that the documenation ("'value' property returns Labview variant) is simply incorrect. It also support my contention that the type definition disconnection is a bug, is erroneous behavior. I've noticed that *sometimes* the type definition is NOT disconnected, although I have not been able to determine what controls that behavior; but note that in the response to my question from tech support, they state that the "strict type definition ... may not be maintained by the property node" (emphasis added). I think this is a flat-out bug; that the data type MUST propagate; that the connection to a type def (if there is one) is in essence part of the data type, and MUST be maintained.

I want this treated as a bug with an action item to get it fixed.

What do you think??? Should the 'Value' property return typed (and type defined) data, or should it return a Labview variant, as documented???

[GregR]

There are 2 types of control references: strict and non-strict. Non-strict control references can be used on any instance of a type of control regardless of its type. Thus the same reference wire could refer to a slider whose type is double or a slider whose type is int32. In this case the 'Value' property could return either type so it is represented as a variant. A strict control reference requires that the control be a specific type. In these cases we make the 'Value" property show the specific type. The documentation saying that the 'Value' property returns a variant is not necessarily wrong, but it may at least be incomplete by not mentioning this other possibility

If you are using implicitly linked property nodes (property nodes without the reference input) or wiring the reference from a control reference, then you have a strict control reference and will see the controls type.

I'm not sure if we intended to disregard the typedef or not, but I suspect it was intentional. If we were to do this, then we would have to consider references to a typedefed slider and to a non-typedefed slider as different reference types. You then could not write a subVI that operated on either control reference. Likewise if you had 2 different typedefs, their control references would not be compatible.

While I agree that it would be nice to get the typedefed type out of the Value property, you have to think about what you would be giving up to get that.

[X.]

I support this bug report (in fact I got a CAR for this in that other request here).

[AristosQueue (NI)]

Greg R's description of the variant vs regular data type is correct. As for the typedef-ness, LV 2012 will fix the bug so that if the conrol ref is strct, the Value property will retain the typedef.

[sbus]

Thank you Stephen for your followup. The fact that the typedef should be retained (and will be in LV2012) by the Value property is very important. It's amazing to me that, until now, no one at NI has been willing to admit that this is actually a bug.

I for one would appreciate a patch to LV2011 to fix this... I hate like hell having to code workarounds when I know they soon won't be necessary...

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.