An Extensible, Object-Oriented Alternative to XControls

[TurboPhil]

This is pretty neat.

Having implemented something like this (though not as polished/extensible) in the past, I would caution you to consider this unfortuate wrinkle: your event handler modules might have problems registering for events on control references if the containing front panel is not open.

Most of the time, that probably won't even come up. But if you place one of these QControls on a VI that you run in the background--whose front panel is only opened on demand--then it can bite you. Registration for front panel events throws an error if the front panel is not open when you register. So if you launch the event handler while the owning VI's FP is closed, then you end up not catching *any* events. This can be especially annoying when debugging, since the behavior can change depending on how you run the calling VI (e.g. "this was just working a moment ago when I ran foo.vi by itself, but now it's not working when I call it as a subvi. Ugh!").

Again, it's not a common use case, so it might not ever come up. But food for thought.

[TheQ]

I actually do handle that scenario.  The Event Handler Dispatcher checks that the front panel of the VI using the QControl is open before launching the Event Handler.  It does mean that the FP must be opened before the Event Handler can start. I think the FP can be in the "hidden" state and still work though.

(In actuallity, the mechnism that is used is that the dispatcher attempts to register for a dynamic event in a loop, catching the errors.  If the VI is never opened, the Close Method of the QControl will stop it.  Otherwise, when the FP is opened it passes the loop and launches the Event Handler.)

Good question.  Thanks for pointing that out.

--Q

[TheQ]

For anyone that would like to rate the QControl Toolkit and/or write a review, the "Ratings and Reviews" is finally available on the tool's NI Tools Network page.  Just follow the link in the original post.

[ThHagel]

Hi Q!

Thanks for sharing this impressive work with the community!

I'm actually trying out your framework for the first time and I encounter the following problem:

I try to make use of your OO-approach to extend existing qControls. My plan is to create qControls that inherit the functionalities provided by the parent class and extend with other functionalities. As an example: think of a new qControl derived from your MulticolumnListboxSelection Class, which than adds a sorting functionality. Derived from that I could imagine a qControl Class adding a filter feature and so on.

So, basically I‘d like to add multiple functionalities over time as an iterative development process using OOP to encapsulate each functionality. My objective is to provide a single enhanced qControl (derived from a specific parent control type) to other developers, to enable them to easily select from the available enhancements and combine them as required. Just as we are used to enable, disable and tune features on the regular LabVIEW controls using property nodes (I admit though, I would also like to have non-runtime options like the context menu or properties dialog, but well...).

Trying to follow this idea, I get stuck as soon as I get to the implementation of the Event-Handler VI.

I realized that, due to the dynamic dispatching of the Event-Handler-VI, each derived class has to not only contain its own event handling code, but also a copy of the parents code in order to keep the parents features working. This conflicts with the idea of encapsulating code.

Do I see things clear so far?

I wonder if I could go without incremental class deviations, by deviating each extended qControl from the same parent qControl (in my example your MulticolumnListboxSelection would be a sibling of the new MulticolumnListboxSort) and than use them on the same LV control reference. But I think I might end up having problems caused by the concurrent running Event-Handler-Threads (unless I apply some sort of protection).

Actually this all boils down to a single question:

Can I create multiple qControls in a way that they can be applied simultaneously (if required) on a common LV-control?

Thanks in advance for your advice and ideas,

Thomas

[TheQ]

Thomas,

Thank you so much for trying out QControls.  I am glad they have helped you.

If I understand correctly, you would like to extend functionality of a QControl by successive specialization through the inheritance hierarchy of the QControl.  

You could do as you have described by creating two (or more) sibling classes and giving them both the reference to LV-Control. This leads to two (or more) event loops operating on the same LV-Control.  Many architects in the community would say this is bad programming practice for good reason; you could end up with unintended consequences due to both loops trying to change aspects of the LV-Control.  This is more problematic when custom state data is saved which is not shared between the siblings. However, nothing would stop you from being able to do what you described and as long as you kept the event loops from stomping on each other it could work.  One other difficulty that would also arise would be that now you have two (or more) constructors with two (or more) wires to pass around to handle one LV-Control.

There is another option.  Nothing says that a child QControl has to have an Event-Handler VI.  Sure the wizard creates one for you but you can delete it if you want.  If you do, the Parent's Event-Handler VI gets called instead.  (You wouldn't want to do this if you inherit directly from a "Interface" Class unless you don't plan on handling any events.)  

So, what does this buy you? You would only have one event loop running for the LV-Control.  You would handle all the events in the parent class Event-Handler VI and have overridable methods that execute the actual functionality.  The parent could have a no-op method for sort where the child class fills it in with the sorting algorithm.  When using a child QControl and the parent Event-Handler in this manner the child class is conserved when the parent Event Handler launches.  Therefore, any event using an overridable method will dynamically dispatch to the child's method if available. Based on the constructor used, the wire type would then change the LV-Control's behavior.

I do something similar in the TreeSelection QControls which are included in the toolkit.  The TreeSelection QControl is the parent class and the only one that has an Event-Handler VI. It also has an overridable method called Toggle Selection.  The TreeSelectionHierarchal and TreeSelectionSingle QControls do not have Event-Handler VIs but they do override and extend the Toggle Selection method to change how the selection takes place.  

I hope this helps.  Feel free to ask followup questions if I haven't answered your question.

Sincerely,

Quentin "Q" Alldredge

[TheQ]

I just posted in the documents section a new QControl.  I call it the ColorSelector QControl and it can be found here.  

Again, the code is unlocked so everyone can see how it was done.  It is for those of you that want your user to select a color without having to use LabVIEW's built in one that is only accessible by clicking on a color box.

Enjoy,

Quentin "Q" Alldredge, CLA

Q Software Innovations, LLC

NI Alliance Partner

[TheQ]

All,

Thank you all for your interest in QControls.  I was hoping to make an appearance at NIWeek and meet up with anyone that had questions for me but unfortunately I won't be going this year due to scheduling problems with my other projects.

However, I have started a blog to help answer questions, share more of the QControls I have created, and give more insight into the QControl Toolkit.  The blog can be found here:

qcontrolsqsi.blogspot.com

Feel free to post questions here or at the blog.  I felt the blog was a better forum to share my QControls I have created.

Thanks again.

--Q

[TheQ]

I added a new QControl to share.  It is the BreadcrumbNavigator QControl and can be found here.

BreadcrumbNavigator QControl

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.

Please let me know if you can't get to it.  Also, I would love to hear about others anyone has made.

Thank you and enjoy.

[TheQ]

I just added a new QControl to my blog, it is the RichTextBox QControl and can be found here:

RichTextBox QControl on QSI QControls Blog

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.

Check it out and enjoy!

[TheQ]

 I had this question posted to the QControl blog:

"Dear Q,
I've installed Qcontrol through VIPM on LabVIEW 2017 (french), but the "New ..." menu doesn't show me the Qcontrol wizard. Is ther an other path to access to the wizard ?
BR"

I have not seen this problem installing in 2015, 2016, or 2017 but I only have the English versions.  Has anyone else seen it in other languages?

Anyway, to answer the question, the QControl Toolkit installs to the following locations in the LabVIEW folder:

The VI that is called by the New Dialog (when running correctly) is at:  [LabVIEW]\resource\plugins\QControl\New QControl.vi

This is the recommended way to access it if it is not showing in the New Dialog.

The main code for the toolkit is at: [LabVIEW]\vi.lib\QSI\QControls

With the main VI for the QControl Creation Wizard is at:  [LabVIEW]\vi.lib\QSI\QControls\QControl Wizard\QControl Creation Wizard\QControl Creation Wizard.vi

If you open this it won't auto run so you'll have to run it.

If the installer adds it correctly the New Dialog is partially defined by an XML file located at: [LabVIEW]\\resource\plugins\NewDialogFiles\LVNewDialog.xml

The installer should make a copy called LVNewDialogOLD.xml before adding the entry for the QControl Wizard. The entry in the XML should look like this:

<Node>
<Name localize="yes">QControl</Name>
<GUID>{4048C645-BD8D-4B94-8BB6-BF27DBC20EE4}</GUID>
<ParentGUID>8E4D36AD-F776-4C48-97C6-C1D85EFE889F</ParentGUID>
<ItemPath>/resource/plugins/QControl/New QControl.vi</ItemPath>
<ItemType>ProjectWizard</ItemType>
<Description localize="yes">This launches the QControl Creation Wizard to step you through the creation of a new QControl.</Description>
<ImagePath>/resource/plugins/QControl/QControl Class.png</ImagePath>
<MagicNumber/>
<Weight>-1</Weight>
<Version/>
<ChildOnly>1</ChildOnly>
<ProjectPossible>0</ProjectPossible>
<NDIconPath>/resource/plugins/QControl/QControl Class Icon.png</NDIconPath>
</Node>

I'm wondering if this is where it goes wrong for the French version.  If this XML file is language specific.  Let me know if that is the case.

For the sake of completeness there are also examples that are installed to: [LabVIEW]\examples\QSI\QControl Toolkit

And help is installed to: [LabVIEW]\help\QSI

Hope this helps.

--Q