Darren's Occasional Nugget 07/11/2013

[Darren]

Quick tip...I learned this little tidbit from browsing LAVA today. You can wire a Data Value Reference of a class to a property node and it works:

Both calls return '123' and no error. Pretty cool!

[Nate_Moehring]

Why oh why won't they let us do that with method VIs?  A property VI is just a simple method VI.  I'd love to be able to wire an object DVR either to an invoke node OR to the method VI directly...

[Darren]

I agree, Nate. In fact, one time a while back I was discussing class architecture topics with some colleagues and I just assumed that wiring a class DVR to a dynamic dispatch terminal would work. I was disappointed when I found out otherwise.

[fabric]

On a slight tangent: Do you happen to know if class accessor PNs incur the same performance hit as regular PNs? I presume their implementation is quite different, but I've always wondered...

[tst]

Since some people might miss it, here's a clarification for the original post - you have to create property VIs for this to work. They're the only ones which are accessible though the property node.

---

@Nate_Moehring wrote:

Why oh why won't they let us do that with method VIs?

---

Nate already knows the answer, but for the sake of others, the short answer is that the locking behavior might be confusing if you call several VIs in sequence.

For the longer answer (and for a chance to vote to change it if that's what you want), go here, where you can debate this with AQ as much as you want - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Have-Dynamic-Dispatching-terminals-accept-Data-Value-r...

[tst]

---

@fabric wrote:
On a slight tangent: Do you happen to know if class accessor PNs incur the same performance hit as regular PNs? I presume their implementation is quite different, but I've always wondered...

---

As far as I know, the answer is a definite no. Regular PNs have performance penalties because they deal with the UI objects and have to go through the UI thread. These PNs simply serve as a wrapper for a DVR action and a VI call. I believe the same is true of PNs of other classes, such as VISA, DAQmx or even VI server classes which aren't for UI objects, although I'll admit I'm just guessing here and certainly the last one could be wrong.

[ohiofudu]

Darren thanks for shearing .

[Darren]

Thanks tst for answering those questions. To my knowledge, any VI Server property node call goes through the UI thread, even those for non-UI objects.

[GregFreeman]

This is a good trick. I'm quite fond of property nodes with classes for one simple reason: They separate Public, protected, and private properties in the selection dropdown. This is beneficial for two reasons. 1) When using VIs as accessors, it is much more difficult to determine their access scope visually. 2) When working with a child class, I don't have to go to the project dialog and look in the parent class to determine what accessors it has; they are automatically populated in the property node (with the caveats TST mentioned above on creation of accessors).

[egraham]

I take it no one here has been scared off from using property nodes instead of accessor VIs in their classes? We've seen some strange bugs using these in 2011, but haven't confirmed if they have been fixed in 2012... mainly because no one wants to risk using them anymore.

One bug in particular that I can recall is that if a typedef enum resides in class private data, it will lose its association with the typedef when accessed via a property node rather than an accessor VI. Maybe this has been fixed? I like the idea of using property nodes to get to my data, but bugs I've seen have deterred me.