Programmatically Set a Property Item

[paul_cardinale 18]

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 695]

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 184]

Correct. Scripting does not support setting dotted properties.

[paul_cardinale 18]

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 695]

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 184]

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

[Darren 184]

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 695]

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 184]

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 184]

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 18]

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