Variant Get Attribute behavior incorrect? (LV2017 SP1)

[AdamZeroK]

It appears that Get Variant Attribute is behaving incorrectly or I am misreading/confused about intended behavior.

The help file says:

If you wire name, the names output changes to a Boolean output found, the values output changes to a variant output value, and the function searches for only the specified attribute. If the function does not find the specified attribute(s), or if it cannot convert the attribute(s) to the default value, found is FALSE, and value displays the contents of default value.

The actual behavior is very strange and does not appear to match the above. In the code below a variant has a single double added as a attribute, then I branch the variant, then I try to get that attribute. The Found and Error outputs in both branches depend on whether the value output is wired in either one of the branches. See below for snippets

output wired

Note the inputs to Get Attribute are identical for both branches.

Questions:

1) I can't see why the wiring of one branch should affect behavior in the other. Variant wires are 'by value' aren't they?

2) In either case assuming double->string is illegal, 'found' should always be false, regardless of the output wiring.

3) Are there any other examples in the standard library of the output wiring affecting VI behavior? Seems very strange

[Bob_Schor]

You create a Variant Attribute "a" having the Dbl value "0".  You then try to get the Dbl Attribute returned, but specify that it is a String.  I think I would expect an Error 91 (LabVIEW:  The data type of the variant is not compatible with the data type wired to the type input) at this point!  If you don't ask Get Attribute to populate a Value, the clever programmers at NI probably "saved time" and didn't even begin to process the function and discovered your error.

Incidentally, I tested this in LabVIEW 2016 and it behaves the same way.  You need to specify the correct type for the Attribute Value when you try to Get Attribute.

Hmm -- I will agree that the final code in the Get Attribute Help seems to say if you make the silly mistake of putting in a type-inappropriate Default Value, it will say Found = False and output the Default Value.  My guess is that this is Poor Documentation (also present in earlier LabVIEW versions).  However, the Error Message that results does accurately pinpoint the error ...

Bob Schor

[AdamZeroK]

That behavior (always return false if it cannot be converted) would be fine and roughly consistent with the help file; my question 2 shows I agree with that being OK behavior.

Except my demo shows it isn't what the behavior is.  The actual behavior depends on the output wiring, and also if branched the output wiring in other branches.  This is the confusing aspect

As a practical example code like I've given might be used if you wanted whether the attribute (a) exists and (b) contained one type or (c) a second incompatible type.  Now for all of these you have to worry about the output wiring if you want consistent behavior.  I'm not aware of any languages were the return values depend on whether it is subsequently read or discarded.

[natasftw]

I'd agree it's strange.  My guess is along the lines of what Bob figured.  Without the output wired, there's some compiler optimizations going on behind the scenes that modify how the code is behaving.  Try placing a single sequence structure frame around just the VI, but not the inputs/outputs.  I'm curious if that changes any behavior.

[AdamZeroK]

Yes, it does change some behavior. 

With the sequence structure around the Get Attribute the wiring of one branch does not affect the other.