Steve,
I have an application that catches SDL key events.
I was relying on the unicode character to
be filled in for both keypress and key release events. According to
the SDL docs, the key release is not guaranteed to fill in the unicode
character.
What platform are you working on?
Linux (X11), for the foreseeable future. Eventually Windows in addition. Maybe.
How can I get that information back?
If you want to make SDL to return a valid unicode value on SDL_KEYUP
events, you need to modify platform dependent parts of SDL. If you
make your app. platform neutral, you need to modify OS interface parts
for all platforms, that I don’t think is easy.
If you just need one particular platform, the difficulty to do so
seems vary on your platform.
If you are working on X11 (I guess so, since you wrote “key release
event” that is the X11 terminology, as opposed to key up that is SDL
terminology…), I might say it is impossible, since under X11/Xlib
the ability to return a meaningful character code on KeyRelease is
mutually exclusive with the ability to support non Latin-1 characters.
Why? I’ve heard that before, and find it very believable, but I
haven’t used accented characters since back when you had to hold down
ALT and press the numeric code on the keypad. So I don’t even know how
to type them today.
But I don’t need SDL to give me a unicode value on key release. I
already have to have a key event handling layer above SDL, so all I’m
really looking for is a reasonable algorithm, preferably one that
matches what Everyone Else ™ is doing.
In particular, I want to handle
shifted keys and control keys. So I can’t use the scancode or the SDL
key sym, because neither of those take the modifiers into account.
I’m just curious; if a user pressed A key, pressed Shift key, then
released A key, what unicode value does your application expect? 0x41
(for upper case A) or 0x61 (for lower case A)?
Either one would be fine by me. But I would prefer shift-down, A-down,
shift-up, A-up to produce “A” (not “a”) on the A-up event. Which I
think means that I would answer 0x61 to your question, to be
consistent – I think I want up events to give me back the same code
that was emitted during the down event. (Which implies I should just
keep a mapping from <scancode,modifiers> -> unicode, and use the down
event modifiers when looking up the up event’s scancode. I guess.)
If a user operated the keyboard as follows, what unicode value for the
last KEYUP for B key?
Pressed A
Pressed Shift
Pressed B
Pressed Ctrl
Released A
Released Shift
Released B
By the logic above, which I still agree with for this sequence, I’d
want an uppercase B.
Well, you wrote your app. worked with SDL 1.2.7. I could test it
by myself on SDL 1.2.7…
Oh! Thanks for the offer, but I’m really just looking for offhand
advice, not some deep bugfix or whatever. I don’t have any reason to
believe that SDL is doing anything wrong; I’m just trying to figure
out what the right way of using what it’s producing.
My app accepts some basic keyboard controls, where the controls are
different for control characters and regular characters. (And very
occasionally, shifted characters.) The user can specify key mappings
with strings like “f”, “F”, and “\C-f”. I’d like to use a common
wchar_t underneath, so I’d convert “\C-f” to the same wchar_t that a
key release on the ‘F’ key produces when the Ctrl key was down during
the F-down event. (Sometimes the user will want the trigger to be on
the down event, sometimes on the up; that specification is done
separately from the “\C-f” description.)On 6/13/07, alissa_sabre at yahoo.co.jp <alissa_sabre at yahoo.co.jp> wrote: