@DavidCanning wrote:
Say I have a local Enum control. I can create a VI Server Reference and link it to the Enum. Using that Enum refnum I can access the properties of the Enum (e.g. Value, Strings[], and so on) using a property node.
My question is, is there any way to achieve the same thing as using VI Server Reference + Link in a way that takes the local Enum control as an input.
Assuming that the Enum is some sort of class in the background.
It is. That's why you can access its properties once you get a reference to the control. You can even get a feel for it's inheritance hierarchy by right clicking on a refnum control and digging through the "Select VI Server class" menu.
It is not, however, a by-value LVOOP class (.lvclass). VI Server classes and LVOOP classes are two rather different things. Properties and methods on VI Server classes are accessed by reference, and you need to obtain that reference before use.
The enum wire, on the other hand, is value based. It does not carry type information, only the value. This is similar to how some other languages work as well. For example, in C# an enum is a value type:
MyEnum value;
var names1 = value.GetNames(); // Doesn't work.
var names2 = Enum.GetNames(typeof(MyEnum)); // Does.
"names1" doesn't work. The "value" variable only stores an integer value. You cannot read type information, such as the names of all the enum members, from it because it does not contain that data. Trying to perform GetNames() on the variable itself is sort of like trying to pass an enum wire to a Property Node.
"names2" does work. You need to create a reference to the MyEnum type itself, which can then be passed to a static method that uses reflection to obtain the member names from the Type data. This is sort of like the convert to variant then read type definition data method Rolf mentioned, and like that method does have some performance impact. (VI Server is, I suppose, also kind of similar with the twist that you need to use a control reference so you're forced into the UI thread.)
Wires in LabVIEW are always value based, even when the value they are carrying is a refnum.
@DavidCanning wrote:
If I write a class and create Read/Write VIs for Data Member Access for a class with "Make Available Through Property Nodes" checked, I get a bog standard Read accessor that takes the class itself as input to read each property. Is this a deliberate design choice by LabVIEW and, if so, what is the thinking behind it?
The "bog standard" accessor VI still exists, however if you check that box you will find that you can also wire the class to a property node and it will have those accessors available.
Sometimes setting a property can have some side-effect or require some data validation or such. Still having the accessor VI is necessary to maintain the ability to implement functionality beyond simply reading/writing the object's private data. They are what the property node will use when accessing those properties. Using a property node vs. chaining a bunch of accessor VIs is (mostly) a style choice.
There are some that dislike this feature because it does work differently from how Property Nodes are normally used with refnums. I don't really mind it, but you could see it as mixing reference vs. value semantics.
