UI Interest Group Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

An Extensible, Object-Oriented Alternative to XControls

Highlighted

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.

 

TheQ_0-1598931162428.png

 

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.

TheQ_2-1598931987416.png

 

Hope this helps.

 

 

Quentin "Q" Alldredge

Owner, Q Software Innovations, LLC (QSI) | Director, GCentral | Admin, LabVIEW Wiki
Tech Lead, Hill AFB LabVIEW Center of Excellence | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner


0 Kudos
Message 51 of 54
(68 Views)
Highlighted

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.

0 Kudos
Message 52 of 54
(59 Views)
Highlighted

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

xub_0-1600128160130.png

 

0 Kudos
Message 53 of 54
(33 Views)
Highlighted

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.  

 

 

Quentin "Q" Alldredge

Owner, Q Software Innovations, LLC (QSI) | Director, GCentral | Admin, LabVIEW Wiki
Tech Lead, Hill AFB LabVIEW Center of Excellence | Creator, The QControl Toolkit
Certified LabVIEW Architect | LabVIEW Champion | NI Alliance Partner


0 Kudos
Message 54 of 54
(21 Views)