How can I get a variant's string data?

[alsoACS]

Greetings!

When I view a variant indicator, I see a (generally) human-readable block of text.  This makes sense to me, since, as I understand it, a variant is, internally, a kind of flattened string.  My question is:  is there a way that I can get that string in LabVIEW, and can I then load that string back into a variant?

I'm trying to preserve the human-readable aspect of the variant data.  Flatten to/Unflatten from String is not human readable, and the variant versions of Flatten/Unflatten drop the variant's attributes.  I've also tried Flatten to/Unflatten from XML, which drops the attributes AND does not unflatten correctly.

Any help you can offer would be appreciated.

Thanks!

Allen C. Smith

Ktech Corporation

[tbob]

There are functions called To Variant and Variant To Data.  Variant To Data requires the variant input and a data type input.  If you wire a string constant into the data type input, the output will be a normal string.  Wire any input into the To Variant function and you get a variant output.  In LV7.1, these functions are found in Data Manipulation palette.

[alsoACS]

To Variant and Variant to Data don't handle a variant's attributes.  I want the block of text just as it appears in a variant's front panel indicator.

[tbob]

You mean you want to display 123.000E+0 and "456" in a normal string indicator?  These simple variants have no attributes.  For variants with attributes, there is a Get Variant Attribute function, but I'm sure you already know about this.

Please give a specific example of what you are wanting to do.

Message Edited by tbob on 01-17-2007 08:58 AM

[altenbach]

I think Allen wants to have access to the plain string that is displayed in the variant container and I have not found a way to get it. The method should require no code and should be independent on the complexity of the data contained in the variant.

I agree this could be somewhat useful and should be supported. For example, we could have a readable property for the variant indicator similar to the text.text property of string indicators.

The text.text string property gives the text formatted as shown in the indicator and thus depends on the display style (normal, '\'-codes, password, hex). It can be e.g. used to convert a plain string to a plain string that incorporates '\'-codes that is available to the code. (See image). This could be useful in a case where you want to mix '\'-codes and plain codes in a descriptive display, for example containing the following three lines:

"The received string in '\'-codes is:

ABC\tDEF\tGHI\n

please verify there are no unexpected characters"

Message Edited by altenbach on 01-17-2007 09:40 AM

[alsoACS]

Altenbach is correct in his assessment; that's exactly what I'm looking to do.  If I have to, I can write my own string handlers to do what I need, but it would be so much more cool to use the existing variant functionality.

Thanks, guys!

[tbd]

Hi guys,

      Just watching this thread and wondering how to take the "plain text that is displayed in the variant's container" and "load it back into a variant" AND recover the original data-type.  It seems the current "plain text" strings don't include enough info. to distinguish a U8 from an I32, a SGL from a EXT, or a String from a Path.  Is it desired to recover the original data-type?

Cheers.

Message Edited by tbd on 01-17-2007 05:59 PM

[alsoACS]

Yes, I would like to recover the original data type.  (I know, I don't want much...  )  Data types are included in the text, but you only see them if you check the option for the indicator.

[tbd]

Ha! I never noticed that - thanks for the tip! 

How would you use/display these lumps of "(generally) human readable block of text"?  This seems like a lot of characters to display if we just want to convey the temperature (degrees C) in North Dakota.  

"single [32-bit real (~6 digit precision)]

0.000E+0"

Message Edited by tbd on 01-17-2007 06:26 PM

[alsoACS]

Well, I'm building a distributed system using shared variables to move data.  I'm starting to see cases where I need to have some metadata to go with some of the shared variables.  This data wouldn't vary much, and I was thinking I could use the description field for that purpose.  The data could be very different for different variables, but I'd like use one set of tools for handling the description field.  I want to keep it human-editable so that you could still, well, enter a description.  I was figuring the "variant" I was storing could be of the string type (the description) with attributes that could be anything.

My plan B is to treat the description field as a mini-INI file and write some string handlers.