FlattenToString and UnflattenFromString problem

[Oliver Friedrich]

Hallo community,

I'm wondering about a very weird and strange thing in LabVIEW.

There are those two VIs FlattenToString and UnflattenFromString. The
FlattenToString converts any data into a flat string and a type descriptor.
But the UnflattenFromString doesn't require that type descriptor, instead it
needs a G-type descriptor.
To me, this makes absolutely no sense at all, it is really annoying.

I can use the FlattenToString to set a control's value by VIServer_Invoke,
no problem. But how to read, because VIServer_Invoke returns string and type
descriptor, which I can't use with UnflattenFromString.

Who explains me this weird thing, and convinces me that the LabVIEW
designers haven't been stoned when i
mplementing this. LabVIEW is great
software, anyway !!
Is there a way or VI to convert a type descriptor into a G-type descriptor
used by UnflattenFromString ?

[Albert.Geven]

My guess is that: to be able at compile time to know what indicator is correct, the labview designers need to know the exact type of the control. You can imagine that otherwise it would be possible to have one or another typedescriptor (via a switch) be connected to the unflatten from string.
So instead of the logical typedescriptor !
You have to connect a control or constant to the unflatten from string.
I also made that mistake !

[Oliver Friedrich]

Hallo Albert,

maybe you're right. But if so, what can I use the type descriptor output
for, when there is no way or VI to Unflatten a string with that kind of
information, this would be useless information, or am I wrong ?

Do you know a way to convert type descriptor into G-descriptor ?

Oliver
albert geven schrieb in im Newsbeitrag:
101-506500000005000000601A0000-982303670000@quiq.com...
> My guess is that: to be able at compile time to know what indicator is
> correct, the labview designers need to know the exact type of the
> control. You can imagine that otherwise it would be possible to have
> one or another typedescriptor (via a switch) be connected to the
> unflatten from string.
> So instead of the logical typedescriptor !
> You ha
ve to connect a control or constant to the unflatten from
> string.
> I also made that mistake !

[CraigGraham]

Oliver Friedrich wrote in message
news:3a9e0f12@newsgroups.ni.com...
> Hallo Albert,
>
> maybe you're right. But if so, what can I use the type descriptor output
> for, when there is no way or VI to Unflatten a string with that kind of
> information, this would be useless information, or am I wrong ?
>
> Do you know a way to convert type descriptor into G-descriptor ?

It's well documented (somewhere- this phrase always means "I can't be arsed
looking it up") what the type descriptor means and what the flattened data
format is. Even though you can't wire a number to the type input of the
"unflatten" function you could, for example, wire a cluster containing many
datatypes to the input and, using the type outpu
t supplied by the "flatten"
function, manipulate the flattened data such that it can be unflattened into
the cluster, which can then be unbundled by name to extract the required
data.

This allows a function to take many different types of flattened data and
work with it without needing to make a new VI for each type of data.

Though this particular example may now be better achieved using a variant-
I've not had the opportunity to lay with these yet.

[SergKr]

Craig,

Application Note 154. "LabVIEW ? Data Storage" for LV6 (datastrg.pdf in LV6 installation\manuals\)and hopefully "LabVIEW G Programmers Reference" manual for LV5x.
There is online reference in online help for any flattened string function in my LV6 installation.

Sorry, forget to mention it.

[SergKr]

Oliver,

Flatten string functions was mainly developed for sending data structures to instruments and another not G applications, I think. Then vi server was using it to exchange data between vi's. Now in LV6 there are some additional possibilities like variants, allowing to attach attributes(types) to flattened data, as well as data socket etc.

To my mind this was needed for reconstructing/changing/and parsing data blocks, gathered from or sending to the outside of the vi (e.g. instruments or binary files). If your vi's exchanging data this way (flattened strings), wiring sample control/constant is not a trouble and more simple (copy/paste) for me.

Attached is a sample that I digged somewhere in my vi's storage to show that type descriptors rather g
ood documented and could be used to parse flattened data blocks if someone need it. If you not yet upgraded, upgrade to LV6 and use variant or simply wire data sample node to unflatten from string.

BTW, in LV6 Flattened String to variant function has Type descriptor input.

[Zuolan]

Sergey,
On your last sentence, you still need the G-type descriptor to convert the resulted variant back to your original data type using Variant to Data. So the loop is still open.