LVOOP Frequently Asked Questions

From LabVIEW Wiki
Jump to: navigation, search

This is a stub page for Frequently Asked Questions (FAQ) about LVOOP. Please feel free to add to the list of FAQ and answer any of the questions that have been posted.

You may find many questions already answered on the LVOOP FAQ on NI's website. That FAQ will be updated by NI for new versions of LabVIEW and new OO tools as they become available.

Why is class data private?

In general object-oriented programming terms, attributes (like methods) can have private, protected, or public visibility. In practice individual object-oriented programming languages have differing capabilities when it comes to specifying visibility. In the UML attributes are generally assumed to have private visibility unless otherwise specified. (Operations, on the other hand, are assumed to be public unless otherwise specified.) Generally, OOP style guides say never to give attributes public visibility, and the so-called “Law of Demeter” in its strong form limits attribute visibilities to private. In other words, access to data in a class from outside the class is always through accessor methods (‘set’ or ‘get’) methods. In LVOOP this is the only choice, a decision designed to promote good code designs with minimal coupling. (See further here: [1]). (Note that LabVIEW 8.5 introduces a “Create Accessor” dialog box to simplify the creation of accessor methods. For more information on this dialog box see the LabVIEW 8.5 Upgrade Notes here: [2].)

What are the differences between public, protected, and private class members?

In Object-Oriented Programming terms these generally mean:

A private feature (UML abbreviation -) is accessible only from the defining class. A public feature (+) is accessible from outside the class. A protected feature (#) is (in C++, for example) accessible from the defining class and any of its child classes. The UML also has an abbreviation for package (~) visibility. The exact meaning of the different visibilities varies among different programming languages.

In 2009 LabVIEW introduced Community scoping to classes (and other project libraries.) Community scoped items are the same as private items, except they are visible to external entities specifically designated as "Friends of This Library." Some important things to keep in mind with community scoping are:

  • Friendship is a one-way permission granted by a class giving external entities access to community scoped items. If Class A makes Class B a friend, Class B has access to Class A's community scoped items, but Class A does not have access to Class B's community scoped items.
  • Child classes are not automatically granted access to a parent's community scoped items.

Why are there no class constructor and destructor?

Are objects by value or by reference?

What does LVOOP mean?

LVOOP (pronounced "el vee oop") stands for LabVIEW Object-Oriented Programming.

How can I create by reference objects?

How can I create active objects?

Are there any add on tools for LVOOP?

What does the "Dynamic Dispatch" connector pane terminal setting do?

My LVOOP class control has a black border, what does that mean ?

A LVOOP class has a default value that is determined by the default value of the private data control in the .lvclass file. However, a control on a vi front panel, or a constant on a block diagram can also have a default value that is different from the default data for the class as a whole. When this happens the control (or constant) is given a black border. It can just as easily be a non-default value of the class itself, so if your private data cluster contains a numeric whose default value is 5, this control may have the numeric with a default value of 6.

When there is a class heirarchy, it is possible for a parent class method to process an instance of a child class. Similarily, it is possible to set the default value of a parent class control or constant to be an instance of a child class. This will also result in a black border around the parent class control or constant. When this happens with a member vi of the parent class, the parent class becomes dependent on the child class in addition to the normal dependency of the child on the parent. This can be confusing and awkward to locate.

To change the default value of a class control run a VI such that a non-default value ends up in an indicator, then do one of the following:
A) Right click on that indicator and choose "Make Current Value Default" or
B) Right click on that indicator and choose "Change to Constant" (the current value of a control/indicator always becomes the value of the constant)