LabVIEW object-oriented programming FAQ - Revision history

Logmanoriginal: Update categories

2020-04-02T14:59:27Z

Update categories

← Older revision		Revision as of 14:59, 2 April 2020
Line 26:		Line 26:
	LVOOP (pronounced "el vee oop") stands for '''L'''ab'''V'''IEW '''O'''bject-'''O'''riented '''P'''rogramming.		LVOOP (pronounced "el vee oop") stands for '''L'''ab'''V'''IEW '''O'''bject-'''O'''riented '''P'''rogramming.

	~~[[Category:GOOP]]~~

	== How can I create by reference objects? ==		== How can I create by reference objects? ==
Line 44:		Line 44:
	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:<br>A) Right click on that indicator and choose "Make Current Value Default" or<br>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)		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:<br>A) Right click on that indicator and choose "Make Current Value Default" or<br>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)

	[[Category:~~GOOP~~]]		[[Category:Object-Oriented Programming]]
			[[Category:Frequently Asked Questions]]

Logmanoriginal: Logmanoriginal moved page LVOOP Frequently Asked Questions to LabVIEW object-oriented programming FAQ: Use a more descriptive page title

2020-04-02T14:56:10Z

Logmanoriginal moved page LVOOP Frequently Asked Questions to LabVIEW object-oriented programming FAQ: Use a more descriptive page title

← Older revision	Revision as of 14:56, 2 April 2020
(No difference)

Bryan: Added definition for acronym.

2019-01-18T12:01:56Z

Added definition for acronym.

← Older revision		Revision as of 12:01, 18 January 2019
Line 24:		Line 24:

	== What does LVOOP mean? ==		== What does LVOOP mean? ==
			LVOOP (pronounced "el vee oop") stands for '''L'''ab'''V'''IEW '''O'''bject-'''O'''riented '''P'''rogramming.

			[[Category:GOOP]]

	== How can I create by reference objects? ==		== How can I create by reference objects? ==

Daklu: /* What are the differences between public, protected, and private class members? */

2012-03-16T20:56:48Z

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

← Older revision		Revision as of 20:56, 16 March 2012
Line 12:		Line 12:

	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.		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? ==		== Why are there no class constructor and destructor? ==

Michael_Aivaliotis at 02:52, 21 February 2009

2009-02-21T02:52:49Z

Jgcode: Updated and added method to "My LVOOP control has black border" to set the default data of a LVOOP constant

2009-02-21T01:05:16Z

Updated and added method to "My LVOOP control has black border" to set the default data of a LVOOP constant

← Older revision		Revision as of 01:05, 21 February 2009
Line 1:		Line 1:
	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.		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 [http://zone.ni.com/devzone/cda/tut/p/id/3573 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.		You may find many questions already answered on the [http://zone.ni.com/devzone/cda/tut/p/id/3573 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: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (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: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)

	==~~What are the differences between public, protected, and~~ private ~~class members~~?==		== Why is class data private? ==
	~~In Object-Oriented Programming terms these generally mean:~~

	A private ~~feature (UML abbreviation~~ -~~) is accessible only from~~ the ~~defining class~~.		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: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (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: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)
	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~~.

	==~~Why~~ are ~~there no~~ class ~~constructor and destructor~~?==		== What are the differences between public, protected, and private class members? ==

	~~==Are objects by value or by reference?==~~		In Object-Oriented Programming terms these generally mean:

	~~==What does LVOOP 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.

	==~~How can I create by reference objects~~?==		== Why are there no class constructor and destructor? ==

	==~~How can I create active~~ objects?==		== Are objects by value or by reference? ==

	==~~Are there any add on tools for~~ LVOOP?==		== What does LVOOP mean? ==

	==~~What does the "Dynamic Dispatch" connector pane terminal setting do~~?==		== How can I create by reference objects? ==

	==~~My LVOOP class control has a black border, what does that mean~~ ? ==		== How can I create active objects? ==

	~~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.~~		== Are there any add on tools for LVOOP? ==

	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.		== 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:<br>A) Right click on that indicator and choose "Make Current Value Default" or<br>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)

			[[Category:GOOP]]

	[[Category:GOOP]]		[[Category:GOOP]]

Gb119: Add new QA about black border controls

2008-10-20T08:23:34Z

Add new QA about black border controls

← Older revision		Revision as of 08:23, 20 October 2008
Line 27:		Line 27:

	==What does the "Dynamic Dispatch" connector pane terminal setting do?==		==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.

			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.

	[[Category:GOOP]]		[[Category:GOOP]]

Paul lotz: /* What are the differences between public, protected, and private class members? */

2007-08-15T16:32:58Z

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

← Older revision		Revision as of 16:32, 15 August 2007
Line 6:		Line 6:

	==What are the differences between public, protected, and private class members?==		==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.

	==Why are there no class constructor and destructor?==		==Why are there no class constructor and destructor?==

Smercer: Add external link to NI's LVOOP FAQ

2007-08-14T21:03:28Z

Add external link to NI's LVOOP FAQ

← Older revision		Revision as of 21:03, 14 August 2007
Line 1:		Line 1:
	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.		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 [http://zone.ni.com/devzone/cda/tut/p/id/3573 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?==		==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: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (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: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)		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: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (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: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)

Paul lotz: /* Why is class data private? */

2007-08-14T20:32:57Z

Why is class data private?

← Older revision		Revision as of 20:32, 14 August 2007
Line 2:		Line 2:

	==Why is class data private?==		==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: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (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: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)

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

← Older revision		Revision as of 02:52, 21 February 2009
Line 1:		Line 1:
	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.		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 [http://zone.ni.com/devzone/cda/tut/p/id/3573 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.		You may find many questions already answered on the [http://zone.ni.com/devzone/cda/tut/p/id/3573 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? ==		== 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: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (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: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)		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: [http://zone.ni.com/devzone/cda/tut/p/id/3574]). (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: [http://digital.ni.com/manuals.nsf/websearch/7A60FDCEA6D2D8C4862572FD00159F5A].)

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

	In Object-Oriented Programming terms these generally mean:		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.		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.

	== Why are there no class constructor and destructor? ==		== Why are there no class constructor and destructor? ==
Line 29:		Line 29:
	== My LVOOP class control has a black border, what does that mean ? ==		== 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.		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.		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:<br>A) Right click on that indicator and choose "Make Current Value Default" or<br>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)		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:<br>A) Right click on that indicator and choose "Make Current Value Default" or<br>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)

	~~[[Category:GOOP]]~~

	[[Category:GOOP]]		[[Category:GOOP]]