Determining plugin MouseInputSource leak

1

Hi,

I have been getting the following assert when quitting the host DAW :

*** Leaked objects detected: 3 instance(s) of class MouseInputSource

but only when I’m in this loop :

    while (isVisible() && !(MessageManager::getInstance()->hasStopMessageBeenSent())) {
        MessageManager::getInstance()->runDispatchLoopUntil(5);
    }

what I’m trying to achieve is a “modal” pop-up that doesn’t block the plugin host. This works fine if I’m in that loop and close the plugin window, or close the “modal”, but if I quit the host DAW I’m getting the leak detection. I took inspiration for this loop from the ThreadWithProgressWindow class runThread() method.

Only other similar forum post I could find was talking about the exact same leaks, but in iOS when it’s iOS that is making the app quit, and the advice was that it could be safely ignored, so I’m wondering if I’m in a similar boat?

Or maybe someone will tell me that this while loop is the worst idea imaginable :smiley:

Thanks,
Rich

2

I think it is messy at best :wink:

When I need modal access over my GUI, usually I simply add a Component over the whole window, that will consume all mouse events.
You can even make it half transparent to give the user a hint, that the rest of the GUI is inaccessible.

HTH

1 Like
3

Thanks for the input. I am doing a similar thing with a semi-transparent Component that covers the whole window, what I had before was some showOkCancelBox that were continuing execution after the answer given, but these were blocking the host. I wanted a similar way to show my question, wait for the response then carry on executing, but I suppose will have to use a callback or some other method to pass the answer back.

4

Yes, that is the preferred way. Running the event loop yourself has so many edge cases to think about, I really would avoid it at all cost.

1 Like
5

Yes, it’s the worst thing imaginable.

Honestly, if the worst thing you see is a leak, then you’re lucky. Quitting the app while there’s a whole bunch of unknown stuff sitting on the stack underneath this run-loop, which will all be unwound after the quit message has been processed is just a total nightmare! On Android, the OS makes it impossible to run synchronous message loops like this, and for good reason! Don’t do it!

1 Like