Get Variant Attribute - Adapt output to default value if returning all attributes

[Sam_Sharp]

This is a simple suggestion regarding returning all variant attributes from a variant in the correct data type if the name is left unwired but the default value is wired.

As you probably know, if you leave the name and value terminals unwired the "get variant attribute function" will return an array of names and variants for all of the variant attributes. If you wire the name or the default value then the node will adapt and return only a single value with the 'found?' output.

Here is a diagram to show you what I'm talking about:

Currently, if you leave the name unwired but wire the default value this results in a broken block diagram.

The reasons for this suggestion are as follows:

• Cleaner block diagrams - if you know all of the variant attributes are the same data type then you save the extra constant/variant to data node
• Possible performance improvements - maybe NI does (or can do) something to improve the performance/memory allocations if the data type is known and can be done within the SubVI
• I can't see a case where it would break compatibility other than perhaps a broken block diagram would no longer be broken if the default value was wired but not the name but the runtime functionality would remain the same
• As variant attributes are a very efficient and recommended way of doing key/value lookup tables I think this minor change will tidy things up nicely and if there are performance gains to be had under the hood by doing this then all the more reason to do it!

Thanks for reading and hope you'll +1 my idea!

[crossrulz]

What if there are multiple data types in the attributes?  My preference for this node would then to only return the names and values of attributes that are of that data type that you specified.

[Sam_Sharp]

That's a smart suggestion crossrulz. I hadn't thought about it in depth but kind of assumed that the node would throw an error if the elements don't match the data type. Perhaps instead your suggestion would work and throw a warning that some of the elements weren't of the correct type?

[AristosQueue (NI)]

crossrulz: I wouldn't support that. It would be too simple to filter the list and not notice that something has gone wrong. If you want a "filter for these types of attributes", I'd introduce that as a brand new primitive, totally separate from the existing functionality. I think it would be fine to support Sam's request -- if they all match type, return them all -- but if they don't all match type, I'd make it return an error. Trying to conflate the direct "get all" function with the "filter some" creates too many situations where you just don't notice a given attribute is out of sync with the rest, IMHO. [It can be a mode on this node, but I'd rather just have a separate function entirely so it is more discoverable in the palettes, but the primary requirement for me would be a different iconography.]

[Hooovahh]

So now that VIMs are a thing, there are several Idea Exchange items that can be completed, or at least gotten a little closer to the requested feature.  Here is my attempt at a VIM that will pull out all variant attributes of a given data type (which changes as you wire to it).  Since I can't attach files here is the snippet.

[wiebe@CARYA]

Why not like this?

Sadly, snippets are still not working. But this one is easier to reproduce, as VI's can't be attached...

[Hooovahh]

Why not like this?

 Because that method generates errors if there is at least one attribute that isn't a double. 

Also Snippets do work but there is some extra work to make them work.  You need to remove the path to the image size, to return the original one.  Here is a link to my working snippet, and here is to yours.  Just a temporary work around until NI/Lithium get this fixed.

[wiebe@CARYA]

> Because that method generates errors if there is at least one attribute that isn't a double. 

Ah, that makes sense. But I'd still come up with this:

The look-up by name seems relative expensive, so I'd try to avoid that. But creating the array of all objects might be more expensive in certain situations. ..

My guess is it depends on the situation which is faster. Your if there are a lot of "expensive" objects that are not doubles, mine if most objects are double or not expensive...

> You need to remove the path to the image size, to return the original one.  

I have no idea what that means? Maybe because it's Monday..

> Just a temporary work around until NI/Lithium get this fixed.

Might be of interest to a lot of people. Maybe post a how-to somewhere? (I could do that if I knew what you mean.)

More OT: How do you quote a reply? Quote always gives me the OP.

[Hooovahh]

Ah, that makes sense. But I'd still come up with this:

The disabled diagram structure in my snippet shows that exact method in another case.  In testing I found this to be slower than the method in the enabled case.  It is true that it will depend on the number of non-correct data type attributes, but in my testing it seemed at worst the same, but in some cases performed better.

The lookup by names is probably expensive, but not using the data types seems to improve performance for VIs with debugging turned off (which VIMs are).

> You need to remove the path to the image size, to return the original one.  

I have no idea what that means? Maybe because it's Monday..

If you click on the image it takes you to a page that only shows the image.  From here you can drag the image to explorer but the copied image won't be a snippet.  If you look at the URL you can remove the last couple of sections which define the size of the image to show (which removes the snippet functionality).  Then going to that URL will return the original image which can be dragged and dropped.

More OT: How do you quote a reply? Quote always gives me the OP.

 I just started doing this today but I switch to the HTML view, then add <blockquote></blockquote> switch back to the Rich Text and copy/paste your text.  A pain for sure.

[wiebe@CARYA]

If you click on the image it takes you to a page that only shows the image.  From here you can drag the image to explorer but the copied image won't be a snippet.  If you look at the URL you can remove the last couple of sections which define the size of the image to show (which removes the snippet functionality).  Then going to that URL will return the original image which can be dragged and dropped.

Nice (quotes too). Doesn't quite work for me like that (in Edge), clicking brings me to another Lithium(?) page. But an inspect element on the original thread get's me the URL. Removing the size and then some gives me a snippet. I'll post this in the other thread (unless you object).

[Hooovahh]

Post away, I've also seen some browsers have an option to download the image, which also returns the original with the snippet.