An Extensible, Object-Oriented Alternative to XControls

[TheQ]

No this will only ever create one instance of the leak during the life of the program.  Memory leaks should be avoided especially in a loop that could grow over the long term.  This ensures there is the only the one no matter how many QControls are called.

I don't know all of the reasoning for this except that the Open VI Reference is a slower operation compared to the Start Asynchronous Call.  The reference to open a new instance will always be the same. So I try to launch a new instance of the Event Handler Dispatcher.vi, if I can't then I know the reference has not been created yet and I create it.  Every time this VI is called after that the reference is stored in the uninitialized shift register.  It is left open which is the cause of the leak.

The Actor Framework code for launching the Actor.vi, shown below, gives more insight.  It show an explanation with a link to the following thread: https://decibel.ni.com/content/thread/12923.

Hope this helps.

[xub]

Thank you for the reply. It makes sense to me now.

I did see only one reference leak after making multiple calls of QControls from root loop and stopping the app in development environment. 

However, DETT captures Event Handler Dispatcher.vi errors after stopping the app using PPL version of QControl. 

Attached please find DETT exports from both scenarios.

[xub]

Could please comment on the error in red from QControl?

It shows up again on another project of mine when calling it from packed library only

[TheQ]

I do run QControls from PPLs and have not encountered the error your seeing.  I can't be sure without running your actual code but it could be that the reference to the control is going inactive.  This happens when the owning VI is closed but you hold on to the QControl.  The Live Caller check should have caught this scenario.  QControl wires should be treated like reference wires.  So if you are opening and closing your front panel you should open and close the QControl with it.  This ensures that the control's reference in the QControl is always the fresh one.  If there is any state that has to carry over from one run to the next then that will have to be handled internal to your application.

However, if your front panel always remains open, than the error must be about something else.  Again, I would need to run your code to find out.  

[golfman]

Hey guys, going all the way back to page2 back in 2016 Oct 17.  

I just started trying to use Qcontrol in the past week and I like the idea.  I use DQMH primarily and think there may be someone else out there that may benefit by emphasizing the fact that Q pointed out that:

The VI using the Qcontrol must either already be open OR the 'FrontPanel Open' method must be ran before the Qcontrol EventHandler starts.  

Everything was great until I went to put the contructor ('New <insert your cntrl name here>.vi) outside the EHL and MHL and tried calling the module from another module.  Then I got errors when the module using Qcontrol wasn't already open.  The error said something about "In Place Element structure..." something or other which sent me down the wrong rabbit hole but the note in 2016 gave a clue and i was able to fix pretty easy.  After reading the post back on page2, I tried moving the constructor into an FGV and placing in the MHL  AFTER the FP Open method was ran, no more errors occurred.

Again, 

The VI using the Qcontrol must either already be open OR the 'FrontPanel Open' method must be ran before the Qcontrol EventHandler starts.

Let me know if anyone finds any issue with this being a fact or with the solution that I used. 

Thanks.

[golfman]

OK, i'm encouraged from the kudos that I must be doing something right.

So, before I go trying to inbed a .net datagrid into a qcontrol custom control, I have a question. How does one actually make a datagrid happen in LabVIEW?

Also, hope I don't offend Q with this but how do I uninstall the right click option to 'Convert to DataGrid'.  Nothing happens when I click it and I'd rather uninstall and do it myself than to fix the install.

[TheQ]

---

@golfman wrote:

Also, hope I don't offend Q with this but how do I uninstall the right click option to 'Convert to DataGrid'.  Nothing happens when I click it and I'd rather uninstall and do it myself than to fix the install.

I’m very offended. Just kidding. I’m just happy I help someone get inspiration for other ideas.

The “Convert to DataGrid” is installed as a Right-Click Menu add on. To remove it just find the LLB file for it in “[LabVIEW 20xx]\resource\plugins\PopupMenus\edit time panel and diagram” and delete or move it out of that folder. 

[golfman]

Success!, I deleted the DataGrid Config.llb from [C:\Program Files (x86)\National Instruments\LabVIEW 2020\resource\plugins\PopupMenus\edit time panel and diagram\] and the right click menu is gone.

Still though, thanks for Qcontrols Q!  I'll be using in the future.  Its so nice to separate user interface controls from the main application!