Here is my personal guess, since I don't work on LVOOP
😞There shouldn't be but a very small and constant amount of overhead involved in this process. You will note that LVClasses have a version number associated with them (major, minor, fix and build). The build number will automatically increment as you make changes to the class data. I think this version number gets saved with the flattened data. Then when you unflatten the class again, LabVIEW knows if the saved data's version is older than the expected class' version. If so, translation occurs.
Some form of translation code has been around LV for a while. For instance, create a plain old typedef with two numeric controls. Create an instance of that control and assign non-zero default values to the controls. Now go back to the typedef and add a third control inbetween the first two, or change one of the control's names. Go back to the instance you created of your control and notice that the data is still pretty much intact for the first two controls you created. LabVIEW knows to some extent how to retain data in changing datatypes. The problem was that typedefs didn't have versions associated with them, they were just data. So flattening them to string lost any notion of how this translation should take place later when unflattening an older version.
This algorithm may have been updated since then to apply in some new way for classes, or perhaps not. But I would bet that's the mechanism involved.
Message Edited by Jarrod S. on 06-28-2007 10:12 AM
Jarrod S.
National Instruments