Nervous about keyboard state usage

I get nervous when I see event handling code that that checks the state
of keys. It is such a common error to check the current key state (or
mouse position, …) and get a result that is different from the state
when the handled event actually happened. (Not even KDE gets it right,
[http://bugs.kde.org/show_bug.cgi?id=151355].)

Therefore I wonder whether the following error might happen in an SDL
application:

  1. ‘X’ key is pressed.
  2. Control is pressed.
  3. Application calls SDL_PollEvent, which calls SDL_PumpEvents. It sets
    the state of the ‘X’ key to DOWN and the state of Control key to DOWN.
    Then it returns the ‘X’ key press event to Application.
  4. Application handles the ‘X’ key press event and the handler checks
    the state of the Control key. SDL says it is DOWN, because that is the
    current state. But it was not down when the handled event occurred, so
    the result will be erroneous.

The event systems gives you the history of key presses and releases while
the state checking functions give you the current state. They can not be
mixed because the concept of time used by the two mechanisms is completely
different.The events may be very old by the time you processes them while
the status functions give you state of the keys as they are right now. If
you want to see if control and X are both pressed right now use the status
functions to test the current state of both keys. If you want to see the
history of presses and releases then use the event functions.

Bob PendletonOn 3/16/08, Erik wrote:

I get nervous when I see event handling code that that checks the state
of keys. It is such a common error to check the current key state (or
mouse position, …) and get a result that is different from the state
when the handled event actually happened. (Not even KDE gets it right,
[http://bugs.kde.org/show_bug.cgi?id=151355].)

Therefore I wonder whether the following error might happen in an SDL
application:

  1. ‘X’ key is pressed.
  2. Control is pressed.
  3. Application calls SDL_PollEvent, which calls SDL_PumpEvents. It sets
    the state of the ‘X’ key to DOWN and the state of Control key to DOWN.
    Then it returns the ‘X’ key press event to Application.
  4. Application handles the ‘X’ key press event and the handler checks
    the state of the Control key. SDL says it is DOWN, because that is the
    current state. But it was not down when the handled event occurred, so
    the result will be erroneous.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

±-------------------------------------+

The event systems gives you the history of key presses and releases while
the state checking functions give you the current state. They can not be
mixed because the concept of time used by the two mechanisms is completely
different.The events may be very old by the time you processes them while
the status functions give you state of the keys as they are right now. If
you want to see if control and X are both pressed right now use the status
functions to test the current state of both keys. If you want to see the
history of presses and releases then use the event functions.

This is also why key events have the modifier state at the time of the
keypress, since it might be different than the current state.

See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment

Sam Lantinga skrev:

The event systems gives you the history of key presses and releases while
the state checking functions give you the current state. They can not be
mixed because the concept of time used by the two mechanisms is completely
different.The events may be very old by the time you processes them while
the status functions give you state of the keys as they are right now. If
you want to see if control and X are both pressed right now use the status
functions to test the current state of both keys. If you want to see the
history of presses and releases then use the event functions.

This is also why key events have the modifier state at the time of the
keypress, since it might be different than the current state.
That is what I had hoped for. I have now fixed all keyboard event
handlers in our project. But unfortunately I was unable to find the
modifier key state in mouse events in SDL 1.2.13. SDL_event is just a
discriminated union with “Uint8 type” as the discriminator and a
SDL_MouseButtonEvent in case it is a mouse button event. And
SDL_MouseButtonEvent only has these members:
Uint8 type; /* SDL_MOUSEBUTTONDOWN or SDL_MOUSEBUTTONUP /
Uint8 which; /
The mouse device index /
Uint8 button; /
The mouse button index /
Uint8 state; /
SDL_PRESSED or SDL_RELEASED /
Uint16 x, y; /
The X/Y coordinates of the mouse at press time */

I do not see anything there that could contain the state of the Ctrl and
Shift keys.

That is what I had hoped for. I have now fixed all keyboard event
handlers in our project. But unfortunately I was unable to find the
modifier key state in mouse events in SDL 1.2.13.

Wow, you’re right. That’s a huge oversight. I’ll add that to the SDL 1.3 API.

Thanks!
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment