Window shown by DLL; whats missing?

…The window

My problem is that I have a .dll, built with JUCE that needs to display a window. The code that generates a DialogWindow subclass all runs but nothing appears on the screen, but an entry does appear in the taskbar. Having perused several threads here and the VST plugin code I thought I had found the answer - that there was no message manager thread running. I am however a little confused by that as the VST code seems to only compile in ‘SharedMessageThread’ in Linux builds. Am I up the right tree?

                      DWORD  ul_reason_for_call,
                      LPVOID lpReserved) {

	switch (ul_reason_for_call) {
                        // Start a message manager thread here?

Have you made certain that your DLL entry point is being called from your app’s event thread? On win32 it’s sadly essential to call initialiseJuce_GUI() on that thread.

I should add that adding a thread class a-la SharedMessageThread does not appear to solve the issue, so I am guessing something else is going on here.

The host application for this testing is a console application - I am assuming that a DLL should have no issue in accessing the Windows GUI in this case. I know in the VST scenario you tend to be adding windows into the space of other applications.

Thanks in anticipation



So in the case of a single-threaded application calling (ie. console) does that mean that there is no way around this?

The method I am using for loading the .dll is the standard link to the .dll export lib in the build, so the load is performed at application initialization time.

I am keen to see if I can find some solution; this fits with a client’s business case. He has legacy VB code that he wants to interface with my code doing the high-speed processing and feeding low-fi data to his code. We want to be able to visualize the hi-fi code from the dll.

If this places constraints on the host application - that is a problem.

However I guess a solution would be a secondary visualization application written as a JUCE App which communicates with the .dll through a named pipe…

But before going there - is this path a dead end?

Oh, you can’t use any GUI stuff in a console app! It’s impossible unless there’s an event dispatch loop running. Just build your app as a normal desktop app and it’ll be fine.

Glad I stumbled into a road block rather than stubbed my toe on something obvious.

Cheers Jules

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”

void AsyncUpdater::triggerAsyncUpdate()
// 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 :sweat_smile:

p.s. I did call the juce::Process::setCurrentModuleInstanceHandle() with the correct HINSTANCE, if that makes any difference

@ed95 perhaps you can help me here or point to someone who’s still active? Thanks!

Opened a new post here:

nevermind… In the end I did call the init functions from the app main thread and everything works fine