When you say GUI stuff does that include the AsyncUpdater class?
I’m using JUCE as an audio engine (dll) inside a Windows app (flutter), and I can’t get AsyncUpdater to work properly.
Basically, the first time I call triggerAsyncUpdate a message gets posted “somewhere”
// If you’re calling this before (or after) the MessageManager is
// running, then you’re not going to get any callbacks!
if (activeMessage->shouldDeliver.compareAndSetBool (1, 0))
if (! activeMessage->post())
cancelPendingUpdate(); // if the message queue fails, this avoids getting
// trapped waiting for the message to arrive
but on subsequent calls the shouldDeliver bool is always 1, so nothing happens. I dug into the code, and did a bit of debugging to see that AsyncUpdater 's message callback is never called, in my application.
void messageCallback() override
if (shouldDeliver.compareAndSetBool (0, 1))
Now, I can see that the only place messageCallback() is called on Windows is inside the MessageManager::runDispatchLoop(), which seems to be run only inside JUCE standalone apps. Is that right?
What I don’t understand is, if there’s a way that these messages posted by the AsyncUpdater’s triggerAsyncUpdate() can be “consumed” (i.e. messageCallback() → handleAsyncUpdate() → shouldDeliver = 0) by some event loop other than MessageManager::runDispatchLoop()?
Right now my DLL entry point is being called from the flutterUI thread (which is not the Windows app main thread). Doing that requires some ugly wiring.
Should I expect calling initialiseJuce_GUI() from the main thread to solve my issue? Would that help JUCE link to the app’s event thread which will run a ‘event dispatch loop’ itself similar to the one that’s implemented in JUCE as MessageManager::runDispatchLoop()?
I hope this makes sense
p.s. I did call the juce::Process::setCurrentModuleInstanceHandle() with the correct HINSTANCE, if that makes any difference