‘LVOOP’ Category Archives
Have you ever wanted to customize the appearance of a type def wire, e.g. by making it a different color? Unfortunately, you can’t.
But you can customize the appearance of wires for a given LabVIEW Class (LVClass) type! This is another way that LVClasses are like type defs with superpowers.
To customize an LVClass wire appearance, right-click on the LVClass item in the Project tree and select Properties.
In the Properties dialog, select the Wire Appearance category and change the radio button to “Use custom design.”
Then you can have fun playing with the pattern, colors and size!
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.”
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… 🙂