Why is a flattened variant different in LabVIEW 2012 and LabVIEW 2011?

[FlamingYawn]

When I flatten a variant in this manner in LabVIEW 2012, the hex I get is 1200 8004 0000 0001 0004 0000 0001 0000 0000 0000.  When I do it in 2011, it is 1100 8008 0000 0001 0004 0000 0001 0000 0000 0000.

Why the difference?

I'm trying to pass a flattened cluster that contains a variant between executables in two different versions of LabVIEW using TCP and I get an error on the unflatten from string.

[Darin.K]

My very quick test seems to indicate that as long as the LV major version byte is >=8, the rest of the first four bytes is ignored.  Are you sure the correct string is reaching the unflatten function?

[FlamingYawn]

Running this code in LabVIEW 2011 returns error 122.  The string constant is in Hex Display and contains the hex from 2012 of the code above.

[Darin.K]

I do not have LV11 to test, but LV10 handled it without error.

[FlamingYawn]

Worked fine for me in 2010 and in 8.2.1.  It also works going from 2011 to 2012.  I wonder what's wrong with 2011.  Is this expected behavior, NI?

[Darin.K]

---

@FlamingYawn wrote:

Is this expected behavior, NI?

---

An expectation of buggy behavior?  Seems like a joke waiting to be written there.

[Norbert_B]

Robert,

Before going into speculations: Can you please post a VI which changes "any" datatype (your variant) into a flattened string as you display it in your screenshots?

Norbert

[gregstoll · Accepted solution]

This behavior is by design. We now include the version number in the flattened string so that we can change/add to the representation in the future and newer versions of LabVIEW will still be able to read flattened strings that were flattened in the past.

If you'd like to flatten a variant for an older version of LabVIEW, you can use <vilib>\Utility\VariantFlattenExp.vi.  It takes a version number in hex form - to flatten for the version of 2011 you used above, pass in 11008008 in hex.  If you flatten for this version, it will be able to be read by 2011, 2012, and all future versions.

[Darin.K]

---

@gregstoll wrote:

This behavior is by design. We now include the version number in the flattened string so that we can change/add to the representation in the future and newer versions of LabVIEW will still be able to read flattened strings that were flattened in the past.

If you'd like to flatten a variant for an older version of LabVIEW, you can use <vilib>\Utility\VariantFlattenExp.vi.  It takes a version number in hex form - to flatten for the version of 2011 you used above, pass in 11008008 in hex.  If you flatten for this version, it will be able to be read by 2011, 2012, and all future versions.

---

Just curious why LV11 was so picky?  I could read future versions (real and fudged) without problems in other versions.

Also curious to know if LV version is the proper versioning to use here.  It is probably the obvious choice, but if nothing changes in the format why introduce an unneccessary version conflict?  Like flatten to string, we only have to decide pre or post 7 (so far).  It is easier for a later version to know how far back it can go than for an earlier one to know how far in the future is ok.  Maybe you expect to make changes every year?  ouch.

Just curious, I sometimes run into these serialization issues in other contexts.

[gregstoll]

---

@Darin.K wrote:

Just curious why LV11 was so picky?  I could read future versions (real and fudged) without problems in other versions.

Also curious to know if LV version is the proper versioning to use here.  It is probably the obvious choice, but if nothing changes in the format why introduce an unneccessary version conflict?  Like flatten to string, we only have to decide pre or post 7 (so far).  It is easier for a later version to know how far back it can go than for an earlier one to know how far in the future is ok.  Maybe you expect to make changes every year?  ouch.

Just curious, I sometimes run into these serialization issues in other contexts.

---

I'm not sure why 2011 was so picky in particular. I don't think we did anything explicitly to make the unflattening work in older versions, so maybe it appears to work in those versions but isn't getting the right data or something.

Yeah...we definitely could have gone with a "serialization version number" instead of using the LV version, but the LV version number is something that everyone on the LV team knows you need to increment when you're making these sorts of breaking changes.  I think it depends on how often you plan on changing your format and in how many different places the serialization code is. (I don't know what the answer is for LabVIEW re #1, but for #2 the answer is more places than you might expect 🙂 )