An Extensible, Object-Oriented Alternative to XControls

[The Q]

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.

[Neil Pate]

Wow, a lot of work has gone into this! Nice toolkit Q.

I have never been a big fan of XControls as they just have too many weird issues.

 

[The Q]

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. 

--Q

Edited October 13, 2016 by The Q

[X___]

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).

[The Q]

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 April 4, 2019 by The Q

[X___]

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...

[The Q]

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?

[The Q]

I tested to a shared folder on my laptop and it worked fine.  Not sure what the folder problem is.

[X___]

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...).

[The Q]

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. 

[X___]

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).

[The Q]

Well, I have a similar computer but I’m not running as a VM.  Could that be it?

[Sparkette]

I haven't used this toolkit much but I'm using a Windows 7 VM as well and I haven't noticed any issues.

[Francois Normandin]

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.

[X___]

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 April 10, 2019 by X___

[hooovahh]

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.

[Darren]

Seems like the checkboxes aren't even necessary if you're only picking one class to inherit from. Just pick a row in the tree and click Next.

[X___]

Sounds like getting rid of the checkboxes would kill two birds with one stone...

[X___]

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 April 11, 2019 by X___

[Sparkette]

@X___: I'm curious, how did you make that class wire look like that? I know how to do it; I'm just curious if you used my tool to do it.

 

[X___]

@flarn2006This is the Wizard's code. Not mine.

Edited April 11, 2019 by X___

[X___]

All this being said, now I am completely unable to create a QControl, wherever I try to save it...

[The Q]

@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?

[The Q]

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.

[The Q]

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.