LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Any downsides to class property nodes?

Solved!
Go to solution

@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?


"Should be" isn't "Is" -Jay
0 Kudos
Message 11 of 18
(379 Views)

@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.

Message 12 of 18
(370 Views)

@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?)

 

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
Message 13 of 18
(323 Views)

@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.

0 Kudos
Message 14 of 18
(307 Views)

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

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 15 of 18
(281 Views)

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.

Message 16 of 18
(237 Views)

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.


___________________
Try to take over the world!
0 Kudos
Message 17 of 18
(185 Views)

@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...

Message 18 of 18
(164 Views)