I have a problem with the WM_KEYUP message not being sent. I've had this problem ever since the first NeHe tutorials that I did when I first started out. I have had this problem across many different input management scheme's, so I don't think its my code that is directly responsible for this, but here it is anyway:

case WM_KEYDOWN:
if (win_active)
for (list<KeyInput>::iterator t = key_inputs.begin(); t != key_inputs.end(); ++t)
(*t).PushKeyDown(ConvertKeyCode(wparam));
return 0;
case WM_KEYUP:
if (win_active)
for (list<KeyInput>::iterator t = key_inputs.begin(); t != key_inputs.end(); ++t)
(*t).PushKeyUp(ConvertKeyCode(wparam));
return 0;


What happens is every so often, a key is pressed down, the keydown message is sent. But when the key is released the keyup message is not sent and my program thinks the key has not been released. the only way to fix this is to press the key again to "unstick" the key. Does anyone know a way to fix this problem?

This may very well be a hardware problem. Lots of keyboards are cheaply wired and do actually not allow more complicated key combos to be noticed simultaneously. For example cursor up, cursor left and space pressed all at once will often exhibit this behaviour. There is nothing you can do about it beside getting another keyboard.

is the program no longer the active program when this occurs?( in my input scheme, also using windows api, this problem manifests because the user clicked off the window, and released the key, than clicked back to my window, the only solution i know of is to take a more proactive solution, and not wait for windows to send the keyboard change message(which it won't in this instance since another program terminated the message before it reached your application.), and instead directly query the keyboard state. but i don't recommend doing that.

a few things you can do:

1) clear input when the window goes inactive or loses focus, (You should only recieve keydown and keyup events if your window has keyboard focus)
2) Ignore the problem, if a key gets "stuck" the user can just press it again.

3) Post your complete message handling code so we can see if you're doing something wierd.