Any downsides to class property nodes?

[JÞB]

---

@Darren wrote:

As far as threading is concerned, class property nodes behave identically to accessor subVIs. So the use of a class property node alone won't require the UI thread.

I've got some performance-sensitive code that uses tons of class property nodes... they're all marked as inline and things work great.

---

Thanks for that!  Basically then the error handling options are the only real difference then since the p node can ignore errors but lacks the new ability to preserve all errors.

Is NI considering adding preserve all errors to property nodes similar to the newer merge errors.preserve all errors option?  Or, should I just post that to the Idea Exchange?

[Darren]

---

@JÞB wrote:

Is NI considering adding preserve all errors to property nodes similar to the newer merge errors.preserve all errors option?  Or, should I just post that to the Idea Exchange?

---

I haven't heard of any planned changes to the way class property nodes work. But I've also been out of LabVIEW R&D for over two years now, so my finger isn't on the pulse now like it was back then.

I agree that the error behavior of class property nodes is weird. The 'error in' of the property accessor VI itself is effectively ignored. If there's an error coming into the property node, it doesn't matter what your error logic looks like in your property accessor VI... it just won't run. This inconsistency is the reason that I almost never wire the error terminals on class property nodes.

[Yamaeda]

---

@Darren wrote:

Can you give me specific steps to reproduce this issue? I have not had issues using 'Find' (either in VIs or in the project) for class property VIs, including inherited method VIs.

---

Create a class with a property and a child of said class. Also create a public method in the base class.

Create 2 VIs, one that has the base class and uses both the property and public method, the other with the child class.

R-click the public method and Find Callers, it'll only find the base class VI, not the child one.

R-click the property node VI and Find Callers. It'll only find the base class VI _if it's open_, not the child one.

Open the property node VI and Find All Instances. It'll only find the base class VI _if it's open_, not the child one.

(The example is G#, but the fact that data is accessed through DVRs should hardly affect this, right?)

[wiebe@CARYA]

---

@Yamaeda wrote:

---

@Darren wrote:

Can you give me specific steps to reproduce this issue? I have not had issues using 'Find' (either in VIs or in the project) for class property VIs, including inherited method VIs.

---

Create a class with a property and a child of said class. Also create a public method in the base class.

Create 2 VIs, one that has the base class and uses both the property and public method, the other with the child class.

R-click the public method and Find Callers, it'll only find the base class VI, not the child one.

R-click the property node VI and Find Callers. It'll only find the base class VI _if it's open_, not the child one.

Open the property node VI and Find All Instances. It'll only find the base class VI _if it's open_, not the child one.

(The example is G#, but the fact that data is accessed through DVRs should hardly affect this, right?)

---

This made me dismiss class properties. If I can't trace back to where it's used, I won't use it.

I also like that VIs have an indication of the class the VI lives in.

Opening the VIs is a lot easier.

I heard class properties don't need error in\error out (anymore?). This is often just noise, so I don't want them. It seems a class property still needs them? 

I do agree that a bad icon is worse than a good text. The property's compactness is nice as well, and if you need more properties, it is faster to create.

[Yamaeda]

Maybe i should add it's LV2018 above, the find seems a little better in 2020.

[OneOfTheDans]

Thanks everyone - my takeaway is that:

1. There is no performance hit by using class properties.
2. They handle errors in an unexpected way, so best practice is to leave errors un-wired.
3. The LabVIEW IDE has bugs that can...
   1. create corrupted properties (fixable by ludicrous black magic)
   2. prevent properties turning up in searches like "Find All Instances"

Personally, this is a green light to keep on using them everywhere, mindful of the caveats you've all pointed out.

[tst]

And one more issue. I'm fairly sure that having a property node would cause a dirty dot (i.e. it would require saving the VI) in caller VIs in certain conditions (probably when updating the typedef of the property VI input/output, but I haven't checked specifically), which didn't happen when calling the VI directly. Like I said, I haven't checked exactly when this happens and I haven't checked in recent LV versions to see if this still happens.

This isn't a real problem, but is annoying if you have to keep dismissing save dialogs or to commit VIs which weren't actually modified to your SCC.

[wiebe@CARYA]

---

@OneOfTheDans wrote:

Thanks everyone - my takeaway is that:

1. There is no performance hit by using class properties.
2. They handle errors in an unexpected way, so best practice is to leave errors un-wired.
3. The LabVIEW IDE has bugs that can...
   1. create corrupted properties (fixable by ludicrous black magic)
   2. prevent properties turning up in searches like "Find All Instances"

Personally, this is a green light to keep on using them everywhere, mindful of the caveats you've all pointed out.

---

You're not wrong. You made a reasonable educated choice, so go for it.

For me:

1) There is a performance hit with class properties. Some days I open >50 accessors and having to right click and select a menu then open the diagram is a performance hit. Not just time, RSI as well.

2) Is a matter of education... It makes sense to me, as it seems to be how all properties (e.g. VI server properties) are handled. "Ignore errors inside" will have effect on the behavior of inside errors.

3.1) That happens. I can handle that.

3.2) Deal breaker.

AFAIC, 3.2) needs to be fixed with the highest priority.

Not only does it not work, you also don't get any indication that it doesn't work. This could lead major time loss. For instance, a redesign based on information is a total waste of time, when you find a property that "Find All Instances" didn't find...

Iff 3.2 gets fixed, it might flip the scale for me...