Control References - Revision history

Michael_Aivaliotis at 08:48, 8 October 2007

2007-10-08T08:48:31Z

← Older revision		Revision as of 08:48, 8 October 2007
Line 117:		Line 117:
	[[Image:Controlsproperty.png\|center\|thumb\|600px\|Example of using the Controls[] property]]		[[Image:Controlsproperty.png\|center\|thumb\|600px\|Example of using the Controls[] property]]

	[[~~Category~~:~~User Interface~~]]		[[category:user interface]]

Michael_Aivaliotis at 08:29, 8 October 2007

2007-10-08T08:29:06Z

← Older revision		Revision as of 08:29, 8 October 2007
Line 1:		Line 1:
	~~__NOTOC__~~		{{TOCnestright}}
	{~~\| align="right" border="0"~~
	~~\|__TOC__~~
	\|-
	\|}
	== Background ==		== Background ==
	Until the release of LabVIEW 6i, there was no way of encapsulating the user interface portion of code when doing user interface programming. In previous versions of LabVIEW, user interface programming was done by using attribute nodes. Attribute nodes have implicit links to front panel controls and must reside in the block diagram of the same VI as their associated control. Therefore, if you have a VI that manipulates front panel controls extensively, your block diagram will end up with dozens of attribute nodes taking up a lot of space on the block diagram, making the block diagram cluttered and difficult to read. One of the keys to creating good LabVIEW applications is using the hierarchical nature of the VI. Creating modular programs using subVIs makes applications easy to debug, understand, and maintain. Until the release of LabVIEW 6i, there was no way to apply this same modular approach for user interface programming. The introduction of control references alleviates this problem.		Until the release of LabVIEW 6i, there was no way of encapsulating the user interface portion of code when doing user interface programming. In previous versions of LabVIEW, user interface programming was done by using attribute nodes. Attribute nodes have implicit links to front panel controls and must reside in the block diagram of the same VI as their associated control. Therefore, if you have a VI that manipulates front panel controls extensively, your block diagram will end up with dozens of attribute nodes taking up a lot of space on the block diagram, making the block diagram cluttered and difficult to read. One of the keys to creating good LabVIEW applications is using the hierarchical nature of the VI. Creating modular programs using subVIs makes applications easy to debug, understand, and maintain. Until the release of LabVIEW 6i, there was no way to apply this same modular approach for user interface programming. The introduction of control references alleviates this problem.

MichaelAivaliotis: Improved positioning of images.

2007-05-04T04:49:29Z

Improved positioning of images.

Show changes

MichaelAivaliotis: /* “Front Panel.Controls []” Property */

2007-04-15T10:52:40Z

“Front Panel.Controls []” Property

← Older revision		Revision as of 10:52, 15 April 2007
Line 111:		Line 111:

	==“Front Panel.Controls []” Property==		==“Front Panel.Controls []” Property==
			*Allows manipulation of controls and data on any VI panel
			*Control references must be closed
			[[Image:Controlsproperty.png\|none\|thumb\|300px\|Example of using the Controls[] property]]

	[[Category:User Interface]]		[[Category:User Interface]]

MichaelAivaliotis: /* Class Hierarchy Shortcut Menu */

2007-04-15T10:47:16Z

Class Hierarchy Shortcut Menu

← Older revision		Revision as of 10:47, 15 April 2007
Line 42:		Line 42:

	==Class Hierarchy Shortcut Menu==		==Class Hierarchy Shortcut Menu==
	[[Image:Classhierarchyshortcutmenu.png\|right\|thumb\|~~300px~~\|Shortcut menu showing control class hierarchy‎]]		[[Image:Classhierarchyshortcutmenu.png\|right\|thumb\|200px\|Shortcut menu showing control class hierarchy‎]]
	Selecting a more generic class for a control refnum will allow it to accept a wider range of objects. The top entry in each of the sub-menus above includes all of the entries beneath it. For example, selecting GObject will make that control refnum able to accept references from decorations, scales, controls, and panels. This could be a beneficial practice if we want to perform the same, general operation on multiple objects. All controls have the attribute "Visible". Therefore, if we wanted to be able to selectively turn on and off the visibility of our front panel controls, we could have one subVI to do this. This is because we would set the refnum control in that subVI to be of type "Control", so that it would accept all types of controls that we may have.		Selecting a more generic class for a control refnum will allow it to accept a wider range of objects. The top entry in each of the sub-menus above includes all of the entries beneath it. For example, selecting GObject will make that control refnum able to accept references from decorations, scales, controls, and panels. This could be a beneficial practice if we want to perform the same, general operation on multiple objects. All controls have the attribute "Visible". Therefore, if we wanted to be able to selectively turn on and off the visibility of our front panel controls, we could have one subVI to do this. This is because we would set the refnum control in that subVI to be of type "Control", so that it would accept all types of controls that we may have.

MichaelAivaliotis: /* Control */

2007-04-15T10:45:45Z

Control

← Older revision		Revision as of 10:45, 15 April 2007
Line 27:		Line 27:

	===Control===		===Control===
	[[Image:Selectclass.png\|right\|thumb\|~~300px~~\|caption]]		[[Image:Selectclass.png\|right\|thumb\|100px\|caption]]
	*Use it to pass references into subVIs		*Use it to pass references into subVIs
	:Its default value is always invalid		:Its default value is always invalid

MichaelAivaliotis: /* Control */

2007-04-15T10:45:00Z

Control

← Older revision		Revision as of 10:45, 15 April 2007
Line 27:		Line 27:

	===Control===		===Control===
			[[Image:Selectclass.png\|right\|thumb\|300px\|caption]]
	*Use it to pass references into subVIs		*Use it to pass references into subVIs
	:Its default value is always invalid		:Its default value is always invalid

MichaelAivaliotis: /* Constant */

2007-04-15T10:31:18Z

Constant

← Older revision		Revision as of 10:31, 15 April 2007
Line 18:		Line 18:

	===Constant===		===Constant===
			*Right-click a control or terminal and select Create»Reference
			*Creates a control reference constant
			:Its class is always strict
			:Its value is always the same
			:You do not have to close the reference. Multiple control reference constants for the same control return the same reference.
			:Always strictly typed
	To create a control reference constant for a control, right-click the control and select Create»Reference. A constant with a curved arrow appears on the block diagram. If you have multiple control reference constants for the same control, they all return the same reference. References returned from control reference constants do not need to be closed by the Close LabVIEW Object Reference function. A reference returned from a control reference constant is always strict.		To create a control reference constant for a control, right-click the control and select Create»Reference. A constant with a curved arrow appears on the block diagram. If you have multiple control reference constants for the same control, they all return the same reference. References returned from control reference constants do not need to be closed by the Close LabVIEW Object Reference function. A reference returned from a control reference constant is always strict.

MichaelAivaliotis: /* Control */

2007-04-15T10:29:02Z

Control

← Older revision		Revision as of 10:29, 15 April 2007
Line 21:		Line 21:

	===Control===		===Control===
			*Use it to pass references into subVIs
			:Its default value is always invalid
			*Located on the Controls»Refnum palette
			*Specify its class by right-clicking it or dragging a control onto it

	==Implicit vs. Explicit Linked==		==Implicit vs. Explicit Linked==

MichaelAivaliotis: Added images and more text.

2007-04-15T10:25:03Z

Added images and more text.

← Older revision		Revision as of 10:25, 15 April 2007
Line 14:		Line 14:

	==Basic Usage==		==Basic Usage==
			[[Image:Creating_control_reference_constant.png\|right\|thumb\|300px\|How to create a control reference constant]]
	There are two types of control references, constants and controls.		There are two types of control references, constants and controls.

	~~[[Image:Creating_control_reference_constant.png\|right\|thumb\|300px]]~~

	===Constant===		===Constant===
Line 24:		Line 23:

	==Implicit vs. Explicit Linked==		==Implicit vs. Explicit Linked==
			[[Image:Implicitexplicit.png\|right\|frame\|Difference between implicit and explicitly linked property nodes.]]
			*Property nodes are '''implicitly''' linked to the front panel control from which they are created
			*Property nodes are '''explicitly''' linked to the control they reference by connecting a control refnum wire
	Use a property node with an implicit refnum input to set or read a control's attributes in the block diagram of the same VI. The property node is implicitly linked to the front panel control from which you created the property node, in that the information pointing the node to its corresponding front panel control is contained implicitly within the node. An implicitly linked property node is drawn differently from the normal property node, as it does not have a refnum input and output. The referenced control's name will be shown in the property node's label.		Use a property node with an implicit refnum input to set or read a control's attributes in the block diagram of the same VI. The property node is implicitly linked to the front panel control from which you created the property node, in that the information pointing the node to its corresponding front panel control is contained implicitly within the node. An implicitly linked property node is drawn differently from the normal property node, as it does not have a refnum input and output. The referenced control's name will be shown in the property node's label.

Line 29:		Line 31:

	==Class Hierarchy Shortcut Menu==		==Class Hierarchy Shortcut Menu==
			[[Image:Classhierarchyshortcutmenu.png\|right\|thumb\|300px\|Shortcut menu showing control class hierarchy‎]]
	Selecting a more generic class for a control refnum will allow it to accept a wider range of objects. The top entry in each of the sub-menus above includes all of the entries beneath it. For example, selecting GObject will make that control refnum able to accept references from decorations, scales, controls, and panels. This could be a beneficial practice if we want to perform the same, general operation on multiple objects. All controls have the attribute "Visible". Therefore, if we wanted to be able to selectively turn on and off the visibility of our front panel controls, we could have one subVI to do this. This is because we would set the refnum control in that subVI to be of type "Control", so that it would accept all types of controls that we may have.		Selecting a more generic class for a control refnum will allow it to accept a wider range of objects. The top entry in each of the sub-menus above includes all of the entries beneath it. For example, selecting GObject will make that control refnum able to accept references from decorations, scales, controls, and panels. This could be a beneficial practice if we want to perform the same, general operation on multiple objects. All controls have the attribute "Visible". Therefore, if we wanted to be able to selectively turn on and off the visibility of our front panel controls, we could have one subVI to do this. This is because we would set the refnum control in that subVI to be of type "Control", so that it would accept all types of controls that we may have.

	==Property Shortcut menu – Inheritance==		==Property Shortcut menu – Inheritance==
			[[Image:Propertyshortcutmenuinheritance.png\|right\|thumb\|300px\|Demonstration of Inheritance in the properties of the various control sub classes.]]
	A class inherits properties and methods from its parent. For example, if you use the operating tool to click the Property Node configured for the Digital class, a shortcut menu appears listing all the properties that are available for the Digital class. The Digital class inherits from the Numeric class, which inherits from the Control class, which inherits from the GObject class, which inherits from the Generic class. In the property shortcut menu, properties are		A class inherits properties and methods from its parent. For example, if you use the operating tool to click the Property Node configured for the Digital class, a shortcut menu appears listing all the properties that are available for the Digital class. The Digital class inherits from the Numeric class, which inherits from the Control class, which inherits from the GObject class, which inherits from the Generic class. In the property shortcut menu, properties are
	organized according to this hierarchy.		organized according to this hierarchy.

	==Non-Strict (weak) and Strict Classes==		==Non-Strict (weak) and Strict Classes==
			*'''Non-strict''' classes must treat value generically
			:Data type of Value property is variant
			*'''Strict''' classes know exact data type of value
			*Some classes always have known type of value
			:Examples: String, Path, and so on

	Allowing the user to choose refnums to be weakly or strictly typed gives them more freedom in programming. A weakly typed refnum is one that does not contain information about the type of data that the refnum points to. Conversely, a strictly typed refnum does contain the data type for the object that it points to. You can change between weak and strict refnums by right clicking on the refnum (or its terminal in the block diagram) and selecting "Include Data Type" for strict and deselecting it for a weak typed refnum. A red star on the Control Reference Control designates that the refnum is strictly typed. There are different cases for when you may want to use a strict type refnum over a weak typed refnum and vice versa.		Allowing the user to choose refnums to be weakly or strictly typed gives them more freedom in programming. A weakly typed refnum is one that does not contain information about the type of data that the refnum points to. Conversely, a strictly typed refnum does contain the data type for the object that it points to. You can change between weak and strict refnums by right clicking on the refnum (or its terminal in the block diagram) and selecting "Include Data Type" for strict and deselecting it for a weak typed refnum. A red star on the Control Reference Control designates that the refnum is strictly typed. There are different cases for when you may want to use a strict type refnum over a weak typed refnum and vice versa.

			[[Image:Strictandnonstrictclasses.png\|left\|thumb\|300px\|Here we show the difference between strict and non-strict class typing.]]

	A control refnum terminal that is strictly typed can only accept control references that are strictly typed to a compatible type. For example, if a subVI expects a control refnum of type Slide(Int32), you can wire a control reference of type Slide(Int32), Slide(Int8), or Slide(DBL), but not Slide(Cluster of DBLs). Wiring in the Slide(Int8) or Slide(DBL) will result in type coercion (no error) and thus a coercion dot as these representations are being coerced to Int32. Wiring the Slide(Cluster of DBLs) will result in a type conflict (error) and thus a broken wire. This is because the Int8 and DBL are numerics like the Int32 and can thus be coerced to be of Int32 representation. The Cluster of DBLs however, is not a numeric, but a totally different data type. Therefore, a cluster being of different data type than the numeric will result in a type conflict if wired together. Strictly typed references are most beneficial when you know exactly what type of data you will be using.		A control refnum terminal that is strictly typed can only accept control references that are strictly typed to a compatible type. For example, if a subVI expects a control refnum of type Slide(Int32), you can wire a control reference of type Slide(Int32), Slide(Int8), or Slide(DBL), but not Slide(Cluster of DBLs). Wiring in the Slide(Int8) or Slide(DBL) will result in type coercion (no error) and thus a coercion dot as these representations are being coerced to Int32. Wiring the Slide(Cluster of DBLs) will result in a type conflict (error) and thus a broken wire. This is because the Int8 and DBL are numerics like the Int32 and can thus be coerced to be of Int32 representation. The Cluster of DBLs however, is not a numeric, but a totally different data type. Therefore, a cluster being of different data type than the numeric will result in a type conflict if wired together. Strictly typed references are most beneficial when you know exactly what type of data you will be using.
Line 43:		Line 55:

	==Using the “Value” Property==		==Using the “Value” Property==
			*Use it to set or read from anywhere
			*Every control can be a global variable
			*Slower than writing a terminal or local variable
			*Recommendation: use only when necessary

	The Control class has the Value property. You can use it to read and write a control value just like local variables. The Value property was created so that the value of a control can be updated at the same time when we change the		The Control class has the Value property. You can use it to read and write a control value just like local variables. The Value property was created so that the value of a control can be updated at the same time when we change the
	control attributes. In LabVIEW 6.0, writing to the Value property is much slower than writing to a local variable. Every time you write to the Value property, it updates the control, even if the value has not changed. (When you		control attributes. In LabVIEW 6.0, writing to the Value property is much slower than writing to a local variable. Every time you write to the Value property, it updates the control, even if the value has not changed. (When you
Line 49:		Line 66:

	==Using a “Reference” Property==		==Using a “Reference” Property==
			[[Image:Referenceproperty.png\|right\|thumb\|300px]]
			*Some properties return a reference to sub-objects
			:“Owner,” “Label,” “Caption,” and so on.
			*They are always read only
			*Property always allocates a new reference
			:You should close references explicitly
			:LabVIEW closes them when VI goes idle but they accumulate until then
			:Use Dotted notation instead, if possible

	There are some properties that return a reference to other objects. They include the Owner property of the Generic class, Label and Caption properties of the Control class, Controls, Decorations, and All Objects properties of the Panel class, Xscale, Yscale of the Graph/Chart class, Plot properties of the Chart class, and so on. These reference properties are read only. Reading a reference property creates a new reference each time, so the reference should be closed, especially in a loop.		There are some properties that return a reference to other objects. They include the Owner property of the Generic class, Label and Caption properties of the Control class, Controls, Decorations, and All Objects properties of the Panel class, Xscale, Yscale of the Graph/Chart class, Plot properties of the Chart class, and so on. These reference properties are read only. Reading a reference property creates a new reference each time, so the reference should be closed, especially in a loop.

	A reference property can be dotted in one Property Node. For example, you can have Label.Text property. It is equivalent to getting a reference to a control label and wiring that to another Property Node to get the label’s text.		A reference property can be dotted in one Property Node. For example, you can have Label.Text property. It is equivalent to getting a reference to a control label and wiring that to another Property Node to get the label’s text.
	The only difference is that with the dotted property, ~~we do~~ not allocate a reference to label.		The only difference is that with the dotted property, LabVIEW does not allocate a reference to label.

	==Type Casting to Another Class==		==Type Casting to Another Class==
			[[Image:Typecasttoanotherclass.png\|right\|thumb\|300px\|This shows how you can typecast to another class.]]
			*Downcast with the '''To More Specific Class''' function or upcast with the '''To More Generic Class''' function
			:Use it with properties that return generic types
			:Returns error at run time if the casting is not valid
			:Use it to find out the type dynamically.
			:use the Class Name property (very powerful)
	There are two functions in LabVIEW that manipulate references. To More Specific Class is used to downcast a reference, for example, from a Control reference to a Numeric reference. Because LabVIEW cannot tell this type of		There are two functions in LabVIEW that manipulate references. To More Specific Class is used to downcast a reference, for example, from a Control reference to a Numeric reference. Because LabVIEW cannot tell this type of
	casting is valid at compile time, this function returns an error if casting is invalid at run time. Use the To More Generic Class to type cast a reference to a more generic class, for example, from a Digital reference to Control reference. (This function does not return an error if casting is invalid, because the validity		casting is valid at compile time, this function returns an error if casting is invalid at run time. Use the To More Generic Class to type cast a reference to a more generic class, for example, from a Digital reference to Control reference. (This function does not return an error if casting is invalid, because the validity
Line 60:		Line 92:

	==Automatic Upcasting==		==Automatic Upcasting==
			[[Image:Autoupcasting.png\|right\|frame]]
			*LabVIEW does it when necessary
			*Casts up to closest common ancestor
			*Happens at Build Array, select structure output tunnels, subVI inputs, and so on.

	References are automatically upcast at Build Array and Case structure tunnels. For example, if you build an array of references from a reference to a numeric, a reference to a string, and a reference to a multicolumn listbox, the references are upcast to the Control class, which is the common parent class for all these classes.		References are automatically upcast at Build Array and Case structure tunnels. For example, if you build an array of references from a reference to a numeric, a reference to a string, and a reference to a multicolumn listbox, the references are upcast to the Control class, which is the common parent class for all these classes.