Access Scope

When you give VIs to others to use, they generally fall into two categories: the VIs that they're supposed to call as subVIs (called interfaces), and supporting VIs that they're not supposed to call directly (which are subVIs of the interface VIs).

Pre-LabVIEW 8.0, you had no way to enforce that they didn't call your support VIs. When creating a new version of your VIs, you couldn't be sure whether or not you would break other people's VIs if you changed your support VIs.

In LabVIEW 8.0, we introduced the project library, which (in addition to namespacing) gives you the ability to set private access scope. Access scope lets you distinguish between your (public) interface VIs and your (private) support VIs.

If you're not yet familiar with project libraries (which we usually call simply libraries), let me clear up a common misconception. Libraries are not LLBs. LLBs are containers, where a single file on disk contains multiple VIs. Libraries are separate files on disk from their member items.

You can think of libraries like exclusive clubs. A VI can be a member of one and only one. Being a member gives the VI certain privileges, including the ability to call private VIs in the library.

In LabVIEW 8.20, we introduced LabVIEW Classes, which also have public and private access scope. (Classes are, in fact, a type of library). Classes, however, have an additional access scope called protected.

We used that name because it's used in other object-oriented languages and we couldn't come up with a better one. It is not, in my opinion, a good name. The obvious question is, "Protected from what?" So let me try to explain.

VIs that have protected access scope can be called by VIs in the same class or descendent classes. (That means classes that inherit from the class directly or indirectly).

There are cases in object-oriented design where you simply need this ability. For example, suppose you have a public interface VI for your class, and a support VI that it requires. What should the access scope of the support VI be? At this point, probably private.

But if you then make the interface VI dynamic so that child classes can override it, things change. If you want those override VIs to be able to call the support VI in the parent class, you can't have it be private. But you don't want VIs outside the classes to call it. So you make it protected.

Dynamic VIs and Override VIs

In order to take advantage of dynamic dispatching, you must have classes with dynamic member VIs.

A dynamic member VI is a VI that

• is a member of a class and
• has a dynamic input terminal.

A dynamic input terminal is the one that determine dynamic dispatching at run-time.

You can create a dynamic member VI by right-clicking on a class in the project tree and selecting New»Dynamic VI. You can also create one by creating a normal VI and configuring it to have a dynamic input. The New Dynamic VI option is just a convenient time-saver, creating the VI from a template and configuring it with an input and output of the selected class.

Should all class member VIs be dynamic? Probably not. The overall design will be clearer if only the VIs that you intend to override in child classes are dynamic. Note that you can easily change a member VI between dynamic and non-dynamic by configuring the connector pane terminals. In previous versions, a connector pane terminal could be Required, Recommended, or Optional. In LabVIEW 8.20, there is a new option called Dynamic Dispatch.

An override member VI is a dynamic VI that has the same name as a member VI in one of the class's ancestors. Again, there is a right-click New option on the class in the project tree that helps you create them.

A dynamic VI and its override VIs in child classes are a set of VIs that perform the same operation for a hierarchy of classes. We call the operation a method (from classic OO terminology), which means a method on a class is a VI or set of VIs.

Let's look at an example. In our new Getting Started window, we have an object to manage each of the link buttons. All of these objects are instances of classes that inherit from Link.

In the Link class, we have a dynamic VI called InitFromXML.vi. This VI parses a section of an XML file to get the data values that are stored in Link's private data cluster.

Now, if we look at the Web class, which inherits from Link, it also has an InitFromXML.vi. This VI parses the value that the Web class knows about (URL) from the XML. But it needs to do more. It needs to have its parent class do whatever work it does for InitFromXML. So it uses the Call Parent Method function.



This kind of override VI extends the functionality of its parent class.

If you look at another VI in Web, HandleItemActivation.vi, you'll find an override VI that replaces the functionality of its parent class (because it does not use the Call Parent Method function).

So, in summary of my point today, dynamic VIs allow you to extend or replace the functionality of a class in its child classes.