Get Variant Attribute Should Search for and return multiple values based on RegEx

[TimmTheEnchanter]

I am using Variants as lookup tables (see this article):
Using Variant Attributes to Build a Dictionary or Look-up Table

I would like to be able to use some sort of wildcard to return multiple results from the Get Variant Attribute VI (all results are of the same type, and I don't know the exact names of all the results - those two points make this idea distinct from this idea: Set/Get Variant Attribute for Multiple Attributes).

Ideally the wildcard would be RegEx.  If it were, the means by which you specify what to return is standardized.

 

In the above example, there would be some ambiguity in terms of whether or not you would want to return a result or an array of results given an input, and I doubt you could detect and assume RegEx is what the programmer desires to use.  So I think this means a new input would be required to specify whether or not the "name" input of the Get Variant Attribute VI should be interpreted as a RegEx query.

[chris_d754]

I like this idea. Some caveats... what if the data type was an array? Then you would have an array of array which is not legal. Some problems could arise when data of the wrong type is found. Do you return all data that is of the same type and ignore the rest? Do you just return one default value? I think with some thought this would be useful.

[X.]

Sounds neat, but the exceptions listed previously being kind of the rule (I put all kind of stuff in variant by attribute), that's wishful thinking.

I don't see what's wrong with wrapping up your current method into an application specific subVI?

[AristosQueue (NI)]

Why RegEx? Why not SQL query? Why not filename wildcard matching?

I don't see anything that makes RegEx special. For this kind of functionality, the code that you've written seems like exactly the right way to do it rather than bolting a RegEx parser or any other system into the primitives or clouding the palette with a bunch of primitives to support various search functions. I could see a primitive that takes a VI refnum that has a conpane of string in/boolean out that you would pass in to supply the filter functionality that you want for any given application, but even that I'd lean toward just letting that be a library that someone writes on top of the primitives. Yes, there is some memory reduction that can be done if it is internal to the primitives, no question about that. But there are so many variations in how to do that filtration/sorting/etc that I'm not confident that any prim would cover a sufficient use case to be worth it. I could be wrong here ... let's see what other comments come in.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.