08-11-2019 06:55 PM
I ran into a bit of odd behavior today, and was wondering if this had been observed by others and as a quick sanity check...
It seems like a "bug" to me, but it's not always clear if behavior is actually intended or not...
It looks like the "Variant to Data" node shows a buffer/memory type behavior with regard to objects.
What I mean by that is that if (in a for loop) you send a Object through a Variant to Data node in one iteration, and then in the second iteration you send an incompatible data type through the same node, rather than the output being the default data type, the output is actually the previous instance of the object...
Below is an screenshot of a VERY simple example where this behavior is observed. I've also attached a .zip file with the example code (LV 2018). When we try this with a "standard" data type (ie a string) the output is the default value (blank string). With the class, it is the last instance of the class to pass through.
In both cases the error cluster still passes through the same error, so the case can clearly be handled correctly. However if this error is suppressed somewhere, the results could be pretty nonsensical/confusing...
Solved! Go to Solution.
08-11-2019 07:26 PM
Thanks for reporting this, jyoung8711
I tried your project in LabVIEW 2019 and it shows the same behavior you are seeing. I wasn't sure it was a bug, but after enabling Iteration Parallelism in the inner loop and getting inconsistent behavior (sometimes using the default object and sometimes not), I concluded it does seem as an oversight.
Therefore, I have filed CAR #743825 for the appropriate team to review and follow-up with this.
Thanks,
08-12-2019 02:57 AM
There's no 'Default' data in Variant to data, only conversion attempt. What you found is clearly a bug, but it also shows the importance of checking error wire, and if you want a default value, wire through the conversion data through a case structure.
/Y
02-19-2020 05:31 PM
This issue will be fixed in LV 2020.
03-06-2020 05:08 PM
@AristosQueue (NI) wrote:
This issue will be fixed in LV 2020.
Great!! Thanks for the update.