Set/Get Property By Name

[TimS.]

So as I was thinking about easier ways to write set/get VI's for LV Classes and I realized "wouldn't be great if there was a way to set/get any property in a property node by name?". I've implemented this a couple of times on my own by creating a subVI that does set (or get) based on long name string input and string data value. This could also be a combination of enum property selection and variant data or multiple other possibilities but you get the idea.

There is already a Browse option in property nodes - what if we could take it one step further and have a "By Name" selection in a property node with data bundled in somehow (i.e. cluster or seperate line item)? This removes the need for creating large sets of code to set individual properties when high cohesion and loose coupling is kept in mind 😉

Regards,

Tim Sileo

[CMal]

I think this is a really interesting idea.  Keep in mind that there would be a potentially large performance reduction because the property node would be figuring out which property to read/write at runtime.  Doing a name lookup like this is significantly slower than accessing a parameter that is specified at edit time.  Also, since the data type isn't known until runtime, the "data" terminal would need to be a variant, and there would be a type conversion done on each read or write, which would add more of a performance penalty.  Still, I think this idea has merit.

[TimS.]

Thanks! Yes, on the performance vs flexibility spectrum it would have very high flexibility but diminished performance. Some users would want to squeeze out every last bit of performance so this wouldn't be for them but for others I think the appeal to write "one subVI to rule all property read/writes" would be great. The best application for something like this would be for properties that are infrequently read or written to (i.e. application startup, larger system initialization, TestStand setup group, etc.). It wouldn't be good to use this approach in a runnnig state where properties need to change rapidly.

Also, I used a string for easier cross-platform or cross-application usability. (i.e. TestStand management of variables or other programming languages). Presumably, the property node under the hood would have the appropriate method for converting from string input to correct data type. So, it would have to search for the property first then look at the string input for data and convert appropriately. If property wasn't found by name or the data input couldn't be converted correctly then it would throw an error. I think that most of the properties I've ever run across can be boiled down to either text/string or numeric. As examples:

- resource name or channel selection properties can accept strings.

- enum properties are numerics. the digital display or detailed help will let a user know what the valid values are

- boolean properties can be 0/1 or T/F or both. As long as the syntax is documented it wouldn't matter.

- properties that are arrays of any of the above can use a delimiter in the string input.

Oh and there could be ways to speed up execution of this property by name approach. Something like an array of the Name/Data cluster feeding a for loop with parallel execution that calls a subVI using property by name. Setting properties is linear in a single property node but now we could parallelize it. Not sure if this would work entirely so please shoot it down if there are caveats I'm missing ;-).

Let me know what you all think!

-Tim

[AristosQueue (NI)]

Your "Data" input is shown in pink. Is that because you imagine it to be a flattened string? Or would you make it a Variant?

[TimS.]

I'm trying to remove the need of a programmer having to format data by keeping the input a normal string. Why have a "property loader" step in your code (or TestStand) if the code under the hood takes care of it for you? As I mentioned above, each property node would know how to convert that string text to the appropriate data type. After scanning through a ton of properties I barely saw any that couldn't be boiled down to the list I mention above. There are very few complex structure based properties to set (i.e. clusters/arrays).

There are many programmers who store configuration data or properties in files such as ini or xml. Wouldn't it be cool to be able to read each item in that file simply as a string and not have to manually program data type conversions in your code? Simple, sweet, easy to maintain, and very scalable if more properties are added later. Aside from developers who need to focus on performance optimizations the only code needed for setting properties would be like the image below. It won't be fast but it will definitely be extremely convenient.

 

[Darren]

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

[nanocyte]

I know this is declined but, FYI, there's a precident for how this should look. In the IMAQdx camera properties, you can select an "Active Attribute" and then set the value in the next node. You can keep going selecting more activeattributes. The purpose is exactly as you described. To grabe data from a config file and apply it.