LabVIEW Data Storage Application Note 154

[instrumento]

---

No there isn't!

Thanks, that completes the answer to my original question. I already accepted the answer pointing to the online help as solution, not sure I can also mark this one as solution too.

[wiebe@CARYA]

You can mark two solutions.

[instrumento]

---

@rolfk

I'm really not even sure where one would get this typecode from in a flattened data stream. Maybe if you could show us how to get it we could give you some more information about how it may be meant to be used but as already said, relying on this to stay the same in future versions of LabVIEW is building a bomb in your software.

---

This is to interface to old stuff that won't be recompiled, so it will stay the same.

To get  0xF1 from a flattened stream, create any typedef, wire it to a "To Variant " conversion, then wire the variant to "Flatten to String". The flattened string will contain the 0xF1 type code.

[wiebe@CARYA]

---

@instrumento wrote:

This is to interface to old stuff that won't be recompiled, so it will stay the same.

---

Yes! Nurture that technical debt!

OK, OT, especially since you mentioned this a few times. Just saying I think it's a bad decision. Sooner or later, someone will pay the price. Might even be happening right now...

[wiebe@CARYA]

---

wiebe@CARYA wrote:

---

@instrumento wrote:

This is to interface to old stuff that won't be recompiled, so it will stay the same.

---

Yes! Nurture that technical debt!

OK, OT, especially since you mentioned this a few times. Just saying I think it's a bad decision. Sooner or later, someone will pay the price. Might even be happening right now...

---

---

@instrumento wrote (PM):

Not sure this  type of replies adds too much to the discussion.

---

It's wasn't mend as condescending, just a fair (and somewhat funny) warning. In fact a very serious warning.

Not sure how else to help.

PM me all you want, but at least accept PM's back.

[JÞB]

---

wiebe@CARYA wrote:

You can mark two solutions.

---

You could too.  Just saying...

[JÞB]

---

@rolfk wrote:

---

@instrumento wrote:

All I am asking is whether there is documentation for all the type codes in flattened data, including the ones NOT in the original App Note 154 or its online replacement, be it 0xF1 or another. 

No there isn't! What is mentioned in App Note 154 and the online help is all NI is willing to document in terms of making users rely upon, that it will not change in the future. Anything not documented in there can change at any time. It's one of the reasons not to document things that are considered internal implementation details, as documenting something basically is similar to writing it in stone. It can never again be changed!

I'm really not even sure where one would get this typecode from in a flattened data stream. Maybe if you could show us how to get it we could give you some more information about how it may be meant to be used but as already said, relying on this to stay the same in future versions of LabVIEW is building a bomb in your software.

---

Which really sucks when the implementation does not match the documentation.

We all write bugs, it takes an engineer to really screw things up!  What is the Russian Phrase? "Доверяй, но проверяй" 

[wiebe@CARYA]

---

@JÞB wrote:

---

wiebe@CARYA wrote:

You can mark two solutions.

---

You could too.  Just saying...

---

True. But I'll leave it to OP in this thread.

[wiebe@CARYA]

BTW (trying to make amends):

In \National Instruments\LabVIEW 20xx\vi.lib\Utility there is a .llb called GetType.llb.

This might not solve anything, it's definitely not the documentation you're looking for. But if you (are forced to) work with flattened types, it is definitely an interesting library to get to know.