typecast does not accept "All" types of data

[pawel]

Take a look on the enclosed vi. TypeCast will not accept this datatype, even though in help is written that it accepts everything. When you remove string from the cluster, it will work. Why it can not accept a string inside a cluster?

cheers
Pawel

[rolfk]

pawel wrote:
> Take a look on the enclosed vi. TypeCast will not accept this datatype,
> even though in help is written that it accepts everything. When you remove
> string from the cluster, it will work. Why it can not accept a string
> inside a cluster?

This is expected behaviour. Typecasting only works on flat data by
definition. This is a limitation of LabVIEW put in on purpose. What
should the result be here?
You seem to expect the C behaviour where the embedded string would count
for four bytes for the pointer (well it really is a handle in LabVIEW
anyhow). However this C behaviour makes no sense in LabVIEW, as LabVIEW
does strictly speaking not support pointers at all in its language
definition. And embedding the variable sized string or array into the
typecasted byte stream would make the bytestream impossible to reverse
typecast as it would miss the information as how long the string must
be. That is why Flatten can work on non-flat data and does add extra
int32 values in front of each variable sized data element so the
bytestram can properly be unflattened later on.

Rolf Kalbermatter

[pawel]

Hi Rolf

I do not think I agree.

Bear in mind that TypeCast with a pure string input (not in cluster) will work properly.

For a cluster I would expect a "TypeCast (to string)" to give a byte (char[], string) representation of any variables that are in the cluster (line C struct).
Cluster should be here a transparent container and the resulting string should contain all variables casted to a string as they were casted to string separatelly and that concatenated.

That is why I do not want to use "Flatten to string", from the reason you mentioned about adding a definition in front of variable.

regards
Pawel

[Albert.Geven]

As Rolf mentioned
A string in a cluster does not exist, only the handle to string.
This means that typecasting would give you four bytes with crazy values!

[pawel]

Hi Albert

I understand.
In this way I need to type cast all elements separatelly and concatenate strings. I just wanted to avoid lots of unboundle-boundle pairs.

Still, I think it would be nice if TypeCast will do what I want. If string in cluster does not exist, the TypeCast should find its representation from the pointer and add it to the resulting string together with all other variables.

kind regards
Pawel

[chilly_charly]

---

@pawel wrote:
Still, I think it would be nice if TypeCast will do what I want. If string in cluster does not exist, the TypeCast should find its representation from the pointer and add it to the resulting string together with all other variables.

---

I agree with Pawel.
Also Rolf statement about reversibility "...And embedding the variable sized string or array into the typecasted byte stream would make the bytestream impossible to reverse typecast as it would miss the information as how long the string must be..." seems to be unfair, since it is true only when 2 strings (or 2 arrays, or 1 string and 1 array...) are present in the cluster.

CC

[pawel]

Hi CC

That is correct, but still you can recover the information if you know what to expect.
E.g. your cluster can look like {U32, U32, String1, String2}, where you define that the first two U32 tels about the length of String1 and String2. That would be propably most often meet during the network communication and some generic typedefs.

You got 5 starts for backing me up 🙂

regards
Pawel

[Photon_Dan]

If you are willing to define length fields, then why not use the Flatten to String function? The only thing it does is place the length fields in the for you. If you feed it two I32s and a string, you'll end up with the following structure.

Num1 I32, Num2 I32, Length I32, String

As long as you expect the first two numbers and realize that there's a length field right after that, you can recover everything.

Dan Press
Certified LabVIEW Architect
PrimeTest Corporation

[pawel]

That was just an example. I was thinking about more advanced solusions, which actually involve LV only on one side, so the interface must be well defined and understandable for others as well.

Cheers.
Pawel

[chilly_charly]

Hi Pawel !
As you know, I was backing you even before the first answer. 😉
Cheers !