How can I use a type descriptor to convert a variant to data?

[Bmarsh]

I've got a generic cluster of controls coming into a subVI, and I'd like to write each of their values out to a config file using "WriteKey.vi" from the palette, which is polymorphic. Problem is when I unravel the cluster of controls using property nodes, I get a value that's variant. Using property nodes, I can also get the type descriptor.

Ideally, there should be a way to use the typedescriptor and the variant converter to convert the value to a typed value.

I suppose I could write a case statement with each case corresponding to a different type descriptor value, and inside each case statement have the appropriately wired variant conversion, but what a p.i.t.a. that is, and
it really seems like there should be "a better way".

I'm attaching a vi that demonstrates the problem.

Thanks,

Brad

[Bmarsh]

Oops, forgot the file...

[Bmarsh]

Oops, forgot the file...

[JeanPierre]

You have no choice but to test for the incoming datatype. You can use the
type descriptor which is an array of I16. The type is the lower byte of
array element[1]. Types are documented in the LabVIEW manual "datastrg.pdf".
One other possibility that is not dependant of the internal datatype
representation (which may change in the next version of LabVIEW) is to use
"Variant to Data" function that returns an error if there is a type
mismatch. You test the variant with all the datatypes you expect and write
to config file when no error.

I hope this helps

Jean-Pierre Drolet

[Bmarsh]

I dug around the palettes and stumbled across
"Flattened String to Variant" under the Advanced->Variant section.

This function takes a Flattened String as input along with A TYPE DESCRIPTOR integer.

At last, an elegant solution. Unfortunately I had to bumble around to find it.

[JeanPierre]

And how does it solve your problem in the VI you posted? "Flattened String
to Variant"
bundles flattened data and type descriptor into variant datatype, not the
described datatype. You already have retrieved that variant data from the
value property node.

Jean-Pierre Drolet

"Bmarsh" a écrit dans le message news:
50650000000500000003370000-993342863000@exchange.ni.com...
> I dug around the palettes and stumbled across
> "Flattened String to Variant" under the Advanced->Variant section.
>
> This function takes a Flattened String as input along with A TYPE
> DESCRIPTOR integer.
>
> At last, an elegant solution. Unfortunately I had to bumble around to
> find it.

[Bmarsh]

OK, admittedly I had to change both VI to get this to work. I guess I meant to say that this solves my problem of wanting a VI that could generically write out a cluster reference without knowing all the details of what is in the cluster reference. And another VI that can generically read out of the file and apply that to another cluster reference.

The GenericWriteParams.vi now loops over every control in the cluster and grabs the "Value" property. This is flattened using "Variant To Flattened String" and then the flattened string is written to the config file.

The GenericReadParams VI now looks at each control in the reference and finds out the name and "TypeDesc" property. The name is used to lookup the flattened string from the config file, and
the "TypeDesc" property is used to unflatten the string (using "Flattened String to Variant"). The Variant is then written to the control value.

These two functions allow me to store and retrieve any generic control I want to.

I'm attaching them.

[JeanPierre]

I thought that you were looking for a solution like the attached VIs.

Write Key (Variant).vi accepts a variant and determines which Write Key
().vi to use according to the datatype. It requires some more
work since it does not make distinction between float and integer types.

Your solution is good too as long as you don't care to store flattenned
strings in a config file instead of more human readable ASCII string
conversions.

Regards,

Jean-Pierre Drolet


"Bmarsh" a écrit dans le message news:
5065000000050000000D370000-993342863000@exchange.ni.com...
> OK, admittedly I had to change both VI to get this to work. I guess I
> meant to say that this solves my problem of wanting a VI that could
> gene
rically write out a cluster reference without knowing all the
> details of what is in the cluster reference. And another VI that can
> generically read out of the file and apply that to another cluster
> reference.
>
> The GenericWriteParams.vi now loops over every control in the cluster
> and grabs the "Value" property. This is flattened using "Variant To
> Flattened String" and then the flattened string is written to the
> config file.
>
> The GenericReadParams VI now looks at each control in the reference
> and finds out the name and "TypeDesc" property. The name is used to
> lookup the flattened string from the config file, and the "TypeDesc"
> property is used to unflatten the string (using "Flattened String to
> Variant"). The Variant is then written to the control value.
>
> These two functions allow me to store and retrieve any generic control
> I want to.
>
> I'm attaching them.



[Attachment genericwriteparams.vi, see below]


[Attachment Write Key (Variant).vi, see belo
w]

[Bmarsh]

Yes, your vi's are what I was originally looking for, but then I realized that my cluster reference might contain anything (not just bool/int/string/float).

One choice was the write my own write/read from scratch. This sounded like a lot of work, and I was looking for the easy solution.

The other choice I came up with is what I posted. Its not ideal, there are some problems with it:

1. As you mentioned, the strings are binary and not readable - this isn't the end of the world, but it isn't ideal either

2. I don't think there is a line length limit in an INI type file, but if there is I could get caught by it with a big array (I tested up to 16K array of char and that was ok.

3. (and this is a problem in general) LabVIEW wi
ll let you have two objects with the same label at the same scope. For instance, you can put down an integer and name it "foo" and another integer and also name it "foo" -- Since I'm using object names for my key names, there could be some non-uniqueness problems if I use the same name. I'll probably dig into the properties and see if there was something more unique I could use for the key.

[Bmarsh]

Here is the solution I ended up with.