LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Darren

Add QControls to LabVIEW Core

Status: New

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.

17 Comments
TheQ
Active Participant

For more information about QControls see the LabVIEW Wiki page here:

 

https://labviewwiki.org/wiki/QControl

 

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



joerg.hampel
Active Participant

+1




DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (The Future of Team-Based LabVIEW Development)


flarn2006
Member

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.

 

Think this is a possibility to any extent?

Kyle97330
Active Participant

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.

 

Link to CoE page with the video link on it

wiebe@CARYA
Knight of NI

52 kudo's in 2 days!

 

I wander how high it will go.

TheQ
Active Participant

Thanks Wiebe!

 

All,

 

Please share the LinkedIn post and retweet the Twitter post to get this even further. 

 

LinkedIn:

https://www.linkedin.com/feed/update/urn:li:activity:6517211236399218688

 

Twitter:

https://twitter.com/qsi_q/status/1111454147973271552?s=12

 

Also there has been some good discussion on LAVA:

https://lavag.org/topic/20836-help-get-qcontrols-added-to-labview-core/

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



wiebe@CARYA
Knight of NI

Is there a method to serialize properties (to\from string\file) yet?

 

For me that would be a great feature, not just for QControls, also for normal controls. We can talk about that at NI Week... 

TheQ
Active Participant

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.

 

https://forums.ni.com/t5/Certified-LabVIEW-Architects/All-Q-s-Presentations-from-the-2018-Americas-C...

 

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. 

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



smithed
Member

I like the idea but its worth saying that the dependencies are an impediment:

Capture.PNG

Personally I don't even want to install all this stuff, and I'm assuming NI doesn't want to be on the hook for shipping something that depends on it.

Hooovahh
Proven Zealot

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.