A QControl is an object-oriented alternative to using an XControl. 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
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 Programing
- 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.)
Comments
Post a Comment