Skip to main content

What is a QControl?

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

Popular posts from this blog

RichTextBox QControl

The  RichTextBox QControl Code  can be found here: RichTextBox QControl.zip The  QControl Toolkit  is required to use this and can be found  here : The QControl Toolkit on LabVIEW Tools Network Overview For this QControl I wanted a completely LabVIEW 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. This QControl contains two classes.  First, the RichTextBox Class inherits from the String Class and adds the ability read/write  through a property nodes: the tagged string  whether to view the tagged string value or the formatted value in the String Control Second, the RichTextBoxWithToolbar adds the Toolbar Facade and the Event Handler to handle all of the formatting events.  The font list is populated based on the OS and there is a case structure for that in
2 comments
Read more

StatusHistory QControl

This is the second in a series of posts on some of the extended QControls that come already installed with the QControl Toolkit.  There is no separate download for these.  To get them just install the QControl Tool Kit available here: The QControl Toolkit on LabVIEW Tools Network After installed, examples can be found in the NI Example Finder and the Controls (Facades) and the methods can be found in the Addons-->QControl Palettes. Overview The StatusHistory QControl is a history stack which will display the last number of strings written to it.  The history size, colors, and direction are settable properties. The StatusHistory QControl is what I used in the New QControl Wizard to get the cool vanishing text effect.  There is an example in the Example Finder (shown below) when the toolkit is installed. Pictured here and in the New QControl Wizard I set the older strings in the stack to fade to the same color as my background to make the disappearing effect.  Ho
Post a Comment
Read more

BreadcrumbNavigator QControl

The  BreadcrumbNavigator QControl Code  can be found here: BreadcrumbNavigator QControl.zip The  QControl Toolkit  is required to use this and can be found  here : The QControl Toolkit on LabVIEW Tools Network Overview For this QControl I had a need to mimic breadcrumb navigation similar to that found in a webpage.  This QControl modifies a string control to display the elements.  For those that don't know what breadcrumb navigation is, it is the history trail of where you have been (like Hansel and Gretel leaving a breadcrumb trail).   It allows the user to return to any given point. This QControl allows a developer to add items, change the delimiter (should be done at the start but default is the colon), and fires a user event when clicked so the user can handle the actual navigation. To add an element, don't write to the strings value; instead use the AddString Property.  The items will appear underlined just like a link on mouseover.  On mouse click a us
Post a Comment
Read more