Window shown by DLL; whats missing?

Windows
1

…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?

BOOL APIENTRY DllMain(HANDLE hModule,
                      DWORD  ul_reason_for_call,
                      LPVOID lpReserved) {

	switch (ul_reason_for_call) {
		case DLL_PROCESS_ATTACH:
			PlatformUtilities::setCurrentModuleInstanceHandle(hModule);
			initialiseJuce_GUI();
                        // Start a message manager thread here?
			break;
2

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.

3

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

 Don
4

Hmm.

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?

5

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.

6

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

Cheers Jules

7

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!
JUCE_ASSERT_MESSAGE_MANAGER_EXISTS

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))
owner.handleAsyncUpdate();
}

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

8

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

9

Opened a new post here:

10

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