Jump to content


Photo
- - - - -

[Eyes on VIs] Intro to LVOOP – Part 1


  • Please log in to reply
No replies to this topic

#1 Christina Rogers

Christina Rogers

    Very Active

  • NI
  • 91 posts
  • Location:Austin, TX
  • Version:LabVIEW 2012
  • Since:1997

Posted 21 August 2012 - 04:21 PM

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

Posted Image

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.

Posted Image

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.

Posted Image

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

Posted Image

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 LAVAPosted Image



View the full article