LV 8.0.1 Bug, no error when unflattening mis-matched data type

Question

When unflattening a string and wiring a "type" that does not match the original format of the data, sometimes I don't get an error and I get no data. I've attached a VI written in 8.0.1 that illustrates 2 examples of this. In LV 7.1 these cases did return an error, but not in 8.0.1. Can anyone offer some insight or global solution?
Thanks, Chip
Attachments:
LV 8 Bug, no error trapped on mismatched type when unflattening string.vi ‏23 KB

Answer 1

Good afternoon,
Well, this certainly is an interesting situation.  In the example “Unflatten string returns data
from previous iterations”, the second iteration of the for loop unflattens a
string as an array of strings type, this is obviously a type mismatch so if any
data is returned I wouldn’t expect it to be valid.  What is even more interesting, is that if you
don’t use the auto indexing, but rather explicitly index the array there is no
error, but the data returned is like it was in 7.x.  I tried to use the flatten function’s
“convert 7.x data function with no luck in either case.  I filed a bug report on this issue (number
3X0CBC3A), but it seems to me the only workaround for now is going to be just
making sure the types match.  I know this
is going to be inconvenient for you, and for that I apologize.
Incidentally, in many cases I wouldn’t necessarily expect an
error to be generated if the types don’t match. 
This is because the flatten to string function takes your data and
converts it to a string which is nothing more than a byte[ ] of data with some
size information.  When you “unflatten”
the function takes the string it is given, and attempts to reconstruct the data
in the format that is specified by the “type” input.  If it can reconstruct the data from type,
regardless of the data returned I wouldn’t expect it to generate an error.  Sometimes, however, an error can be detected
– if you flatten a double-precision number and unflatten to a single precision
number LabVIEW can detect that the incoming data represents something much
larger than a single precision number.  I
suppose that LabVIEW 7 did a better job checking the size of the sting before
deciding whether or not to generate an error.
Again, I apologize for the problems this may cause.  Please let me know if there is anything else
I can help with.
Travis M
LabVIEW R&D
National Instruments