Window shown by DLL; whats missing?


#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