LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Organization of Variant Attributes

Solved!
Go to solution

LV2013, Win7

 

I'm using a VARIANT to represent a function call from a script engine to an add-on.

In other words, you write an add-on in a certain format and put it into a certain folder.

My host program can see it, and attach it, and then there are certain facilities available.

Your addon can register a function, with parameters, and the host's script engine can call that function, supplying parameters, and your addon will execute your function and return a value.

 

The VARIANT seems a perfect fit for this: it has a TYPE, and can carry parameters as attributes, each having a separate type.

 

I've discovered that attributes seem to have TWO names.  The External name, supplied separately when you SET ATTRIBUTE, and an internal name, taken from the label of the value you supply to SET ATTRIBUTE.

This pic shows this:

Case 1.PNG

 

The NAME VI above uses the TYPE DESCRIPTOR of a variant and extracts the name embedded in that.  As you can see, each attribute has TWO names.  

My scheme needs to use the internals, because I need to deliver the parameters in the expected data type: u8, I32, Enum, whatever.  If your addon specifies a U16, then you get a U16 - no conversions necessary.

 

All of that works OK.

What I don't understand though, is this:

Case 2.PNG

 

Notice the EXTERNAL name of the first attribute is changed to "BAttr 1".

Also notice that the names come out in REVERSE ORDER!

I assume that LV or Windows or somebody is alphabetizing the attributes.

 

It would be easier and more efficient for me if the attributes came back in the order that I put them in, regardless of alphabetic order.

 

1... Is that possible?

2... Why are there TWO names for each attribute?

3... What is the purpose of alphabetizing the attributes?  Maybe a dictionary search?

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 21
(4,501 Views)

Variants store attributes in alphabetical order so they can do very fast lookups.  Variants store the name of the data they contain, because the name is part of the datatype description, but that feature is not used to name the attribute. 

0 Kudos
Message 2 of 21
(4,467 Views)

 


@CoastalMaineBird wrote:

It would be easier and more efficient for me if the attributes came back in the order that I put them in, regardless of alphabetic order.

1... Is that possible?

2... Why are there TWO names for each attribute?

3... What is the purpose of alphabetizing the attributes?  Maybe a dictionary search? 


1. probably not (see #3 below)

2. no idea

3. Based on prior discussions of using variant attributes for lookup tables with name-value pairs, the internal storage structure is tree-based and uses alphabetic ordering.  The structure and algorithm seem designed for efficient ordered insertion and name lookup.  My understanding is that both are inherently order log(N).

  I don't believe the internal storage structure has any mechanism for keeping track of the *sequence* of insertions.

 

Most of the gains of this structure aren't realized until the # of name-value pairs gets pretty big.  You'll likely have a countable # of distinct function call names, and could just make your own storage structure that retains sequence info.  It sounds like an array of clusters containing string name, variant, and maybe some ordering # could do the trick.

 

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 3 of 21
(4,465 Views)

CoastalMaineBird wrote: 

The NAME VI above uses the TYPE DESCRIPTOR of a variant and extracts the name embedded in that.  As you can see, each attribute has TWO names.  

My scheme needs to use the internals, because I need to deliver the parameters in the expected data type: u8, I32, Enum, whatever.  If your addon specifies a U16, then you get a U16 - no conversions necessary.

 


Any chance of a hint as to how you do this? Although the Get Type Information seems an obvious choice, I don't see how to get the output without a Variant To Data, and a case structure for every type in the enum, with constants for each type manually added. Is this what you've done?

 

Edit: I'm not even sure that would work, and I can't figure a way to use a malleable VI to take a Variant input and output the data item - although I would love to be able to do this. With Type Specialization Structure and a Types Match for every type, you could I suppose do it for built-in types, but presumably you have some improvement using the class VIs to get a default class object, which rules out the TSS/Types Match route afaik.


GCentral
0 Kudos
Message 4 of 21
(4,427 Views)

Variants store the name of the data they contain, because the name is part of the datatype description, but that feature is not used to name the attribute. 

 

Sorry, but i can't unpack that.  Are you saying that the DATA has one name, and the ATTRIBUTE has another?

I don't see a purpose or value to that.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 5 of 21
(4,405 Views)

@CoastalMaineBird wrote:

Variants store the name of the data they contain, because the name is part of the datatype description, but that feature is not used to name the attribute. 

 

Sorry, but i can't unpack that.  Are you saying that the DATA has one name, and the ATTRIBUTE has another?

I don't see a purpose or value to that.


Data names support things like a cluster of named elements.  It’s part of the data type description stored by the Variant.   Attribute names are stored in some kind of look-up tree, so they can’t be the same memory structure.   It might be less confusing to change the data name to the attribute name, but that would involve a copy and be a performance hit, I’d imagine.  

Message 6 of 21
(4,399 Views)

Any chance of a hint as to how you do this? Although the Get Type Information seems an obvious choice, I don't see how to get the output without a Variant To Data, and a case structure for every type in the enum, with constants for each type manually added. Is this what you've done?

 

There is an OPEN-G package for dealing with variants, which illuminated things for me.

The TYPE DESCRIPTOR for a variant includes a basic type code.  This is a byte which declares the variant to be a U8,U16,U32,U64,I8,I16.... etc.  There are four values that are special: Enum8, Enum16, Enum32, Enum64. They're all the same except for the size of the DATA STRING attached.

 

Remember that the strings of an ENUM are PART OF THE DATA TYPE.  Unlike a menu ring or something, the enum will not coerce if the strings do not match.  They are CARRIED AROUND with the enum value.

 

The TYPE DESCRIPTOR also includes a field called # ELEMENTS.  In a lot of cases, this isn't used, but for the ENUM types, it indicates how many strings there are in the enum type.

 

So, in the TYPEDESC, extract the #Elements field and use it to extract the enum strings.

 

Enum Strings.PNG

 

The strings are stored as Pascal strings, meaning a one-byte count and then N bytes of ASCII.

Get PString.PNG

 

So, now you have an array of strings that are the possible values in the ENUM.

The DATA STRING then represents a U8,U16,U32, or U64 integer, which is the index into that array.   When reading, that U8 or whatever wires directly to an enum indicator.

When WRITING, my situation comes from a string.  I match the string to one of the enum strings and use the resulting index as a U8,U16... value to flatten into the DATA string.

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

Message 7 of 21
(4,395 Views)

Here is the CONVERT logic.  In my case, I already have a VARIANT, given to me by the addon, so I have extracted the TYPE DESC from it.  I simply manipulate it.

The user enters a STRING value in all cases.

 

Here is the I8 case.  I simply SCAN FROM STRING using an I8 default, then flatten the result.

 

Convert1.PNG

 

For an I16 (and all other numeric types), it's similar:

Convert2.PNG

 

For an ENUM, I have elsewhere extracted the ENUM STRINGS.  I use a "signature" (hash value) of the strings, as i have a fast hash algorithm, and matching signatures is faster than matching strings.  So I take the signature of the given string and match the strings in the ENUM. The resulting index is converted to a U8, U16... and flattened.

Convert3.PNG

 

This allows me to convert a STRING value into any type of variant (except CLUSTER, or ARRAY - I don't support those).

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 8 of 21
(4,389 Views)

Data names support things like a cluster of named elements.  It’s part of the data type description stored by the Variant.   Attribute names are stored in some kind of look-up tree, so they can’t be the same memory structure.   It might be less confusing to change the data name to the attribute name, but that would involve a copy and be a performance hit, I’d imagine.

 

OK, thanks for the info.  The "attribute name" is what I've been calling the "external name" and the "data name" is what I've been calling the "internal name".

 

I'll look again, but i haven't found the "attribute" name in either the TYPEDESC for the parent variant or the TYPEDESC for the attribute variants.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 9 of 21
(4,385 Views)

So... How does this work, exactly?

if I deconstruct a variant BEFORE and AFTER I add an attribute to it, I get the exact same TYPE DESC and the exact same DATA STRING.

 

Is there some other place the attributes are stored?

Attr.PNG

 

 

Why, yes... yes, there is. 

Attr.PNG

 

 The SIZE is different.  There has to be other data that I haven't accessed yet.  Back to the OpenG stuff...

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 10 of 21
(4,380 Views)