07-01-2007 09:31 PM
07-03-2007 06:30 AM
07-05-2007 03:04 PM
My goodness, I feel as though I have stumbled onto gold reading this thread. Great nugget Shane!
I look forward to Jarrod/NIs responses in future nuggets/whitepapers/NiWeek Sessions?
07-05-2007 11:25 PM
07-06-2007 03:20 AM
07-25-2007 01:04 PM
07-25-2007 01:12 PM
07-25-2007 01:40 PM
Refer to my guess about the underlying methodology on page 4 of this post, from 06-28-2007 10:11 AM. Typedef changes can maintain data in certain situations, just not with regards to unflattening old data. I believe the same mechanism is at work with LVOOP. If you really don't believe me, try it! 🙂
@billings11 wrote:
By the way, Jarrod, I don't see how classes can possibly decipher the flattened string to an updated class datatype. There is no way the clas could know how it changed or how to map the old data to the new datatype. If a typedef can't do it I don't see how a class can.
07-25-2007 01:46 PM - edited 07-25-2007 01:46 PM
Jarrod,
I know what you are implying. In certain situations it can decode flattened data properly without an error even when the data type has changed slightly. For example, new elements can be added to an U8 enum and the flattened data will still work fine. You aren't really changing the datatype there though since it is still a U8. But if you added entire controls to a typedef or class data type, it will probably error. I know with a typedef if you add any new control to a cluster it errors when you do flattened string to data. So I'm sure the same is true for classes.
Even if there are certain conditions where it doesn't error and actually manages to decode teh string properly, since we have no way of knowing the exact rulesets for this, we have to assume we are going to get an error if we change the class.
Message Edited by billings11 on 07-25-2007 01:49 PM
07-25-2007 01:59 PM