How to get a variant's value as a string

[David_Staab]

I have an existing codebase that passes values from the UI to the operational logic as variants. I've been asked to log all values passed in this manner to a text file. I'm trying to figure out how to get the value of a variant's data as a string without having to case on the type descriptor for the data. The variant indicator does it, so I expect I can, too.

Anybody know how?

[odiseo123]

The variant indicator does show you the string because it has implicit the information of which type of variable it was originally.

See the funtion "Variant to flattened string". It returns you a "data string" (the data in bytes, this is a ascii char for each byte). When you first look at the returned string you think that the information is "garbage". However it is not. The second output, "type string" contains the information on how to interprete or decode the "strange characters".

For example, for the double you gave in your example (5.321), the function will return an array of "4" and '10".

4 indicates the size of the descriptor itself, this is, the first 4 bytes are addtional info and not data. This is neccesary to avoid decoding the header as if it was data.

10 indicates the type of variable, which accoriding to LV help is (hex 0A) "Double-Precision Floating-Point Number".

To round up, you cannot isolate the string without considering the cases of the type descriptors because they are what gives sense to the raw data.

Consider using "Write INI cluster" function from openG. This functions writes a variant cluster to a file. This is very useful to store a configuration cluster. I think this is fairly close to your "codebase with the operational logic".

I copy here the VI documentation:

Writes a cluster of section formatted clusters to configuration data identified by refnum.  Section cluster names are used as section names and key-value pairs correspond to the named cluster elements and thier values within the section formatted clusters.  Only the items within the "INI  Formatted Cluster" input cluster are written to the configuration data.

For example an Cluster containins subClusters MyCluster1 and MyCluster2, where MyCluster1 contains two elements MyNumeric and MyBoolean, and  MyCluster2 contains two elements MyEnum and MyString.  This would correspond to an INI write of the following data:

[MyCluster1]
MyNumeric=1.024
MyBoolean=TRUE
[MyCluster2]
MyEnum=init
MyString="Hello World"

Note: Special characters in section and key names will be escape-coded.  These include the following: \00-\1F (non-printable chars); "[", "]", and "=" (INI syntax elements); \FE ("þ") and \FF ("ÿ") (legacy bracket encoding); Additionally, the escape character, "\", will be escaped as "\\".

Note: This VI checks whether every element of the cluster has a name so it can be identified.

[Darin.K]

Personally, I just use the Flatten to XML function.  Usually I will strip off the LvVariant and Name tags so it is a little less verbose.  When I really care, I also have XSL transformations to go from the ugly LV Schema to something much more readable as well as back again.  

[Ben]

I'd just use the variant to data with the prototype being the float and then wire that to format into string.

No parsing required.

Ben

[odiseo123]

Hi Ben, that would certainly work for the simplified example. However I would expect that the OP's "operational logic" might contain different variable types.

An example of the input codebase would allow a more precise answer.

Regards,

[Ben]

---

@odiseo123 wrote:

Hi Ben, that would certainly work for the simplified example. However I would expect that the OP's "operational logic" might contain different variable types.

An example of the input codebase would allow a more precise answer.

Regards,

---

I agree.

I was just offering a simple answer to a simple question.

If my reply falls short the OP's will generally let me know and then I will adapt as required.

Take care!

Ben

[David_Staab]

Please adapt, Ben.

I need to intercept about 150 different messages of lots of primitive types. That's why they're casting to variant before sending the message.

[Ben]

I'd insist they "throw you a bone" and change the data to a cluster where the first elment is an enum that ID's the data type and the second value is a vaiant to hold the data.

On the recieving end the enum drives a case structure where ther is a case to handle each data type.

Try seraching of "Function over-loading" (not sure if memory serves on that term).

Edit: see Shanes Nugget here.

Q:

Are you allowed to push back?

Ben

[David_Staab · Accepted solution]

Thanks, all! I decided to just use the XML approach:

[Ben]

The discusion Forums are to LV as a smorgusboard is to food. keep looking and eventually you will find something that looks good.

Ben