QControl - Revision history

Dwb: grammar

2022-11-16T14:55:39Z

grammar

Q: /* External Links */

2020-12-01T14:03:57Z

External Links

← Older revision		Revision as of 14:03, 1 December 2020
Line 65:		Line 65:

	== External Links ==		== External Links ==
			'''Get the QControl Toolkit'''
			*[http://sine.ni.com/nips/cds/view/p/lang/en/nid/214228 From the LabVIEW Tools Network]
			*[https://www.vipm.io/package/qsi_qcontrol_toolkit/ From VIPM.io]
			'''Other Resources for Learning about QControls'''
			*[https://forums.ni.com/t5/QControl-Enthusiasts/gh-p/5383?profile.language=en QControl Enthusiasts - NI Community Page]
	*[https://education.ni.com/center-of-excellence/resources/1185/ui-extensible-mod-uis-extend-the-vi-server-with-object-oriented-techniques UI: Extensible & Mod UIs: Extend the VI Server With Object-Oriented Techniques] - by Quentin Alldredge, Q Software Innovations, LLC		*[https://education.ni.com/center-of-excellence/resources/1185/ui-extensible-mod-uis-extend-the-vi-server-with-object-oriented-techniques UI: Extensible & Mod UIs: Extend the VI Server With Object-Oriented Techniques] - by Quentin Alldredge, Q Software Innovations, LLC
	*[~~http~~://~~sine~~.ni.~~com~~/~~nips~~/~~cds~~/~~view~~/p/~~lang~~/en/~~nid~~/~~214228~~ QControl Toolkit on the ~~LabVIEW Tools Network~~]		*[https://www.qsi.dev/2020/06/03/QControl-Toolkit-Design-Decisions-1/ QControl Design Decisions #1 - Article from Q Software Innovations Website] ([https://www.qsi.dev www.qsi.dev])
			*[https://www.qsi.dev/2020/06/03/QControl-Toolkit-Design-Decisions-2/ QControl Design Decisions #2 - Article from Q Software Innovations Website] ([https://www.qsi.dev www.qsi.dev])
			*[https://www.vipm.io/package/qsi_qcontrol_toolkit/ Also see Posts on the QControl Toolkit VIPM.io Page]

	[[Category:QControl]]		[[Category:QControl]]
	[[Category:XControl]]		[[Category:XControl]]
	[[Category:User interface]]		[[Category:User interface]]

JLMommy: Fixed NI link (they changed from learn.ni to education.ni)

2020-11-14T19:41:02Z

Fixed NI link (they changed from learn.ni to education.ni)

← Older revision		Revision as of 19:41, 14 November 2020
Line 65:		Line 65:

	== External Links ==		== External Links ==
	*[https://~~learn~~.ni.com/center-of-excellence/resources/1185/ui-extensible-mod-uis-extend-the-vi-server-with-object-oriented-techniques UI: Extensible & Mod UIs: Extend the VI Server With Object-Oriented Techniques] - by Quentin Alldredge, Q Software Innovations, LLC		*[https://education.ni.com/center-of-excellence/resources/1185/ui-extensible-mod-uis-extend-the-vi-server-with-object-oriented-techniques UI: Extensible & Mod UIs: Extend the VI Server With Object-Oriented Techniques] - by Quentin Alldredge, Q Software Innovations, LLC
	*[http://sine.ni.com/nips/cds/view/p/lang/en/nid/214228 QControl Toolkit on the LabVIEW Tools Network]		*[http://sine.ni.com/nips/cds/view/p/lang/en/nid/214228 QControl Toolkit on the LabVIEW Tools Network]

Q: /* Why use a QControl instead of an XControl? */

2020-06-09T16:00:42Z

Why use a QControl instead of an XControl?

← Older revision		Revision as of 16:00, 9 June 2020
Line 30:		Line 30:
	* Slightly more complicated when programming a custom control with more than one control in it		* Slightly more complicated when programming a custom control with more than one control in it

	== Why use a QControl instead of an [[XControl]]? ==		== Why use a QControl instead of an XControl? ==
	If the Tradeoffs above didn’t help here is a more detailed explanation. [[XControl~~\|XControls~~]] have two main problems with their implementation that boil down to when an [[XControl]] is running.		If the Tradeoffs above didn’t help here is a more detailed explanation. [[XControl]]s have two main problems with their implementation that boil down to when an [[XControl]] is running.

	First, the nature of an [[XControl]] is that it is always running when it’s owning VI is in memory but only reacts during the user’s interaction with it. An [[XControl]] starts and its [[XControl:Abilities:Init_Ability_VI\|Init Ability]] executes when the [[XControl]] is placed on the Front Panel of a VI that is not in a Library or Class or when said VI opens and is loaded into memory. The [[XControl]] then closes and its [[XControl:Abilities:Uninit_Ability_VI\|Uninit Ability]] (if it has one) executes when that VI leaves memory or when the [[XControl]] is deleted from the VI.		First, the nature of an [[XControl]] is that it is always running when it’s owning VI is in memory but only reacts during the user’s interaction with it. An [[XControl]] starts and its [[XControl:Abilities:Init_Ability_VI\|Init Ability]] executes when the [[XControl]] is placed on the Front Panel of a VI that is not in a Library or Class or when said VI opens and is loaded into memory. The [[XControl]] then closes and its [[XControl:Abilities:Uninit_Ability_VI\|Uninit Ability]] (if it has one) executes when that VI leaves memory or when the [[XControl]] is deleted from the VI.

Q: /* Tradeoffs of a QControl vs an XControl */

2020-06-09T16:00:14Z

Tradeoffs of a QControl vs an XControl

← Older revision		Revision as of 16:00, 9 June 2020
Line 8:		Line 8:
	* Part of the QControl Class Hierarchy which mimics the [[VI Server]] Class Hierarchy		* Part of the QControl Class Hierarchy which mimics the [[VI Server]] Class Hierarchy
	__TOC__		__TOC__
	== Tradeoffs of a QControl vs an [[XControl]] ==		== Tradeoffs of a QControl vs an XControl ==
	There are tradeoffs to using a QControl versus using a regular [[XControl]].		There are tradeoffs to using a QControl versus using a regular [[XControl]].

Q: /* Tradeoffs of a QControl vs an XControl */ Fixed links

2020-06-09T15:59:49Z

Tradeoffs of a QControl vs an XControl: Fixed links

← Older revision		Revision as of 15:59, 9 June 2020
Line 20:		Line 20:
	* Decoupling the UI Look (Skin) from the UI Logic		* Decoupling the UI Look (Skin) from the UI Logic
	* Being easier to use with [[Object oriented software\|Object Oriented Programming]]		* Being easier to use with [[Object oriented software\|Object Oriented Programming]]
	* Being easier to use with [[LabVIEW Libraries ~~(LVLibs)~~]] and [[Packed Project Libraries (PPLs)]]		* Being easier to use with [[LabVIEW Project Library\|LabVIEW Project Libraries]] and [[Packed Project Library\|Packed Project Libraries (PPLs)]]
	* Inheriting from current LabVIEW controls to give access to their properties which allows the LabVIEW controls to be extensible		* Inheriting from current LabVIEW controls to give access to their properties which allows the LabVIEW controls to be extensible
	* Being more stable		* Being more stable

Q: Added links

2018-12-01T04:33:42Z

Added links

← Older revision		Revision as of 04:33, 1 December 2018
Line 1:		Line 1:
	[[File:QControl Class Green.png\|258x258px\|frameless\|right]]		[[File:QControl Class Green.png\|258x258px\|frameless\|right]]
	A '''QControl''' is an object-oriented alternative to using an XControl created by [https://www.linkedin.com/in/quentin-q-alldredge/ Quentin "Q" Alldredge] from [http://www.qsoftwareinnovations.com/ Q Software Innovations, LLC]. It allows a developer to create useful, highly customized User Interface (UI) components in LabVIEW of which the behavior is extensible and reusable.		A '''QControl''' is an object-oriented alternative to using an [[XControl]] created by [https://www.linkedin.com/in/quentin-q-alldredge/ Quentin "Q" Alldredge] from [http://www.qsoftwareinnovations.com/ Q Software Innovations, LLC]. It allows a developer to create useful, highly customized User Interface (UI) components in LabVIEW of which the behavior is extensible and reusable.

	It is:		It is:
Line 6:		Line 6:
	* A class that can be reused to recreate the UI Logic wherever required		* A class that can be reused to recreate the UI Logic wherever required
	* Could have an asynchronously called Event Hander that handles UI Logic		* Could have an asynchronously called Event Hander that handles UI Logic
	* Part of the QControl Class Hierarchy which mimics the VI Server Class Hierarchy		* Part of the QControl Class Hierarchy which mimics the [[VI Server]] Class Hierarchy
	__TOC__		__TOC__
	== Tradeoffs of a QControl vs an XControl ==		== Tradeoffs of a QControl vs an [[XControl]] ==
	There are tradeoffs to using a QControl versus using a regular XControl.		There are tradeoffs to using a QControl versus using a regular [[XControl]].

	A QControl has the same benefits of an XControl by:		A QControl has the same benefits of an [[XControl]] by:
	* Encapsulating UI Logic Code		* Encapsulating UI Logic Code
	* Maintaining the same functionality when used in multiple instances		* Maintaining the same functionality when used in multiple instances
	* Allowing for complicated UI code to be abstracted from other developers		* Allowing for complicated UI code to be abstracted from other developers
	* Allowing for custom properties accessible through Property Nodes		* Allowing for custom properties accessible through Property Nodes
	It is better than an XControl by:		It is better than an [[XControl]] by:
	* Not requiring separate Edit Time behavior to be developed		* Not requiring separate Edit Time behavior to be developed
	* Decoupling the UI Look (Skin) from the UI Logic		* Decoupling the UI Look (Skin) from the UI Logic
	* Being easier to use with Object Oriented Programming		* Being easier to use with [[Object oriented software\|Object Oriented Programming]]
	* Being easier to use with LabVIEW Libraries (LVLibs) and Packed Project Libraries (PPLs)		* Being easier to use with [[LabVIEW Libraries (LVLibs)]] and [[Packed Project Libraries (PPLs)]]
	* Inheriting from current LabVIEW controls to give access to their properties which allows the LabVIEW controls to be extensible		* Inheriting from current LabVIEW controls to give access to their properties which allows the LabVIEW controls to be extensible
	* Being more stable		* Being more stable
Line 30:		Line 30:
	* Slightly more complicated when programming a custom control with more than one control in it		* Slightly more complicated when programming a custom control with more than one control in it

	== Why use a QControl instead of an XControl? ==		== Why use a QControl instead of an [[XControl]]? ==
	If the Tradeoffs above didn’t help here is a more detailed explanation. XControls have two main problems with their implementation that boil down to when an XControl is running.		If the Tradeoffs above didn’t help here is a more detailed explanation. [[XControl\|XControls]] have two main problems with their implementation that boil down to when an [[XControl]] is running.

	First, the nature of an XControl is that it is always running when it’s owning VI is in memory but only reacts during the user’s interaction with it. An XControl starts and its Init Ability executes when the XControl is placed on the Front Panel of a VI that is not in a Library or Class or when said VI opens and is loaded into memory. The XControl then closes and its Uninit Ability (if it has one) executes when that VI leaves memory or when the XControl is deleted from the VI.		First, the nature of an [[XControl]] is that it is always running when it’s owning VI is in memory but only reacts during the user’s interaction with it. An [[XControl]] starts and its [[XControl:Abilities:Init_Ability_VI\|Init Ability]] executes when the [[XControl]] is placed on the Front Panel of a VI that is not in a Library or Class or when said VI opens and is loaded into memory. The [[XControl]] then closes and its [[XControl:Abilities:Uninit_Ability_VI\|Uninit Ability]] (if it has one) executes when that VI leaves memory or when the [[XControl]] is deleted from the VI.

	This becomes more complicated if the owning VI is in a Library or Class. All VIs in a Libraries or Classes are loaded into memory when the Library or Class is loaded into memory. This means that the Init and Uninit Abilities run at the load and unload of the Library or Class and not during the load and close of the owning VI. Loading of Libraries and Classes, unless called dynamically, are when the Project loads and closes. XControls become even more unstable if it is compiled and used from Packed Project Libraries (PPLs) and/or is used when a LabVIEW Class Object is its data type. As such XControls are also not recommended for use with the Actor Framework.		This becomes more complicated if the owning VI is in a Library or Class. All VIs in a Libraries or Classes are loaded into memory when the Library or Class is loaded into memory. This means that the [[XControl:Abilities:Init_Ability_VI\|Init]] and [[XControl:Abilities:Uninit_Ability_VI\|Uninit]] Abilities run at the load and unload of the Library or Class and not during the load and close of the owning VI. Loading of Libraries and Classes, unless called dynamically, are when the Project loads and closes. XControls become even more unstable if it is compiled and used from Packed Project Libraries (PPLs) and/or is used when a LabVIEW Class Object is its data type. As such XControls are also not recommended for use with the Actor Framework.

	Second, XControls are difficult to handle during the edit time of the owning VI. Because they are always running, interaction during edit time has to be programmed into the XControl (an XControl has a flag that tells it if the owning VI is in Run Mode or Edit Mode). This causes a lot more coding necessary just for the ease of the developer that will never be seen by the end user. Also any properties and method to the control(s) on the Façade have to be recreated as Property and Method Abilities of the XControl.		Second, [[XControl\|XControls]] are difficult to handle during the edit time of the owning VI. Because they are always running, interaction during edit time has to be programmed into the [[XControl]] (an [[XControl]] has a flag that tells it if the owning VI is in Run Mode or Edit Mode). This causes a lot more coding necessary just for the ease of the developer that will never be seen by the end user. Also any properties and method to the control(s) on the Façade have to be recreated as Property and Method Abilities of the [[XControl]].

	QControls on the other hand do not execute until the owning VI executes. All edit time behavior is conserved. There is no limitations for use in VIs that are part of other Libraries or Classes including PPLs and the Actor Framework.		QControls on the other hand do not execute until the owning VI executes. All edit time behavior is conserved. There is no limitations for use in VIs that are part of other Libraries or Classes including PPLs and the Actor Framework.

	Also, while using the QControl Toolkit, all properties of the control it is based on, when consisting of single controls, are passed through by nature of inheritance in the QControl Class Hierarchy. (QControls that have more than one control in a cluster can still have the properties and methods pass through but they would have to be created just as they would have to be created in an XControl.)		Also, while using the QControl Toolkit, all properties of the control it is based on, when consisting of single controls, are passed through by nature of inheritance in the QControl Class Hierarchy. (QControls that have more than one control in a cluster can still have the properties and methods pass through but they would have to be created just as they would have to be created in an [[XControl]].)

	== Extended QControls ==		== Extended QControls ==

Q: Added Extended QControls

2018-12-01T01:35:29Z

Added Extended QControls

← Older revision		Revision as of 01:35, 1 December 2018
Line 42:		Line 42:

	Also, while using the QControl Toolkit, all properties of the control it is based on, when consisting of single controls, are passed through by nature of inheritance in the QControl Class Hierarchy. (QControls that have more than one control in a cluster can still have the properties and methods pass through but they would have to be created just as they would have to be created in an XControl.)		Also, while using the QControl Toolkit, all properties of the control it is based on, when consisting of single controls, are passed through by nature of inheritance in the QControl Class Hierarchy. (QControls that have more than one control in a cluster can still have the properties and methods pass through but they would have to be created just as they would have to be created in an XControl.)

			== Extended QControls ==
			'''Extended QControls''' refers to QControls that have been created and shared to the community. These are available to download from the links on their respective pages.

			=== [[AnimationRing QControl]] ===
			The '''AnimationRing QControl''' s a QControl that inherits from and extends the Ring control, specifically a Picture Ring. It cycles the value of the ring which contains a frame of the animation. The frame rate is settable by property.

			=== [[BreadcrumbNavigator QControl]] ===
			The '''BreadcrumbNavigator QControl''' is a QControl that inherits from and extends the String control. It acts like a list of HTML-Like links to help provide navigation in an application. Add items through an included property. Clear all items through an included method. When an item is clicked on, any thing after it is removed from the list and the clicked item is returned.

			=== [[Calendar QControl]] ===
			The '''Calendar QControl''' is a QControl that inherits from and extends the Cluster control. It implements multiple buttons, lists, etc. to implement a Calandar.

			=== [[DataGrid QControl]] ===
			The '''DataGrid QControl''' is a QControl that inherits and extends the Multicolumn Listbox control. It functions as a completely LabVIEW implemented Data Grid where the column data type is defined at edit time by the developer. The user is then constrained by that data type when inputting data into the Multicolumn Listbox.

			=== [[RichTextBox QControl]] ===
			The '''RichTextBox QControl''' is a QControl that inherits and extends the String control. It functions as a completely LabVIEW implemented Rich Text Box. Under the hood it uses an HTML-like tagged string to define the formatting. Then there are two main methods: one that converts the tagged string to the formatted string and one that converts the formatted string to the tagged string.

			=== [[SpellcheckString QControl]] ===
			The '''SpellcheckString''' is a QControl that inherits from and extends the String control. It implements run-time spell checking inside of a String control. It highlights misspelled words by underlining and changing the color to red. Right-clicking on a misspelled word opens a menu with the suggestions and an option to add word to dictionary.

	== External Links ==		== External Links ==

Q: Q moved page QControls to QControl: Fixing Title

2018-12-01T01:23:54Z

Q moved page QControls to QControl: Fixing Title

← Older revision	Revision as of 01:23, 1 December 2018
(No difference)

Q: New page for QControls

2018-12-01T01:23:27Z

New page for QControls

New page

[[File:QControl Class Green.png|258x258px|frameless|right]]
A '''QControl''' is an object-oriented alternative to using an XControl created by [https://www.linkedin.com/in/quentin-q-alldredge/ Quentin "Q" Alldredge] from [http://www.qsoftwareinnovations.com/ Q Software Innovations, LLC]. It allows a developer to create useful, highly customized User Interface (UI) components in LabVIEW of which the behavior is extensible and reusable.

It is:
* A LabVIEW Object-Oriented Class with a Control Reference as part of its Private Data where all manipulation of the Control should be done through Properties and Methods of its Class
* A class that can be reused to recreate the UI Logic wherever required
* Could have an asynchronously called Event Hander that handles UI Logic
* Part of the QControl Class Hierarchy which mimics the VI Server Class Hierarchy
__TOC__
== Tradeoffs of a QControl vs an XControl ==
There are tradeoffs to using a QControl versus using a regular XControl.

A QControl has the same benefits of an XControl by:
* Encapsulating UI Logic Code
* Maintaining the same functionality when used in multiple instances
* Allowing for complicated UI code to be abstracted from other developers
* Allowing for custom properties accessible through Property Nodes
It is better than an XControl by:
* Not requiring separate Edit Time behavior to be developed
* Decoupling the UI Look (Skin) from the UI Logic
* Being easier to use with Object Oriented Programming
* Being easier to use with LabVIEW Libraries (LVLibs) and Packed Project Libraries (PPLs)
* Inheriting from current LabVIEW controls to give access to their properties which allows the LabVIEW controls to be extensible
* Being more stable
However, it does have the drawbacks of:
* Not having customizable Edit Time behavior
* Not being able to define Data Type
* Not being able to enforce the use of the defined façade
* Slightly more complicated programming in usage (does not exist as just a terminal on the block diagram)
* Slightly more complicated when programming a custom control with more than one control in it

== Why use a QControl instead of an XControl? ==
If the Tradeoffs above didn’t help here is a more detailed explanation. XControls have two main problems with their implementation that boil down to when an XControl is running.

First, the nature of an XControl is that it is always running when it’s owning VI is in memory but only reacts during the user’s interaction with it. An XControl starts and its Init Ability executes when the XControl is placed on the Front Panel of a VI that is not in a Library or Class or when said VI opens and is loaded into memory. The XControl then closes and its Uninit Ability (if it has one) executes when that VI leaves memory or when the XControl is deleted from the VI.

This becomes more complicated if the owning VI is in a Library or Class. All VIs in a Libraries or Classes are loaded into memory when the Library or Class is loaded into memory. This means that the Init and Uninit Abilities run at the load and unload of the Library or Class and not during the load and close of the owning VI. Loading of Libraries and Classes, unless called dynamically, are when the Project loads and closes. XControls become even more unstable if it is compiled and used from Packed Project Libraries (PPLs) and/or is used when a LabVIEW Class Object is its data type. As such XControls are also not recommended for use with the Actor Framework.

Second, XControls are difficult to handle during the edit time of the owning VI. Because they are always running, interaction during edit time has to be programmed into the XControl (an XControl has a flag that tells it if the owning VI is in Run Mode or Edit Mode). This causes a lot more coding necessary just for the ease of the developer that will never be seen by the end user. Also any properties and method to the control(s) on the Façade have to be recreated as Property and Method Abilities of the XControl.

QControls on the other hand do not execute until the owning VI executes. All edit time behavior is conserved. There is no limitations for use in VIs that are part of other Libraries or Classes including PPLs and the Actor Framework.

Also, while using the QControl Toolkit, all properties of the control it is based on, when consisting of single controls, are passed through by nature of inheritance in the QControl Class Hierarchy. (QControls that have more than one control in a cluster can still have the properties and methods pass through but they would have to be created just as they would have to be created in an XControl.)

== External Links ==
*[https://learn.ni.com/center-of-excellence/resources/1185/ui-extensible-mod-uis-extend-the-vi-server-with-object-oriented-techniques UI: Extensible & Mod UIs: Extend the VI Server With Object-Oriented Techniques] - by Quentin Alldredge, Q Software Innovations, LLC
*[http://sine.ni.com/nips/cds/view/p/lang/en/nid/214228 QControl Toolkit on the LabVIEW Tools Network]

[[Category:QControl]]
[[Category:XControl]]
[[Category:User interface]]

← Older revision		Revision as of 14:55, 16 November 2022
Line 35:		Line 35:
	First, the nature of an [[XControl]] is that it is always running when it’s owning VI is in memory but only reacts during the user’s interaction with it. An [[XControl]] starts and its [[XControl:Abilities:Init_Ability_VI\|Init Ability]] executes when the [[XControl]] is placed on the Front Panel of a VI that is not in a Library or Class or when said VI opens and is loaded into memory. The [[XControl]] then closes and its [[XControl:Abilities:Uninit_Ability_VI\|Uninit Ability]] (if it has one) executes when that VI leaves memory or when the [[XControl]] is deleted from the VI.		First, the nature of an [[XControl]] is that it is always running when it’s owning VI is in memory but only reacts during the user’s interaction with it. An [[XControl]] starts and its [[XControl:Abilities:Init_Ability_VI\|Init Ability]] executes when the [[XControl]] is placed on the Front Panel of a VI that is not in a Library or Class or when said VI opens and is loaded into memory. The [[XControl]] then closes and its [[XControl:Abilities:Uninit_Ability_VI\|Uninit Ability]] (if it has one) executes when that VI leaves memory or when the [[XControl]] is deleted from the VI.

	This becomes more complicated if the owning VI is in a Library or Class. All VIs in a Libraries or Classes are loaded into memory when the Library or Class is loaded into memory. This means that the [[XControl:Abilities:Init_Ability_VI\|Init]] and [[XControl:Abilities:Uninit_Ability_VI\|Uninit]] Abilities run at the load and unload of the Library or Class and not during the load and close of the owning VI. Loading of Libraries and Classes, unless called dynamically, are when the Project loads and closes. XControls become even more unstable if it is compiled and used from Packed Project Libraries (PPLs) and/or is used when a LabVIEW Class Object is its data type. As such XControls are also not recommended for use with the Actor Framework.		This becomes more complicated if the owning VI is in a Library or Class. All VIs in Libraries or Classes are loaded into memory when the Library or Class is loaded into memory. This means that the [[XControl:Abilities:Init_Ability_VI\|Init]] and [[XControl:Abilities:Uninit_Ability_VI\|Uninit]] Abilities run at the load and unload of the Library or Class and not during the load and close of the owning VI. Loading of Libraries and Classes, unless called dynamically, are when the Project loads and closes. XControls become even more unstable if it is compiled and used from Packed Project Libraries (PPLs) and/or is used when a LabVIEW Class Object is its data type. As such XControls are also not recommended for use with the Actor Framework.

	Second, [[XControl\|XControls]] are difficult to handle during the edit time of the owning VI. Because they are always running, interaction during edit time has to be programmed into the [[XControl]] (an [[XControl]] has a flag that tells it if the owning VI is in Run Mode or Edit Mode). This causes a lot more coding necessary just for the ease of the developer that will never be seen by the end user. Also any properties and method to the control(s) on the Façade have to be recreated as Property and Method Abilities of the [[XControl]].		Second, [[XControl\|XControls]] are difficult to handle during the edit time of the owning VI. Because they are always running, interaction during edit time has to be programmed into the [[XControl]] (an [[XControl]] has a flag that tells it if the owning VI is in Run Mode or Edit Mode). This causes a lot more coding necessary just for the ease of the developer that will never be seen by the end user. Also any properties and method to the control(s) on the Façade have to be recreated as Property and Method Abilities of the [[XControl]].
Line 50:		Line 50:

	=== [[BreadcrumbNavigator QControl]] ===		=== [[BreadcrumbNavigator QControl]] ===
	The '''BreadcrumbNavigator QControl''' is a QControl that inherits from and extends the String control. It acts like a list of HTML-~~Like~~ links to help provide navigation in an application. Add items through an included property. Clear all items through an included method. When an item is clicked on, ~~any thing~~ after it is removed from the list and the clicked item is returned.		The '''BreadcrumbNavigator QControl''' is a QControl that inherits from and extends the String control. It acts like a list of HTML-like links to help provide navigation in an application. Add items through an included property. Clear all items through an included method. When an item is clicked on, anything after it is removed from the list and the clicked item is returned.

	=== [[Calendar QControl]] ===		=== [[Calendar QControl]] ===
	The '''Calendar QControl''' is a QControl that inherits from and extends the Cluster control. It implements multiple buttons, lists, etc. to implement a ~~Calandar~~.		The '''Calendar QControl''' is a QControl that inherits from and extends the Cluster control. It implements multiple buttons, lists, etc. to implement a Calendar.

	=== [[DataGrid QControl]] ===		=== [[DataGrid QControl]] ===
	The '''DataGrid QControl''' is a QControl that inherits and extends the Multicolumn Listbox control. It functions as a completely LabVIEW implemented Data Grid where the column data type is defined at edit time by the developer. The user is then constrained by that data type when inputting data into the Multicolumn Listbox.		The '''DataGrid QControl''' is a QControl that inherits and extends the Multicolumn Listbox control. It functions as a completely LabVIEW-implemented Data Grid where the column data type is defined at edit time by the developer. The user is then constrained by that data type when inputting data into the Multicolumn Listbox.

	=== [[RichTextBox QControl]] ===		=== [[RichTextBox QControl]] ===
	The '''RichTextBox QControl''' is a QControl that inherits and extends the String control. It functions as a completely LabVIEW implemented Rich Text Box. Under the hood it uses an HTML-like tagged string to define the formatting~~. Then there~~ are two main methods: one that converts the tagged string to the formatted string and one that converts the formatted string to the tagged string.		The '''RichTextBox QControl''' is a QControl that inherits and extends the String control. It functions as a completely LabVIEW-implemented Rich Text Box. Under the hood it uses an HTML-like tagged string to define the formatting; there are two main methods: one that converts the tagged string to the formatted string and one that converts the formatted string to the tagged string.

	=== [[SpellcheckString QControl]] ===		=== [[SpellcheckString QControl]] ===