What controls names to be part of type descriptors

[owillebo]

Variants can be converted into a type (descriptor) string and a data string using
the 'Variant To Flattened String' vi.

In the Type Descriptors specification it says;
"... The minimum value in the size field of a type descriptor is 4, as shown in the previous table.
However, any type descriptor can [!!!!!!] have a name (a Pascal string--> appended, in which case the size
field is larger by the length of the name rounded up to a multiple of two. ..."

I found that indeed sometimes there is this 'Pascal' string appended and sometimes not.

However I need these strings to identify elements in a Cluster. So I need to know how I control that
the Pascal strings are appended.

[tst]

I'm not an expert on working with the type descriptors, but if you want to see a very detailed example of how to work with them, check out the OpenG packages. The Variant Configuration VIs and the Variant VIs should probably do what you want.

[shoneill]

If you look at the definition of each Type Descriptor, you have a minimum length as you have already stated which is type-dependent.  Integers, for example have a length of 4 Bytes followed by a single Byte indicating the length of the String used for the name.  When this 5th Byte (using an integer example) doesn't exist, there's no name.  When it's present and larger than zero, the following N Bytes represent the name.

The first two Bytes (or U16 if you wish) give the total length of the Type descriptor.  This includes type descriptor, name and so on.

U8 Example...

Byte sequence 00 14 40 05 0E 44 61 74 61 20 74 79 70 65 20 28 55 38 29 00 Gives a U8 Data type with the name "Data type (U8)" (Unless I mistyped a number of course 😉 )

The first U16 gives the entire length (14 Hex = 20).  The second U16 gives the Type, even though the first byte can (must) be ignored (40 in this case).  The next byte (if there IS one) gives the length of the string used for the name (0E = 14).  If you've reached the end of the Type descriptor length without finding a string length entry, there isn't one.  The finyl 00 is simply rounding the TD to a multiple of 2.  If dealing with complex type descriptors like clusters (or arrays) you need to "cut" the individual items into the appropriate length (first two bytes, remember?) to avoid running over into the next type descriptor.....

AFAIK of course.  I have written quite a few variant parsers and this has always worked for me.

The Equivalent TD without a name would be

Byte sequence 00 04 40 05 Gives a U8 Data type with no name

Shane

Message Edited by shoneill on 02-12-2007 05:16 PM

[owillebo]

Thanks,

That is not the question. I know how to find out if a type descriptor has a name. What I want to know is how to make LabVIEW use names.

For instance take a cluster. If there are only numeric elements in the cluster LabVIEW does not write the names in the type descriptors.
But as soon as you add a string or boolean to the cluster then LabVIEW suddenly adds the names?? If you remove the boolean or string
names are gone again???

Furthermore LabVIEW changes names underwater.

When you have a cluster with a boolean named 'Boolean' and a string named 'String' then LabView adds the names 'Boolean' and 'String' as
expected.
Now when you add an int, LabVIEW suddenly changes the names (underwater not in the GUI) to 'status' and 'source' (he that's an error cluster)

My question is this documented and/or can it be controlled or worked around?


Okko

[shoneill]

"For instance take a cluster. If there are only numeric elements in the cluster LabVIEW does not write the names in the type descriptors.
But as soon as you add a string or boolean to the cluster then LabVIEW suddenly adds the names?? If you remove the boolean or string
names are gone again???"

"When you have a cluster with a boolean named 'Boolean' and a string named 'String' then LabView adds the names 'Boolean' and 'String' as
expected. Now when you add an int, LabVIEW suddenly changes the names (underwater not in the GUI) to 'status' and 'source' (he that's an error cluster)"

Can you provide examples of these?  I've never witnessed anything like that.  Maybe you've got a messed up LabVIEW installation.....

Shane
PS Are you sure you're reading the right Type Descriptor?

Message Edited by shoneill on 02-15-2007 10:02 PM

[RikPrins]

Hello Okko,

I am also not perfectly sure what you are looking for. I agree with shoneill about posting a small example program that illustrates your problem. I have played around a little bit with what you are describing and I do see some of the things you are seeing. About the cluster sudenly acting like an error cluster I can be short: This is expected. The only thing that differs an error cluster from a "normal" clucter is that it always has the same elements in it in the same order. So if you create a cluster with the right elements in the right order, LabVIEW assumes that it is an error cluster. If you are using LabVIEW 8.20 you will even see that it will take the coilor of an error cluster in the blockdiagram. I do not think that there is any way to workaround that.

But anyway, as I said, an example would be very helpful.

Regards,

RikP - National Instruments Applications Engineering

[owillebo]

Please find an example vi created with 8.2 attached.

[shoneill]

Thanks for posting the examples.

You seem to be using the "Flatten variant to string" instead of the simple "Flatten to string".  This seems to be part of the problem.

Replacing the function with the normal "flatten to string" avoids having to first make your data variant, and then building a string.  I agree this is a bug.

If you replace the functions with the correct ones, the names remain.





I'll add these to the bug list.  I think we have two seperate bugs here.  One is the automatic error-cluster assignment to something which is clearly not an error cluster, the other is the disappearing names when wiring certain data to the "Flatten variant to string" function.

Hope this helps

Shane.

[owillebo]

I cannot use 'Flatten to string' because I want the serialization ('read Variant To Flattend String') done in a sub vi accepting any type data.

This is only possible by using a variant because;

1. Clusters cannot be transferred over vi boundaries i.e. I cannot make a vi which accepts a Cluster is input.

2. I don't want to maintain a polymorphic set of vi's.

[shoneill]

Well, you'll have to wait for a bugfix then.  I have since noticed that the bug has been reported twice (once in January and once today by me by mistake).

It seems that the conversion to Variant causes some controls to lose their names.

I imagine this will be fixed in the next version of LV.  Until then, I don't see much of a workaround unless you take the TD of the data and pass this to the sub-vi as an extra input.  Horrible workaround I know, but at least you have a single VI with a variant input.....

Sorry I don't have THE solution on hand.

Shane.