I’ve posted about this before in the main forum, but I learned some more and this is a Windows -only topic.
If you have a window with a native titlebar, then this is OK:
-click on the titlebar
-press alt-spacebar
-system menu is shown correctly
This doesn’t work:
-click somewhere in the content component
-press alt-spacebar
-system menu doesn’t show up
I did some debugging and I noticed that in both cases, the window is still receiving WM_SYSCOMMAND. So I’m wondering - is the menu showing up in the second case, but isn’t being painted properly because the z-order is different?
no, the menu’s not appearing, though I can’t figure out why - none of the windows messages that could interfere with it are getting overridden. I’m a bit stumped on that one, actually.
Thanks; I just applied my usual technique of poking randomly at it until I learned something. : )
However, the fix I posted broke the demo; if you had the demo in native title bar mode and clicked the close button, my change caused the app to try and shut down twice. First you get the WM_SYSCOMMAND with SC_CLOSE, which causes the window to close, followed by WM_CLOSE, which tries to close the window again.
This results in the JUCE shutdown code running twice, which toggles a jassert.
So I changed it to this:
[code] case WM_SYSCOMMAND :
if ((styleFlags & windowHasTitleBar) != 0)
{
switch (wParam & 0xfff0)
{
case SC_CLOSE :
PostMessage(h,WM_CLOSE,0,0);
return 0;
case SC_KEYMENU :
if (h == GetCapture())
ReleaseCapture();
break;
}
}
break;
[/code]
This doesn’t pass the SC_CLOSE to DefWindowProc, which prevents the double WM_CLOSE message. It seems to handle all the cases - pressing alt-F4, double clicking the system menu icon, using the system menu, or pressing the close button.