JackDunaway Posted May 5, 2011 Report Share Posted May 5, 2011 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 Quote Link to comment
crelf Posted May 6, 2011 Report Share Posted May 6, 2011 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. Quote Link to comment
JackDunaway Posted May 6, 2011 Author Report Share Posted May 6, 2011 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 Quote Link to comment
MikaelH Posted May 6, 2011 Report Share Posted May 6, 2011 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 Quote Link to comment
TomOrr0W Posted May 6, 2011 Report Share Posted May 6, 2011 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: Quote Link to comment
crelf Posted May 6, 2011 Report Share Posted May 6, 2011 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? Quote Link to comment
TG Posted May 24, 2011 Report Share Posted May 24, 2011 Fortunately using the convert to variant function removes the possibility for the bug to happen. Quote Link to comment
JackDunaway Posted May 25, 2011 Author Report Share Posted May 25, 2011 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.