The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Hello

I have a code which repeats keys on it's on even despite multiple events of key repetition occurring from the SDL2 itself. The reason for that is because I would like to control repetition time on my own. This creates certain issues like when should I release all keys when no SDL_KEYUP is dispatched to indicate that the key was released. Few users of my application reported an issue with given key not being released even when the key is not held anymore, but it's so rare that I'm unable to replicate it, and they have no idea under what circumstances it happens.

I'm currently using following code to work with keyboard:



onKeyDown:
- If the key is not pressed then it marks it as pressed and an internal event looping through all states will repeat this key until it's released (onKeyUp)
- If key is pressed then the function call is ignored.

onKeyUp:
- If the key is pressed then it marks it as not pressed and an internal event looping through all states will no longer repeat this key.
- If key the is not pressed then the function call is ignored.

Does anyone know whether I should release all keys under any other SDL2 events? Perhaps I'm missing something?

I would like to bring this thread up since perhaps someone has an idea of under what other events I should release all keys or just specific ones.

I would like to help you but I really don't understand what you're trying do/how it's supposed to work. Do you mind explain a bit more how the key handling is supposed to work and how the game is played?

And if it's not a game: how's the application supposed to work?

Thank you for your post. I'm not really sure what I should explain more. Well, the long story short is that I'm handling key repetition on my own and I do need to know when (under what kind of SDL events from the window) to release keys if no SDL_KEYUP event is dispatched because otherwise the key will be repeated forever.

Lets give an example - you are holding arrow key when you switch the window to another one (alt + tab) and release the key there. If all keys wouldn't be released on lost focus event (like it is in my example) then the key would still be repeating itself because no SDL_KEYUP event would be dispatched to my window to indicate that the key is no longer being hold.

Missing key-up events is an age-old hardware issue. I'm afraid you'll have to live with it. On some physical keyboards, depressing multiple keys before releasing them causes the hardware to forget which keys are pressed. There's no software solution.

Why do you need a custom repeat rate? The user has set their desired repeat rate in the settings of their chosen operating system. Changing this behavior will upset some users.

Your real issue is the track of off focus events, custom repeat or not. I think there is some off focus input tracking in mouses, then perhaps for keyboards. Anyone using that? Like for a joystick to keboard input mapper system service.
Windowed Apps input is usually intentionally on focus, unless stated, desired, and carefully controlled, because else switching between windowed apps and interacting would be missinterpreted by the rest of the windows.
What About: When you lose focus, reset the pressed keys mapping to unpressed, and if applicable pause the app.That events are well known.
jmbc

Thank you for your posts. It came to my mind that I can always check SDL_GetKeyboardState to see whether the key is still down, however, is it even possible for a key not be pressed according to the data from that function and no SDL_KEYUP being dispatched? It wouldn't add much overhead since I did read that memory location returned by SDL_GetKeyboardState is updated by SDL_PumpEvents anyway.

By looking at the sources that's not going to help. Events are based on the values changed in SDL_keyboard.keystate so either way it won't help since it's the same. Also, once the keyboard loses focus an event of SDL_WINDOWEVENT_FOCUS_LOST is dispatched so according to my post (releaseAllKeys()) that should be covered, too.

I guess people will have to live with that, it looks to me like a hardware or OS issue.