QControl Enthusiasts

cancel
Showing results for 
Search instead for 
Did you mean: 

Handling Multiple Controls in a QControl

Solved!
Go to solution

This may be more doable with the current feature set than I'm assuming, but I'll throw it out there. Forgive me if it's a noob request 😉

 

It would be neat to have multiple controls be part of the "QControl" as a whole. For an example, I have some 4-D data that needs to be plotted. The user can use one dropdown box to select the data on the X axis, another dropdown to select the data on the Y axis, and another dropdown to select a parameter to generate multiple lines for the given X and Y.

 

Say you're looking at motor torque/speed curves versus temperature and humidity controlled by an environmental chamber. You could use dropdowns to say "Torque on X, speed on Y, and do a different plot for each discrete temperature target (one at 20C, 40C, 60C, etc.) Then, via dropdown, you could select the parameter to be humidity- do one plot at 10%, 30%, 50%, etc.

 

The more general case is to be able to "mess with" multiple controls that each interact with each other. Right now I have to pick one control to get inheritable properties. I may could do a "nested" Qcontrol with Qcontrols inside Qcontrols, but I'd really prefer the Event handler to be able to process all of the UI events associated with each of the dropdowns AND the chart.

 

It's certainly doable right now by modifying the Initialize Control to include multiple references, but I only get the OOP stuff for the main control (the plot, in my case).

Message 1 of 4
(3,436 Views)
Solution
Accepted by BertMcMahan

Handling multiple controls in a QControl is one of the few places that can be more difficult than an XControl.  I have discovered three ways to do it so far and each have pros and cons.

 

 

  1. Inherit from the Cluster class, wrap all Controls in a Cluster, and pass the cluster reference to the Constructor method.
  2. Add all of the Control references as inputs into the Constructor method.
  3. Only have one control for inheritance and reference; all other controls are small, one control dialog boxes.

 

The first two involve getting the necessary control references into the Constructor method while the third deals with handling the extra controls through popups. 

 

 

Inherit from the Cluster class, wrap all Controls in a Cluster, and pass the cluster reference to the Constructor method.

 

The first way loses all of the inherited properties and methods for the individual controls due to inheriting from the Cluster class.  However, the tradeoff is that the new facade that is created as the cluster is easier to share and standardize.  All internal manipulation of the individual controls will have to be managed by getting the references to them through the cluster's "Controls[]" property.  An example of where I do this is in the Calendar QControl.

 

Add all of the Control references as inputs into the Constructor method.

 

The second way you have to chose the main control type you want to inherit from and pass that reference in as the main reference in the Constructor method, (in the case above, the plot control).  Then any other controls will have to be added as inputs (individually, as a cluster of references, or as an array of references).  The Constructor method will have to be further modified to add these other references to the Class Data.  Unlike an XControl where all properties and methods have to be manually programmed; you will have the benefit of still having the inherited properties and methods of the main class type chosen.  Only the properties or methods on the other controls will have to be manually programmed.  I do this in the RichTextBox QControl where I have the main control as a string and the secondary controls are a cluster of controls for the formatting toolbar (so kind-of a combination of the first way too).

 

Only have one control for inheritance and reference; all other controls are small, one control dialog boxes.

 

There is a more complicated third way to do this if it fits. Only the main control is really exists in the using VI.  All other controls are used more as small, one control dialog boxes appearing in the correct position.  This really only make sense if these other controls are only opened for certain interactions and then are dismissed.  The DataGrid QControl has controls that appear to popup when a cell of the multicolumn listbox is double-clicked.  This was accomplished by having these controls as subVIs that are moved and opened to appear above the cell.

Quentin "Q" Alldredge

Chief LabVIEW Architect, Testeract | Owner, Q Software Innovations, LLC (QSI)
Director, GCentral | Admin, LabVIEW Wiki | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner



Message 2 of 4
(3,410 Views)

Thanks for the info. For my application I'm going with option 2. There's a main plotting window and three selectors that go along with it to allow the user to select which parameter for X, Y, and P (where each value for P gets its own line drawn on the graph). At least for this instance, I won't need to interact too much with the selectors, but there is a lot of stuff I can do with the graph itself. So far the UI is working fine, so I'm happy with this method. It also allows reskinning a bit easier than the cluster method in case I want to go with Silver/NXG/System plots or selectors.

0 Kudos
Message 3 of 4
(3,387 Views)

A fourth solution is to work with a subpanel reference.

This is done in one of the wonderful examples on github.

0 Kudos
Message 4 of 4
(2,906 Views)