Due to difficulties with using XControls with other classes, libraries, packed-project libraries (PPLs) and the Actor Framework, I created a new framework that gives you many of the benefits of XControls without many of the headaches. I call them QControls. QControls allow easy UI Logic Code reuse, encapsulation and decoupling of the UI Logic away from the Business Logic of the main application and from the UI Skin. Introduction to QControls with tutorials and complete documentation is attached in the PDF. Also in the attached PDF, I explain more about the trade-offs between QControls and XControls. In the toolkit there are examples that are installed into the Example Finder; just search for the keyword "QControls".
I would like to hear peoples' feeback and questions here on this discussion. If you like it, please give it a good rating and leave a review on the NI Tools Network page for the toolkit as soon as the feedback page becomes available.
Quentin "Q" Alldredge
Certified LabVIEW Architect
Q Software Innovations, LLC
NI Alliance Partner
Nice. I've made a similar attempt at an Xcontrol alternative. The biggest advantage over Xcontrols, IMO, is that Xcontrols completetly replace, rather than extend, regular controls. With a package like this, one can just add functionality to multiple different existing controls. The controls can even have different data types (I developed my package to add features to Graphs and Intensity Charts which can have varying data type).
You know I never made that connection that XControls replace rather than extend. That would have been a good bullet point to point in my documentation. I did try hard to make QControls extensible .
I added a new QControl to the documents section in this forum, found here. It is the AnimationRing QControl which can be used for animation for loading/busy indication when animated gifs can't be used.
The AnimationRing QControl is based on a picture ring control. The elements in the picture ring represent frames of the animation. The frame rate is settable via property node. The animation only occurs when the ring is visible. Setting the ring control to not visible effectively pauses the animation.
The toolkit looks very useful!
I am going through the quick start example, and I have gotten stuck. After creating the Property Definition Folder (CorrectColorBG), I try to create the VI by right clicking the folder and selecting New -> New VI from Static Dispatch Template. A new VI appears with the class in and out and error in and out terminals. When I try to save it, I get the following error dialog.
Has anyone else seen this or know what would cause it? I think I followed all the prior steps with nothing else open in LabVIEW. I'm uising 32 bit 2015 SP1 on Windows 7.
Yes, I see the same problem. The problem is when the wizard completes and opens the class, the class itself is in a weird state. Although it has been created, saved, and is not locked; added VIs don't know the correct path to save to. I'll see if there is anything I can do to fix that.
However, if you start the wizard from an open project, the QControl class will be added to your project automatically when the wizard completes instead of opening the class directly. Then you won't have the problem.
I tried to install it to 2014 using VIPM, and it failed, since one of the install VIs needed LV2015 to run 😞
Do you have a 2014 version?
Yes, there is a post-install VI that runs to put QControls in the "New" dialog so that the QControl Wizard will launch from it. I did write the toolkit in LV2015.
I could save the toolkit for previous versions of LabVIEW but that will lead to other problems. This is because all of the available run-time properties from the VI Server have equivalent properties in the QControl Classes (see my PDF Sections 5 and 6). LV2015 has new properties that LV2014 and earlier do not have. So those properties would be broken if saved in previous versions and cause the whole toolkit to be broken.
I could look into creating versions of the toolkit for LV2014 and earlier. It would be fairly simple to save the post-install VI to earlier versions of LabVIEW; but I wonder if there is a way I could disable those newer properties to just be no-ops if the LabVIEW version does not have it? I guess this is a question to the community, if anyone might have ideas for a solution. (Other than maintaining multiple releases which I don't really want to do.)
I added another QControl to share. It is called the Calendar QControl and can be found in the documents, here.
I had this as an XControl first off and just reprogrammed it as a QControl. Hope you like it.