Requesting addition to HWNDComponentPeer


#1

I am hosting Juce windows in some plugin code(*) inside a win32 application and its window hierarchy. (Using Component::addToDesktop etc) I was puzzled by a long time how to avoid getting some problems when the application is shut down with the Juce windows still visible.

I was finally able to come up with a fix that apparently works by altering HWNDComponentPeer’s code in the peerWindowProc method by adding a WM_DESTROY handler :

case WM_DESTROY:
			getComponent().removeFromDesktop();
			break;

Does this seem like a change that could be part of the official JUCE source? If not, is there some other way how to deal with this situation, namely the host application/Windows destroying JUCE windows which have had addToDesktop called on them?

(*) Reaper extension plugins, which are not VST or similar plugins, but another plugin type entirely.


#2

Interesting… though I’d be pretty cautious about adding that for use by all apps as I wouldn’t feel confident that it wouldn’t break something in someone’s unusual edge-case code.


#3

Maybe it could be put inside an #ifdef block?


#4

Hmm… but what would the #ifdef be called? What is this actually trying to do?


#5

JUCE_HANDLE_COMPONENT_PEER_DESTRUCTION_BY_WINDOWS or something like that?


#6

Doesn’t it get into a loop though? Calling removeFromDesktop will try to delete the peer, which will destroy the window, which should send wm_destroy again…? Have you stepped through what it does?

Also, at a minimum I’d have thought it should “return 0” to get out of the function as soon as the removeFromDesktop() has returned, because otherwise the method will be inside a dangling pointer to the peer…


#7

This stuff happens for me when the process is shutting down, so maybe that prevents any infinite loops from happening. I am not getting any problems when running a debug build under the debugger, so I think it all goes fine.

Of course now that I thought about it further, this probably only helps in this particular situation where the peer and the associated component are no longer needed at all. I guess it wouldn’t help if some code calls DestroyWindow or something but the host process isn’t quit right after that…


#8

FYI I’ve added something to do this now - thought it was worth having something in there, if just to be a placeholder in case anyone hits something similar in the future. Let me know if it does the trick for you.


#9

Yeah this seems to work, thanks!