variant to flattened string consistency

[instrumento]

For a given data type, e.g. a string, I was expecting the "Variant to Flattened String" function to always yield the same "type string" array, but that doesn't seem to be the case with 9.01, or at least in the case I'm trying now.   Is this true, i.e. "type string" can be different or do I have an error somewhere else? 

I have a string that is converted to a variant a few calls above and lands as the input to the function.  If I do a simle test, I always seem to get "0 8 0 48 255 255 255 255" (decimal) for the type string, which seems legit, no matter what the string looks like.  When I call it in my code, same apparent strings I typed in my simple test case, show up as "0 18 64 48 255 255 255 255 9 84 101 120 116 46 84 101 120 116" or as "0 14 64 48 255 255 255 40 110 99 109 101 0", both legit string types, I guess, with some extra info, and my code doesn't handle this quite well.

[rolfk]

The type string contains not only the data type and extra information regarding that type but also the labels of all controls. The format is logic and you can account for that when parsing the type string but it is certainly not trivial to do so, since the type string is a recursive data structure that can also easily describe any complex data structure such as arrays of clusters of elements of clusters of arrays of ........

[tbob]

This NI description of  flattened data data may help.

[instrumento]

TMI on the type I guess 🙂  I really only wanted to pass the "type" and the "value" around (and string was only an example, I do this generically for several types).

Thanks

[instrumento]

I've read all of that, plus the 7.1 manual on that, thanks. 

My problem was that I wasn't expecting a given type to yield different type strings, of different lengths of all things, and that was confusing my unflattening section.   After reading the description of flattened data I would expect all strings to have a type string of NN NN xx 30 FF FF FF FF, where xx is reserved by NI, and NN NN the number of bytes in the string with the proper endian-ness, and that is not case.  There's lots extra stuff not addressed in that document.

For now a little semaphore between the two threads that were involved fixed the problem, but if I knew about that fact I would have coded things a bit differently.

[rolfk]

Well the LabVIEw 2009 help file for the type descriptor is rather useless information. It describes the new 32 bit internal datatype descriptor that is not anywhere exposed to the diagram as far as I know. Also you are right that the addition of the label is not documented in that place. It used to be documented however in an application note that I can't seem to find quickly.

Basically the type descriptor has after the actual type information a Pascal string appended that also counts for the length at the beginning of the type descriptor. Pascal string means a byte indicating the characters to follow and then the characters. This information can be completely absent, when the typedescriptor length is used up after the normal type parsing.

Message Edited by rolfk on 05-18-2010 02:27 AM