From 11:00 PM CDT Friday, May 10 – 02:30 PM CDT Saturday, May 11 (04:00 AM UTC – 07:30 PM UTC), ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
The QControl Toolkit is a fantastic library of tools for developing reusable UI components. I think they are a great alternative to XControls. Not only does the QControl Toolkit provide me the framework for developing my own QControls, but it also ships with some fully functional QControls, my favorite probably being the tree with checkboxes.
I think QControls are useful enough for all LabVIEW users that they should be part of the LabVIEW core product instead of an add-on toolkit.
What would be REAL nice would be if we could use them just like regular controls. That is, you just place it from the controls palette, just a regular terminal on the block diagram that you use like any other, and (most importantly) they behave as expected inside clusters and arrays. Just like with regular controls, you don't need a reference to the control for basic read/write functionality; if you want to do something more advanced that requires a reference, you can use the VI Server Reference node. Maybe even have the reference wires automatically (or through To More Generic Class) coerce to the refnum type of the control it's based on without anything extra.
Basically, if this is implemented the way I hope it is, using a QControl would be no different from using any other control. And of course, the current way of using them would still work, for backward compatibility.
For those interested it's worth noting that if you have a NI account that has access to the Center of Excellence, there's a video there of Q himself presenting at NIWeek 2018 showing a lot more details and live examples.
I did create a way to get all properties and values of the properties of an object quickly but not as part of the QControls. It is part of my Property Browser I presented last A-CLA Summit during a 7x7. It was the IDE Addons presentation.
The same method I used to gather the data, with something to write to string/file could be used to accomplish serialization. The setter would be a little harder but I do something with scripting to allow property sets as well.
I believe all of those dependencies are licensed under BSD, and making a copy and modifying it is allowed, typically as long as the original author is attributed. If this were added to LabVIEW there are multiple options, one of which would be to just include a copy of those functions that are actually used, and not include the full packages. I'd much rather NI include OpenG and MGI as part of the base LabVIEW install, and in fact I install all of that stuff on all LabVIEW installations I do anyway.