I am using juce in a DLL now, so I am using the event loop of the main app to handle events, and in the documentation to init the juce gui and such, it makes a reference on windows that you may need to use PlatformUtilities::setCurrentModuleInstanceHandle and pass in the handle, however, if I do that, it locks up the entire process. If I don’t pass it in, it works fine, so I don’t, but thought I would mention that…


Where does it lock up? The setCurrentModuleInstanceHandle function does nothing except set a static variable with the data you pass in, so if that locks up then it must be some kind of compile/link problem.

There are only two places the handle gets used, in MessageManager startup, and in creating windows, so I guess one of them must be messing up?


I can’t run it in debug as after I compile the dll it has to be moved to another system that is rather restricted. If I get a chance I’ll have it dump debugging info to a file that I can see where it crashes. As stated though, it works fine if I don’t use it.

It doesn’t crash when the function itself is called, as I call it upon the class load, which is loaded from the dll at program load. It only crashes when the program makes a call into the class in my dll to show a window, upon which I then load a juce window, and it crashes.