MisMatch when UnFlattening

[Intaris]

---

@Sam_Sharp wrote:

---

@Intaris wrote:

But then I can't quite follow where the Strings are supposed to be.....  I don't see Hex values for "degC" Anywhere in the flattened string (And certainly not twice).   If I had to hazard a guess, I might suggest that the cluster V1 has some hidden elements in the cluster..... It seems to be storing a couple extra DBLs with zero value.

---

The units could be an Enum rather than a string?

---

Just posted the exact same theory.  I reckon so.  If so, then the flattened string seems to check out (for me, I used to parse these in the past.  I don't remember why, perhaps just out of interest).

[Intaris]

---

@CoastalMaineBird wrote:

 the array should be in-line.

Which is what I expected, but that contradicts what Norbert said above.

---

It is inline, Norbert is mistaken I believe.

Try adding "01" at the end for a Boolean TRUE and "4059 0000 0000 0000" for a DBL "100" and see if it will cast back then.......

[CoastalMaineBird]

The data elements before Scale Factors is not an issue because if V2 wouldn't match them, all elements AFTER Scale Factors would also mess up (e.g. Rec. Rate) as data alignment wouldn't fit anymore.

Good point.  It CORRECTLY unflattens items AFTER the array, proving that it hasn't gorched the unflattening process.

That assumes that the default values of V2 don't by accident match what we see in the screenshots....

No, all defaults are 0/false/"", It is CORRECTLY handling stuff after the array.

One VERY IMPORTANT ASSUMPTION: The tab order of elements of V1 and V2 is identical. So the two new elements are placed AFTER the other items (including the array)!. Is that true?

--- I don't know about the tab order, but the cluster order is indeed that way.  I deliberately added new elements AFTER all others, thinking that it would just leave them default.

FWIW, it does complain about "Data is corrupt" (error 74) in the second case.

[CoastalMaineBird]

But then I can't quite follow where the Strings are supposed to be.....  I don't see Hex values for "degC" Anywhere in the flattened string

Sorry - that is an ENUM, which only occupies 16 bits.

[CoastalMaineBird]

Try adding "01" at the end for a Boolean TRUE and "4059 0000 0000 0000" for a DBL "100" and see if it will cast back then.......

Yes, it works, without error.

The original:

After adding the appropriate data:

Still, I don't understand.  How does adding the data onto the end, make the array start working?

[CoastalMaineBird]

UGLY HACK:

Unflatten with the new TypeDef

If Error

   Unflatten with old TypeDef

SON OF UGLY HACK:

Append 0x01 4059 0000 0000 0000 to every string

UnFlatten with new TypeDef

(If the string already has the new data, the excess will be ignored.)

[tst]

---

@CoastalMaineBird wrote:

Still, I don't understand.  How does adding the data onto the end, make the array start working?

---

You would have to read the relevant help section on how LV stores data in memory, but my guess is that the array is stored as a pointer (which makes more sense than being flat, as it allows LV to resize it cleanly and handle internal types) and when the unflatten fails, LV simply doesn't get to the point in the code where it puts the correct pointer in the cluster (or something else along those lines), resulting in the array being empty.

The bottom line is that you should not use this. Use something like the OpenG VIs.

[Intaris]

---

@tst wrote:

---

@CoastalMaineBird wrote:

Still, I don't understand.  How does adding the data onto the end, make the array start working?

---

You would have to read the relevant help section on how LV stores data in memory, but my guess is that the array is stored as a pointer (which makes more sense than being flat, as it allows LV to resize it cleanly and handle internal types) and when the unflatten fails, LV simply doesn't get to the point in the code where it puts the correct pointer in the cluster (or something else along those lines), resulting in the array being empty.

The bottom line is that you should not use this. Use something like the OpenG VIs.

---

I disagree. The bottom line for me is this is a bug.

[CoastalMaineBird]

read the relevant help section on how LV stores data in memory

None of that applies to how things get FLATTENed.

[tst]

---

@CoastalMaineBird wrote:

read the relevant help section on how LV stores data in memory

None of that applies to how things get FLATTENed.

---

You say the problem happens when unflattening. That's a conversion from a flat format to an in-memory representation.