Bug in Variant Coercion

[JackDunaway]

Attached is a bug we've run across where the data name is not properly interprete in the variant coercion process. The bug manifests itself in different ways in 2009 and 2010, but is present in both versions (see FP of attached VI for details).

BugInVariantCoercion_2009.vi

[crelf]

Yes, I see the bug too, but I've got to admit that you confused me even futher by swapping the indicators on the FP (double click on your terminals on the BD to see what I mean). I note that if the representation of the numerics in the arrays are different then the bug goes away.

[JackDunaway]

Yes, I see the bug too, but I've got to admit that you confused me even futher by swapping the indicators on the FP (double click on your terminals on the BD to see what I mean). I note that if the representation of the numerics in the arrays are different then the bug goes away.

Thanks for the confirmation - crelf! I'll pass on the UI recommendation to the guy who made the UI

[MikaelH]

Funny, if you add an AlwaysCopy node on the notWorkingTest1 wire the DataType.Label becomes 'notWorkingTest2'

BTW I get the same thing in 2011-64bit

Cheers,

Mike

[TomOrr0W]

In LabVIEW 2009, I found that the wire that is coerced first's data name is written to all the indicators. I was able to reproduce the 2010 behavior in 2009:

[crelf]

In LabVIEW 2009, I found that the wire that is coerced first's data name is written to all the indicators.

Hmmm - good catch. Looks like a coercion bug?

[TG]

Fortunately using the convert to variant function removes the possibility for the bug to happen.

[JackDunaway]

Fortunately using the convert to variant function removes the possibility for the bug to happen.

True, this is a valid workaround, thanks TG! (see snippet) This is a known issue, CAR 279047.