I am trying to ensure backward compatibility for a cluster saved as part of a binary file. This cluster may change over time as new info becomes available To achieve backward compatibility this cluster is made to be the private data of a class and I flatten the class to XML before saving to a section of the binary file ( which has other data types apart from the cluster) . When I want to read back the cluster,I simply unflatten from XML to the new class ( with private data changed) .This seems to work sometimes when the cluster is not populated with certain data types like 2D pictures. In that case it says the data is corrupt and can not be unflattened to any LabVIEW class. Could this be a bug? I am using LabVIEW 17.0f2(64-bit)
XML unflattening in LabVIEW has... quirks. I wrote up a post here a while back:
You can see there that Variant unflattening doesn't work because it has some sort of "invisible" type defining happening inside of it that it can't decode based purely off of the XML it writes. I would speculate that a 2D picture might have the same sort of thing in it stopping that from unflattening.
I would suggest that if you wish to continue with this method, you will need to find which data types specifically don't work, and store those in alternate methods. Because LabVIEW classes use accessor VIs, you can still store data types that are "weird" as long as you create a "write" accessor that puts them in a format that isn't "weird", and then write a matching "read" accessor that unpacks it into its native format. For instance, for a 2D picture, if it's just a bitmap you might be able to store it as a cluster using the "Picture to Pixmap" conversion VI.