Intro to LVOOP – Part 1

Aug 21st, 2012 by Christina in LabVIEW, LVOOP

After talking to a few people who were learning LabVIEW Object-Oriented Programming (LVOOP) at NIWeek, I decided to revisit an introduction to LVOOP here on my blog.

You can think of a LabVIEW Class (LVClass) as a cluster with superpowers. An LVClass has many of the advantages of a type definition but it also gives you much more.

Creating a LabVIEW Class

To create an LVClass, you should be in a Project. (It’s not required, but I strongly recommend it).

Right-click on a target (such as My Computer) in your Project Explorer window and select “New>>Class.”

A dialog will ask you to name your LVClass. Let’s say you name it “Widget.” Two items will appear in your Project tree: Widget.lvclass and Widget.ctl.

The CTL item is not a separate file on disk. It is the private data control for the LVClass. Every LVClass must have one (and only one) private data control, and it is saved in the .lvclass file on disk.

Edit the CTL file and you will see an empty cluster. This is the heart of your LVClass. It is where you define the data members.

Let’s say you want two data members: a Color box and a Boolean. You simply add controls to the cluster.

You may think there is a similarity between this Widget class private data control and a type definition. And you would be correct! But the users of this LVClass cannot unbundle the cluster to access the elements – only VIs that are members of the LVClass can do that.

If you want VIs outside of the LVClass to know about a data member – for example, to be able to read the value of the color box – then you need to create a VI for Data Member Access. Rather than bundling/unbundling the cluster, VIs outside of the class must use the interface VI.

So you can think of an LVClass as being like a type def cluster that’s a “black box” to the VIs that use it. They can “see” the interfaces (e.g. that they can read a color) but they have no idea what else is in the cluster.

The encapsulation of the LVClass also makes it easy to perform actions whenever a data member is read or written. As the designer of the LVClass, you know that there is no way a VI can read or write these data members without going through the VI interfaces you have created for the LVClass.

More on LVClasses later! If you have any questions on the basics, feel free to post them in the Comments. If you have any questions beyond the basics, there’s this place online where the most amazing experts hang out called LAVA… 🙂

4 Comments

  • When I was first learning about LVOOP, my first revelation was that an object is by value rather than by reference.

    Consider other objects in LabVIEW that you’re probably familiar with – say a VI Server object reference to a front panel control. If you branch the wire from the reference and invoke two separate methods on each wire, they both affect the same control, because VI Server classes are by reference.

    LVOOP on the other hand is natively by value – if you branch the wire, you get two copies of the object. Once I finally learned to treat the LVOOP object wire just like I would a cluster wire (rather than, say, a VI Server reference), method invocation and property setting finally made sense.

    I’m not trying to stray from the post topic with some by-ref vs. by-val rabbit trail, I’d like to bolster her point: think of an object as a cluster, and with this by-val mentality you’ll be much more successful than I was starting off 🙂

  • Jack, thanks for the comment! You are correct, the by-value vs. by-reference concept causes much confusion, especially for people who have experience with previous by-reference OO systems before learning LVOOP. For those who have a solid understanding of Object-Oriented design and are curious why LabVIEW uses by-value objects, I recommend the white paper “LabVIEW Object-Oriented Programming: The Decisions Behind the Design”: http://www.ni.com/white-paper/3574/en

  • Consider a small group of developers (2-3), is using LabVIEW OOP still beneficial?
    Can you point toward a resource that enlists all the practical advantages of using LVOOP?

  • Depending on the project, LVOOP can be beneficial even with small teams (or single developers). I’d suggest reviewing the LabVIEW Object-Oriented Programming FAQ for an extended discussion of the benefits of LVOOP.

 

Comments have been closed for this post.