Doing some windows API / opengl related stuff and a problem I've run into is the window freezes if ALT or F10 are pressed (on the key up event). It unfreezes if the window receives any input (even from alt/f10).
It also appears that a small amount of time has passed (1 second or so) even if it is frozen for 10seconds.
Why is it doing this and how can I fix it?
I've tried:
case WM_KEYUP:
{
switch (a_wParam)
{
case VK_F10:
{
return DefWindowProc(a_hHandle, 0, 0, 0);
break;
}
default:
{
break;
}
}
break;
}
Inside my WindowProc function, but the keyup event only triggers if the pressed key is not ALT or F10
EDIT: After some research I found the problem is related to how I create my window. Using the "WS_SYSMENU" style allows a menu or something and when I press alt or F10 with that style enabled the window tries to open that menu I believe. Disabling it will solved the problem, but it will also remove my exit, maximise and minimise buttons. How can I solve the problem without removing the "WS_SYSMENU" style.
I've been having this exact same problem, but couldn't figure out what the cause was. Your findings make perfect sense. Thanks for the info!
Update:
After trying a few things, I discovered two ways to solve it. The first is to disable WS_SYSMENU. I'm actually using SlimDX & C#, so I simply created a new descendant class of RenderForm and put in an override for the CreateParams function, like so:
protected override CreateParams CreateParams
{
get
{
CreateParams createParams = base.CreateParams;
createParams.Style &= ~WS_SYSMENU;
return createParams;
}
}
Unfortunately, this also removed the "X" button in the top right of the window, which I want to keep, so this technique wouldn't cut it for me.
I then discovered another technique, which is to override the ProcessDialogKey() function and tell the form to ignore the Alt and F10 keys. The code ended up as follows:
protected override bool ProcessDialogKey(Keys keyData)
{
if ((keyData & Keys.Alt) == Keys.Alt || (keyData & Keys.F10) == Keys.F10)
{
return true;
}
else
{
return base.ProcessDialogKey(keyData);
}
}
I did a quick test, and I'm able to capture the F10 key for my own purposes through my normal key handler and it doesn't trigger the menu "freeze".
[size="2"]Currently working on an open world survival RPG - For info check out my Development blog:[size="2"] ByteWrangler
I discovered that the second solution I gave above also disables ALT-F4, which isn't ideal, so I modified the code to allow that combination. For those who are interested, the final code is:
To do the same in C++ handle WM_SYSKEYDOWN in your window-proc.
switch(msg) {
case WM_SYSKEYDOWN:
if(wParam == VK_F10 || wParam == VK_MENU)
return 0;
else
return DefWindowProc(...);
}