Keyboard key handling |
.3lite
|
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.
|
|||||||||||
|
Naith
|
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?
|
|||||||||||
|
Naith
|
And if it's not a game: how's the application supposed to work?
|
|||||||||||
|
.3lite
|
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.
|
|||||||||||
|
.3lite
|
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.
|
|||||||||||
|
AntTheAlchemist
|
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. |
|||||||||||
|
Keyboard key handling |
Juanma BC
Guest
|
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 |
|||||||||||
|
.3lite
|
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.
|
|||||||||||
|
.3lite
|
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. |
|||||||||||
|