Programmatically Set a Property Item

[paul_cardinale 20]

I want to set a property item in a Property node.  For properties that have a single ID, I can get this method to work:

For example, setting a property item for a Control property node to "Label" simply requires the ID string "6332005"; yielding:

However many properties require more that one ID.  For instance: requires "6332005" (Label), and "632d800" (text).

I can't find a way to set a property item to a property that has such multiple levels.

Does anyone know how to do this?

 

Paul Cardinale

[hooovahh 732]

Someone from NI can chime in, but I think this is not possible and is one of those limitations of LabVIEW Scripting.  QuickDrop has a CTRL+Shift+B that operates on a property node and it has a limitation of not working with "dotted properties".  I assume that's due to a limitation with LabVIEW's scripting otherwise NI would have supported it.

[Darren 194]

Correct. Scripting does not support setting dotted properties.

[paul_cardinale 20]

I found it!  Unfortunately it's deprecated.

It takes dotted inputs as either names or ID codes.

Edited December 13, 2018 by paul_cardinale

[hooovahh 732]

Wow I never knew about that and the fact that it can handle dotted properties is awesome.  Darren is there a reason we shouldn't be using this thing that does exactly what we might want when the proper method lacks this functionality?

[Darren 194]

I had no idea this existed. I will look into it.

[Darren 194]

Thanks for digging this up, Paul. I got it to work for dotted properties of multiple levels (so not only Label.Text, but also things like Terminal.Wire.Terms[]). I'm going to try to update the VI Server Rename plugin for Quick Drop to allow setting dotted properties by using this deprecated property. (?)

[hooovahh 732]

So does that mean that this deprecated function is still semi-supported?  I assume it was deprecated for a reason, is it unstable under any known circumstance?

[Darren 194]

On 1/14/2019 at 8:45 AM, hooovahh said:

So does that mean that this deprecated function is still semi-supported?  I assume it was deprecated for a reason, is it unstable under any known circumstance?

If I recall correctly, it was deprecated because the current property is more explicit about how you're assigning the property name (ID, short name, long name), whereas the deprecated property was more ambiguous (you could wire in any of them I think). But to my knowledge, there's no problem using the deprecated property. When I update the VI Server Rename plugin, I'll make sure to only call the deprecated property if there's a period in the specified property name.

[flarn2006 88]

Does this mean its deprecated status will be removed?

Also Paul, just wondering, how did you find that property?

[Darren 194]

19 hours ago, flarn2006 said:

Does this mean its deprecated status will be removed?

Not in 2019. But we will look into consolidating the API in 2020 so the non-deprecated method is able to set dotted properties like the deprecated property can.

[paul_cardinale 20]

A long time ago (maybe around LV 7) I created a VI that was just a set of property nodes: One for every class (that I knew of), each node having every possible property.  I think that when I created it, that property wasn't deprecated.

All_Methods.vi

All_Properties.vi

[Yair 224]

Darren, any chance of getting the All Supported Properties property of the Property class (i.e. the property node) to actually return all the supported properties for the current class of the property node, including all of the nested ones?

As it is today, that property only returns the top level properties (so it would show a Label property if the node is linked to a class inheriting from Control, but not all the subproperties coming from the Label class).

If that's too hard for support reasons, maybe at least adding a new property which will actually return all of them?

[Darren 194]

6 hours ago, Yair said:

Darren, any chance of getting the All Supported Properties property of the Property class (i.e. the property node) to actually return all the supported properties for the current class of the property node, including all of the nested ones?

As it is today, that property only returns the top level properties (so it would show a Label property if the node is linked to a class inheriting from Control, but not all the subproperties coming from the Label class).

If that's too hard for support reasons, maybe at least adding a new property which will actually return all of them?

This is a good idea. I suggest posting it to the Idea Exchange.

[Yair 224]

OK - https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-the-All-Supported-Properties-property-return-nested/idi-p/4001207https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-the-All-Supported-Properties-property-return-nested/idi-p/4001207