An Introduction to Class Hierarchies in LabVIEW

The introduction of a few key features in LabVIEW 6i, such as control references, has prompted many questions about classes and object orientation in LabVIEW. In this article, we will take a look at the concepts behind classes and how the latest versions of LabVIEW give users more ability than ever to programmatically manipulate LabVIEW objects.

You can think of an object as an instance of some kind of entity that has known characteristics and behaviors. Given this definition, everything from a front panel control to a menu item can be considered an object. In practice, LabVIEW allows the programmer to manipulate only a specific set of objects. Over time, the number of accessible objects has grown. Because there are so many accessible objects, it is necessary to organize them in some useful way. This brings us to the idea of class.
Objects can be grouped into classes based on the degree to which they are similar. The organization of the animal kingdom is a useful analogy. Each species of animal can be considered a class. We can define a class called dog and a class called wolf. Dogs and wolves are different enough that they can be defined as distinct classes. However, dogs and wolves share many characteristics. Because of this, class dog and class wolf can both be considered subclasses of a class called canine. All subclasses of class canine have certain commonalities as well as certain differences.

Objects in LabVIEW can be classed in a similar way. Boolean controls are members of a class called Boolean. However, there are other kinds of controls besides Boolean, such as numeric controls or array controls. So class Boolean is a subclass of class Control, along with other subclasses such as Array. Of course, the classes depicted in Figure 1 represent only part of a large hierarchy of both animals and LabVIEW objects¹. We place objects in a class hierarchy based on their characteristics and behaviors. In LabVIEW, we call these characteristics properties, and we call these behaviors methods. Objects that are members of the same class expose the same properties and methods. Some of these properties and methods are particular to the class itself, and some are inherited from higher classes in the hierarchy.



To illustrate this, examine the properties and methods exposed by an object of class Boolean. Example1.vi, included on this issue's LTR resource CD, contains a Boolean control, Bool1. You can access the properties of Bool1 using a property node. Two kinds of property nodes are shown on the diagram (see Figure 2). One is implicitly linked. It is linked to a particular control through its pop-up menu. The other is explicitly linked, meaning it has been wired to a control reference. (Control references are a powerful new feature of LabVIEW 6i; they allow the programmer to set properties and methods of an object in a VI other than the one in which the object exists.) In both cases, the properties available in the property node are specific to the class of which the control is a member. Figure 3 lists the available properties for class Boolean.


Now examine a similar example (see Figure 4). Example2.vi has on its panel an array control, Array1. A reference to Array1 is wired to a property node.


Figure 5 lists the available properties for class Array.


The properties available for class Array are similar to the properties available for class Boolean. In fact, only the properties in the bottom section of the menu differ. This gives us a hint of how classes Boolean and Array are related. They are similar enough that they share many properties, yet different enough that they have their own specific properties. The properties in the upper and middle parts of the menu are inherited from higher-level classes. For example, all controls have a description, but Number of Rows and Number of Columns are specific to class Array.

Suppose you want to write a VI that can be set to read the text color of any digital numeric control on a VI front panel. For a given company, red numeric text might be a standard way to indicate that a certain global condition is true. In this case, a VI that could manipulate other VIs' numeric text in a generic, reusable way would be useful.

Figure 6 shows one approach to this problem, and it illustrates several key concepts. (Notice that most of the error checking in this VI has been omitted for clarity.)


Example3.vi receives as its input a reference to the VI whose digital numeric controls you want to manipulate. (The calling VI would have used the Open VI Reference function to return this reference and pass it to Example3.vi.) The first question that arises is how do we use a reference to the VI to manipulate that VI's controls? First we need to get to the VI's panel. We do this using a property node. Notice that the Panel property itself returns a reference. This is an important point: some properties and methods return references to other objects. To return to the animal analogy, one of the properties of a dog might be fur. The fur property would return a reference to the dog's fur. Fur has its own properties, such as color and length. In a similar way, each VI has a panel, which in turn has its own properties and methods.

At this point we have a reference to the VI's panel. Next we need to obtain references to the digital numeric controls on that panel. One of the properties available for class Panel is Controls [ ]. This property returns an array of references to all the controls on the panel. We know that arrays, even arrays of refnums, can only contain one data type. How can this array hold the references of many different classes of controls? The answer is that the references to these controls are cast to a more generic class, namely class Control, before they are returned from the Controls [ ] property.

We now have references to all the controls on the panel, but we are only concerned with manipulating the properties of the digital numeric controls. How can we tell which references belong to digital numeric controls? We need to test each reference. We can do this by using the To More Specific Class function. This function explicitly casts a reference from a more generic class to a more specific class. In this case, we are attempting to cast each reference of class control to class digital. A Class Specifier Constant² is wired into the To More Specific Class function for the purpose of specifying the class to which we would like to cast. If the control whose reference is being cast is a digital, the To More Specific Class function will succeed, and the reference will be cast to class Digital. Otherwise, the function will return an error. We test the error condition using a Case structure.

You might be wondering how the references retain knowledge of their specific class once they have been cast to a more generic class (which is what happens internally when the references are returned from the Controls [ ] property). Each reference, regardless of how it is cast up and down the hierarchy, maintains a Class ID that is unique to its most specific class (the lowest class of which it is a member in the hierarchy). This ID, which is an integer, is accessible through the Class ID property.

Continuing with the example, in the True case, we know that we have a reference to a digital numeric control. One of the properties of a digital numeric control is NumText.TextColor³. We can set this property to red using a color box constant.

This article describes some of the general theory behind class hierarchies and their usage. A good understanding of the specifics of LabVIEW's class hierarchy takes time and experimentation. Don't be daunted by the size of the hierarchy; you can begin to write useful applications with only a basic understanding. One good way to experiment is to drop a property node and configure its class (choose Select VI Server Class from the pop-up menu). Then examine the properties you see. After you see enough classes, you will begin to get a better feel for the overall hierarchy. Once you do this, you will have a whole new set of functionality at your disposal that LabVIEW users could only dream about a few short years ago. What’s more, your knowledge will be extensible in future versions as the LabVIEW team continues to expose more objects to the programmer, making LabVIEW an even more powerful tool.

¹ You might be aware that National Instruments introduced other classes in LabVIEW prior to version 6i, such as class Application and class VirtualInstrument. Classes also exist for certain interfaces, such as VISA and ActiveX. The concepts discussed in this article also apply to these classes. See the author’s article, Serving up Powerful Solutions: LabVIEW VI Server Examples in LTR Volume 6, Number 4, for a more specific discussion of classes Application and VirtualInstrument. You can view the entire LabVIEW class hierarchy in the LabVIEW online help. Search for "Properties and Methods Class Hierarchy" in the index.

² The Class Specifier Constant has a type that is configurable at edit-time and fixed at compile-time, but its value is always not a refnum. For this reason, you should use the Class Specifier Constant only for its type. One incorrect usage would be to equate a Class Specifier Constant to a control reference, as shown in Figure 7. The result will always be false.


³ The dot notation is a nuance of the property node. When a property returns a reference to another object (the numeric text), you can access the properties of this object (the color) in the same property node, that is, without needing a separate wire and property node for the returned reference.

About LTR
LabVIEW Technical Resource(^TM), LTR, is the leading independent source of LabVIEW-specific information. Each LTR issue presents powerful tips and techniques and includes a Resource CD packed with VIs, Utilities, Source Code, and Documentation.

About the Author
Steven Harrison is a former Product Support Engineer for LabVIEW and currently manages the Product Support Engineers at National Instruments. He can be reached at steven.harrison@ni.com.

Reader Comments | Submit a comment »