SDL_EnableKeyRepeat and mod keys

Hello,

I’m writing a program that has a text editor within it. I want to support unicode. I have SDL_EnableUNICODE() set.

If you open up your favourite text editor you should be able to hold a key, then press shift, then release it and then release your key to give the following result:

Code:
llllllllllllllllllllllLLLLLLLLLLLLLLLLLLLLLlllllllllllllllllllllllllllllllll

This doesn’t seem possible in SDL.

Using SDL_EnableKeyRepeat doesn’t take account of the changes to the mod keys (i.e. shift) and so doesn’t update the value of keysym.unicode.

Before discovering SDL_EnableKeyRepeat I had written my own delay and repeat routine. It stored the last keydown and with some timers checked the values from SDL_GetKeyState().

SDL_GetKeyState(), however, only tells you if a key is pressed.

What I need is a way to take the keysym.sym value and convert it to its unicode value based upon the values from SDL_GetModState().

But there doesn’t seem to be a function available in SDL to generate the unicode value manually.

SDL is obviously capable of doing this internalaly as it does it when it creates SDL_Event’s with SDL_PollEvent().

Ideally I would want SDL_KeyboardEvent available on a SDL_KEYPRESS event (I know the type doesn’t exist).

Or a way for me to force a refresh of the SDL_KeyboardEvent generated by SDL_EnableKeyRepeat.

Or just simply some function that takes the keysym.sym and mod keys and spits out the unicode value.

Thanks

Actually the correct behavior is to stop repeating the ‘l’ as soon as
shift (or any other key) is pressed. Every text editor that I have
tried has that correct behavior. If you know a text editor that
produces the above output, that’s probably a bug in that editor.On 2/4/2011 04:07, richyelbag wrote:

If you open up your favourite text editor you should be able to hold
a key, then press shift, then release it and then release your key to
give the following result:

Code:
llllllllllllllllllllllLLLLLLLLLLLLLLLLLLLLLlllllllllllllllllllllllllllllllll


Rainer Deyke - rainerd at eldwood.com

It’s platform dependant, apparently. On my X11/Linux system, all applications
(KDE and others - completely different GUI toolkits) behave like the above;
shift does NOT stop the key repeat. On systems that still use the keyboard
hardware repeat, I suppose the behavior would depend on the keyboard rather
than any part of the software…

I can’t remember dealing with any OS where applications normally implement key
repeat. However, SDL DOES implement key repeat…! IIRC, this is to avoid
problems with the native repeat on some platforms.

As to what is correct behavior, I don’t know if there is one. I guess it’s one
of those things where whatever you’re not used to seems wrong. :-DOn Saturday 05 February 2011, at 11.53.44, Rainer Deyke wrote:

On 2/4/2011 04:07, richyelbag wrote:

If you open up your favourite text editor you should be able to hold
a key, then press shift, then release it and then release your key to
give the following result:

Code:
llllllllllllllllllllllLLLLLLLLLLLLLLLLLLLLLllllllllllllllllllllllllllllll
lll

Actually the correct behavior is to stop repeating the ‘l’ as soon as
shift (or any other key) is pressed. Every text editor that I have
tried has that correct behavior. If you know a text editor that
produces the above output, that’s probably a bug in that editor.


//David Olofson - Consultant, Developer, Artist, Open Source Advocate

.— Games, examples, libraries, scripting, sound, music, graphics —.
| http://consulting.olofson.net http://olofsonarcade.com |
’---------------------------------------------------------------------’

Cheers for the responses.

tbh, I never thought to test the behaviour in Windows. It seems more natural to me that the shift shouldn’t stop the input but as Rainer points out it’s one of those “what you’re used to” things.

As SDL is platform independent I guess lowest common denominator wins. :slight_smile:

I was thinking of using a separate unicode library to translate the keysyms and do away with the sdl implementation but I think that would involve unnecessary effort.

If you’re using SDL 1.3, the unicode member of the key event is deprecated
and you should be using the SDL_TEXTINPUT event which gives you text as the
OS interprets it.

FYI, the behavior you describe isn’t necessarily universal. On my Mac, for
example, if I press shift while holding down a letter, the repeat stops. :slight_smile:

See ya!On Fri, Feb 4, 2011 at 3:07 AM, richyelbag <richard.simkins at gmail.com>wrote:

Hello,

I’m writing a program that has a text editor within it. I want to support
unicode. I have SDL_EnableUNICODE() set.

If you open up your favourite text editor you should be able to hold a key,
then press shift, then release it and then release your key to give the
following result:

Code:

llllllllllllllllllllllLLLLLLLLLLLLLLLLLLLLLlllllllllllllllllllllllllllllllll

This doesn’t seem possible in SDL.

Using SDL_EnableKeyRepeat doesn’t take account of the changes to the mod
keys (i.e. shift) and so doesn’t update the value of keysym.unicode.

Before discovering SDL_EnableKeyRepeat I had written my own delay and
repeat routine. It stored the last keydown and with some timers checked the
values from SDL_GetKeyState().

SDL_GetKeyState(), however, only tells you if a key is pressed.

What I need is a way to take the keysym.sym value and convert it to its
unicode value based upon the values from SDL_GetModState().

But there doesn’t seem to be a function available in SDL to generate the
unicode value manually.

SDL is obviously capable of doing this internalaly as it does it when it
creates SDL_Event’s with SDL_PollEvent().

Ideally I would want SDL_KeyboardEvent available on a SDL_KEYPRESS event (I
know the type doesn’t exist).

Or a way for me to force a refresh of the SDL_KeyboardEvent generated by
SDL_EnableKeyRepeat.

Or just simply some function that takes the keysym.sym and mod keys and
spits out the unicode value.

Thanks


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


-Sam Lantinga, Founder and CEO, Galaxy Gameworks