Jump to content

What is best

Recommended Posts

If the data is accessible by the VI, I tend to stick with an unbundle.  I heard that using a property node forces a switch to the UI thread, and it wasn't clear to me if that wasn't the case for class data or not, so I just avoid them if I can.  That is one place that NXG did improve on the design of classes and clusters.  A cluster was accessed with a property node like it was a class.  This made the conversion from a cluster to a class easier, since the methods to access the data were the same.

Link to comment
1 hour ago, hooovahh said:

I heard that using a property node forces a switch to the UI thread, and it wasn't clear to me if that wasn't the case for class data or not, so I just avoid them if I can.

It does not apply to classes.  In fact, the UI thread is only used in property nodes that somehow reference a front panel or something on a front panel (ex controls/indicators).  VISA property nodes, for instance, do not use the UI thread.

The downside to me for the property node for accessing private data in a class is that you have to have an accessor VI to do so.  You do not need the accessor VI if you are using the bundle/unbundle by name.

Link to comment
1 hour ago, Neil Pate said:

I exclusively use the bundle/unbundle, unless I am not able to for example if accessing a field in a parent class.

I tend to also follow this concept.  And, often, the accessors will be set to "Protected" so that only children classes can use them.

Link to comment

+1 for Unbundle. It it simple, requires less code and you understand immediately that these elements belong to the current class. They are also easier to maintain in case you ever feel the need to change the name or type of an element and work well with In-Place Element Structures in Unbundle-Bundle-Scenarios.

  • Thanks 1
Link to comment

Thank you all for your answers. I understand better 🙂. I think I took the wrong reflex, to make access VI for all the commands of the object, in case it would be useful to me 🙄. I had a quick training on objects 2 years ago. This training lasted only 2 days, but it challenged everything I thought I knew about labview 🤯😵
I have to say that I have been self-taught for many years, and that having an object training with a CLA, made me realize that my codes were very bad , even if they worked and nobody saw them 😰

But thanks to this forum, I have real answers to my questions, so thank you all very much for that 🙏

And I still have a lot of questions 😏

Link to comment

When I did my first big LabVIEW OOP project (from scratch) a few years back I went "all in" with creating accessor nodes.

Maybe it works better in other programming languages but in LabVIEW all those read write vi's clutters up. There are a few cases where it could be useful, like if you have a underlying property of the class (like time) and you want to read it in different formats (timestamp, string, double) making an accessor vi with small modifing code can be quite neat.

Also I work with a real time application and since each accessor is a vi I'm not sure of it affects preformance. Extra settings like reentrancy needs to be taken into account I guess. So now when I'm trying to identify preformance issues I replace any accessor node possible with bundle/unbundle just to be safe.

Fully agrees with @Neil Pate. Nowadays I'm much more restrictive.

Edited by codcoder
  • Thanks 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.