Jump to content

An Extensible, Object-Oriented Alternative to XControls

Recommended Posts

The QControl Toolkit by Q Software Innovations is an object-oriented and extensible alternative to XControls. Use the QControl Toolkit framework and the QControl Creation Wizard to create QControl Classes and receive the benefits of XControls without the headaches. Take advantage of easy UI logic code reuse. Encapsulate and decouple the UI logic away from the business logic of the main application and from the UI skin. Use wherever the VI Server and LabVIEW object-oriented programming are allowed. Easily extend the capabilities of current LabVIEW controls through access to all properties available at run time. And easily use the toolkit with more complex frameworks like the Actor Framework or other plugin architectures where LabVIEW libraries and packed project libraries are used and where XControls can behave unpredictably. 

Check it out now on the NI Tools Network here.

I also started a thread on the NI Community: UI Interest Group page, here.

  • Like 2
Link to post
Share on other sites

Thank you. I do hope it becomes a useful tool for everyone. 

I posted another QControl that controls animation on the UI Interest Group Community page, here

Also, a question...

What would be the best way to share these QControls? My thoughts were either to zip them as I did with the animation one or use VIPM to create packages for them. I want people to be able to share theirs easily as well. 


Edited by The Q
Link to post
Share on other sites
  • 2 years later...

Old thread, but since interest in the toolkit was rekindled in another thread, I decided to give it a try.

I am facing some trivial issues. When I try to create a new control, saving fails in several steps:

1) in the folder selection page, I am first told that a Qcontrol already exists where I know there is none:


2) When I try to circumvent this problem by creating an additional folder and select that folder, the wizard is obviously confused as to which folder I am choosing, as illustrated below:


Above, I have created a Q Control folder and selected it, but the final path is bogus...

3) While the above isn't flagged as an issue (yet), creating the class fails (as it should):


As a side note, the scrollbar is frozen, so I can't read the full error message...

Thanks for checking.

Tested on a MBP running LV 2018 SP1f2 64 bit in a Windows 7 SP1 VM (Parallels Desktop).

Link to post
Share on other sites

I’ll try to recreate the steps you went though when I get home this evening and let you know what I find. I wonder if there is something weird going on with trying to create it on the desktop.  Looks like the wizards is in some confused state to come up with a path like that. The default is:

[Your path]\[QControl Name]\[QControl Name].lvclass

Edited by The Q
Link to post
Share on other sites

Thanks. I first tried on a network drive (that's how my MBP folders appear on the Windows VM) and it failed the same way I described, so I tried to simplify the path using the Desktop.

I just tried a different path (C:\Users\X\Downloads\) and of course that worked... Duh.

Another note: the inheritance dialog has a large latency (several seconds) as far as response to user clicks in the tree is concerned. No biggy but not usual...

Link to post
Share on other sites

I'm glad you were able to figure out the folder problem.  It was working for me on the desktop.  You say it has trouble on a network drive?  I'll have to find some way to test that.

As for the tree, I don't see the same latency.  Is it the same every time you launch the wizard?

Link to post
Share on other sites

Actually, today I have no such folder issues... 😞

Not sure what's different (beside my MacOS 10.14.4 update).

The lag is consistent and persistent.

Also, when the path selection dialog pops up, it is hidden by the Wizard's window. Again, no biggie but not usual (actually I have seen such a behavior in Matlab executable - it might be a Windows thing...).

Link to post
Share on other sites

I can’t seem to duplicate the lag or the popup dialog problem. I wonder if it has to do with your LabVIEW being 64bit. I don’t have LabVIEW 64bit installed right now.  I’ll have to install it and give it a try. 

Link to post
Share on other sites

Nope, I tried it in LV 2018 32 bit to the same effect. That may have something to do with my setup (MBP core i7 16 GB SSD running LV 2018 in Windows 7 - VM in Parallels Desktop with 10 GB of dedicated RAM).

Link to post
Share on other sites

Not sure that's the issue, but lags can sometimes occur because the installed code is not compiled for the current version you're using. If you're using VIPM to install the package, make sure your options are set not to prevent compiling after installation. Alternatively, browse to the installed package folder and force it to mass compile.

I've seen this behavior for code that installed under Tools menu (under LabVIEW 20xx/project) which were not compiled, so there was always a lag the first time you load it in memory. Being being installed in a non-write accessible folder, it would cause the same issue the next time you'd open LabVIEW and brought the code back into memory.

Link to post
Share on other sites

I just mass-compiled the user.lib and vi.lib\QSI folders.

Same symptom: when I select a category in the tree, it is highlighted right away, but it takes several seconds before the checkbox is checked (off or on).

On a related topic,  I am a bit confused by the disconnect between selecting an item and checking it off. For instance, in the snapshot below, I have the Array class checked off and the Boolean class selected (but not checked off). What would be the purpose of this?


Edited by X___
Link to post
Share on other sites

I'm pretty sure the item selection in that tree means nothing, and setting it to -1 and disabling it might be the best option so not to confuse the user.  All that matters is what items are selected with the checkbox.  And even the checkbox acts like a radio button where only one item can be selected at a time.  You can of course have multiple controls in a QControl, but it will only inherit from one class.

Link to post
Share on other sites

OK, so I must the nightmare of a developer, as I am facing the same new Qcontrol path nonsense again (with the random failure symptom as well to boot).

Let me recap:

- When choosing where to create the QControl, I typically want to choose a new folder, therefore I create one (*) by either typing the name of a new folder I haven't yet created, or using the "browse" button and creating one,  opening the newly created folder and clicking "Select Current Folder"

- The indicator labeled "The final path will be" then reads: "path of the newly created folder\LabVIEW\QControls"

- obviously the next step fails (but does create the two additional folders (LabVIEW and subforder QControls).

(*) Just for kicks, I tried to NOT create a new folder, and use the "QControls" top folder I have saved a few test QControls in and I then get the following error:


That part seems to "work": the wizard requires an EMPTY folder to proceed.


I looked at the Wizard VI that handles that part of the dialog (Update Save Location.vi), and it seems to be explaining part of my issues:

- if the creation fails the first time, that VI will use the last two hierarchy levels of the "final path" and append them to the proposed creation path!? I am not sure I understand the reason for that, but I understand that it doubles down on a first failure...


Since I can't reinitialize this indicator, the only option is to quit the Wizard and start over again. There must be a better approach...

Edited by X___
Link to post
Share on other sites

@flarn2006 sorry I didn’t know about your tool.  It would have saved me time.  I created one of my own. Your’s looks better though and has more features.

@Francois Normandin and I discussed the lag on first call and I am adding a fix to do a post install mass compile to see if that fixes it.

@X___, I’m sorry there have been so many problems. I’ll take a look at the folder code tonight.

As for using the checkboxes, the wizard uses the Tree Single Selection QControl to be seen as an example. I’m not sure why the performance is so bad for you as I have not seen that anywhere else. If it is better for user experience, I could remove the use of that QControl in the wizard.

The wizard also uses the Steps QControl for the tab disabling and the StatusHistory QControl for the status string during the creation scripting process.  Has there been issues with those as well?

Link to post
Share on other sites

I'm working hard to try to understand the problems.

I'm currently stepping through the wizard code node-by-node trying to see the path problems you are seeing. 

One thing I see is when you start the new dialog when a project is not open or the project is not saved, the default folder it picks first is the [LabVIEW Default Data Directory]\QControls\[QControl Name]\[QControl Name].lvclass normally this is in the [User Documents]\LabVIEW Data\QControls\[QControl Name]\[QControl Name].lvclass.  This is why you are seeing the "LabVIEW\QControls" coming up as default.  If the wizard is started when a saved project is open then the default path is relative to the project: [Project Path]\[QControl Name]\[QControl Name].lvclass

At the VI you showed above, nothing has been created yet.  It has just constructed the path as the destination of the new QControl class and the indicator for the final path shows you where it thinks it ought to be saved.  However, something very wrong is happening for you if it is keeping the "LabVIEW\QControls" in the path.  At this point it should be the have a folder using the class name and the class. 

The destination should be showing you the class name and folder like this:


The error down stream occurs when the path is checked to exist already.  The full path with the new class should not exist yet.  But if your path is just folders that do exist it will pass the error at the check here:


So, now why is it not showing the class name and folder?  Does the QControl Name tab let you past without typing the new name?  If the name is blank I could see this being the cause but the Next button should be disabled until you type something in.  (I found an error I should catch as it does let you just type a space and that would be bad too.)  If you do specify a name, I wonder why it is not being passed correctly.  I can see now that the way it is being passed is not robust enough and that will need to be fixed.

After it starts the scripting, if it fails, it does have to be started over.  This could probably be more elegant but if it does error while scripting there is no cleanup code to remove what was partially created.  Maybe I should add this in the future.

Link to post
Share on other sites

Now on to the sluggish behavior problem.  Can you reach the examples in the Example Finder?  In the Example Finder search for QControls and test each of those out and let me know if it is all of them or just the Tree Selector one.  This will help me narrow the problem down.

@X___, I'm sorry this has been a bad experience for you but thank you for your patience and for being a troubleshooter for me.  With your help we can make this event better.

  • Like 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Ryan Vallieu
      I have seemingly found an issue with the shipping example code for Nested Malleable VIs.  Another user has verified that he saw the same behavior in 2019.
      I am working through the examples and the presentation from NIWeek 2019.  In running the Lesson 2b code (C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Malleable VIs\Nested Malleable VIs) I found the Equals.vi in the class was not being leveraged and the search failed.  When I went to my LabVIEW 2018 machine and ran the Lesson 2b.vi the code worked to find the element by correctly leveraging the in-class Equals.vi.
      One difference I see is that in the 2018 example the Equal.vi is in the example folder with the code, and in 2019 the Equal.vi has been moved to VI.lib - otherwise the code looks to be the same.  The Equals.vi code looks identical, and the calling VIM look identical.  I posted on the LabVIEW NI.com forum here: 
      I am trying to determine what may have broken or changed between the implementation in 2018 and 2019, visually the code looks the same.
    • By dcoons
      Inspired by my question from this post: link, I started off on a path of packaging project dependencies into vi.lib as suggested by @smithd and @Darren  however I have started down a rabbit hole of packed project library (ppl, *.lvlibp) head scratchers that have left me a little confused on what is going on in the background. Most of my components are built into packed libraries because I am following plugin models for extensibility when building as an EXE.  To make packed libraries work with dependencies, you basically have to build those into packed libraries as well to avoid the namespace issues.
      I used VIPM to create packages to distribute some of this shared code to vi.lib.  In the example below, I created a packed library (Controls.lvlibp) and packaged it to vi.lib for use.  In the Limits project in the image, I am using the Controls library in a few of the functions. Limits also contains a build specification to create a packed library for a component.  However, I first noticed an issue when I looked at my child class projects (that inherit from the Limits.lvlibp:Limits.lvclass).

      The Limits.lvlibp is showing as Not Loaded. When I go directly to the library on disk and try to open it, I get the message "Project or Library file cannot be opened." I notice that if I get the correct Controls.lvlibp into memory by opening it up or by putting one of its VIs on a block diagram, then the library will load correctly.  So, I know it has something to do with when data from vi.lib is loaded into memory, but I don't know how to force it into memory to get this to work correctly.  Generally I am selecting the option to "Exclude dependent packed libraries" in my build specifications, but if I leave that unchecked it will open properly (because it places the dependency directly next to where it is built).  I did not have these issues until I placed my shared components into vi.lib, so I would be grateful for any help to help me debug this!

    • By ensegre
      Is anyone aware of a limitation on what the smallest possible FP size is? On LV 2017, I am under the impression that this is 116x41 on one windows machine, and 1x1 on a linux. Known issue, WM, or deserves a CAR?
      The reason I'm asking: I'm fiddling with the cosmetics of an Xcontrol. I would have nothing against a larger transparent border, but when I webpublish the big FP using it, the large transparent border turns grey on the snap png.
      ETA:, ah, https://forums.ni.com/t5/LabVIEW/How-to-set-front-panel-size-to-be-same-as-one-led/td-p/1565524
      ETA2: ok, tried the snippet of that thread and get either no reduction or eloquent "Error 1 occurred at Property Node (arg 1) - Command requires GPIB Controller to be Controller-In-Charge" for tighter sizes.
    • By Benoit
      Hi there!
      I am trying to find a workaround the the missing possibility to set key focus in an array at a specific location by using X-Control.
      I am struggling at the point that i manage the key focus in my X-Control to work, but I cannot set to other control. it always stay at the same one...
      Is anyone manage to enable key focus on specific element of a X-Control?
    • By Voklaif
      Hello all,
      I am programming with LabVIEW for around 2 years and was recently stumbled upon LVOOP.
      I am required to write a communication protocol to work with a micro-controller, which later will be also used for ATP and debug purposes.
      I want to build the program "correctly" from the beginning so it will be maintainable and flexible to additions and changes.
      My natural way of building a program would have been a queued state machine, with several loops, each loop is in charge of a different module (one for GUI obviously), but as I stated in the beginning, I want to use LVOOP.
      Does anyone have a LVOOP project I can use as reference? I've searched online and found some nice examples, but they are small and teach you the basic stuff.
      For me it's important to see the how to use the project tree wisely, where to place the classes, see the managing loop and to learn as much as possible before I create one of my own.
      Thanks in advance,
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.