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