Case sensitive key down?

Andre_Stein · May 21, 2004, 10:20am

Hi all,

I am wondering whether it's possible with SDL to get the "real"

character pressed during a keydown event… It seems like SDL doesn’t
make a difference between e.g. a and A and translates it to the same
virtual key code. If you’d like to implement a textfield to type for
example the user’s username - case senitive - the solution to go for is
to handle the shift event and so toggle the next character. But this
workaround wouldn’t care about special chars especially on international
keyboards.

So in other terms is there a nice & beautiful solution how to use SDL
key down events to get the real pressed char like in any Qt/Win32 textfield?

Thanks in forward for any help!
Regards,
-Andr?.–
http://www.steinsoft.net
cout << “Happy Coding!” << endl;

Matt_Wilson · May 21, 2004, 10:31am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andr? Stein wrote:
| Hi all,
|
| I am wondering whether it’s possible with SDL to get the “real”
| character pressed during a keydown event… It seems like SDL doesn’t
| make a difference between e.g. a and A and translates it to the same
| virtual key code. If you’d like to implement a textfield to type for
| example the user’s username - case senitive - the solution to go for is
| to handle the shift event and so toggle the next character. But this
| workaround wouldn’t care about special chars especially on international
| keyboards.
|
| So in other terms is there a nice & beautiful solution how to use SDL
| key down events to get the real pressed char like in any Qt/Win32
| textfield?

If ‘a’ is pressed then the key event is ‘a’, but in the case of an 'A’
the ‘shift’ key event is also pressed (along with the ‘a’ key event).
These are keycodes, not keys. You could easily write a macro or function
to do it;

#define SDL_IS_CAPS(keys) ( keys [ SDLK_RSHIFT ] ||
~ keys [ SDLK_LSHIFT ] ||
~ keys [ SDLK_CAPSLOCK ] )

then incorporate that into some other macro to perform translations (or
something). ie.

#define SDL_GET_ALPHA(alpha,keys) ( SDL_IS_CAPS ( keys ) ?
~ toupper ( alpha ) :
~ alpha )

SDL_GET_ALPHA ( ‘a’, keys ) or something like that (not ideal, just an
idea).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFArdptms1059AAPcwRAqPDAKCUxrSFH4eBryv11aKrKtHxoj5n+gCdEjdY
E+8rmsp6x16sg3Chauyqn20=
=Ax2J
-----END PGP SIGNATURE-----

David_Olofson · May 21, 2004, 10:43am

Forget about scan codes, qualifier keys and stuff. You’ll just get a
headache and a non-portable and/or missbehaved application.

In your initialization:

SDL_EnableUNICODE(1);

and then when you get a keyboard event: (From ‘man SDL_keysym’)

if(!(event.key.keysym.unicode & 0xff80))
	ascii = event.key.keysym.unicode;
else
	<deal with international characters>;

This method actually works, even with weird keyboard layouts like my
custom swedish Dvorak variant.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Friday 21 May 2004 12.20, Andr? Stein wrote:

Hi all,

I am wondering whether it’s possible with SDL to get the "real"
character pressed during a keydown event… It seems like SDL
doesn’t make a difference between e.g. a and A and translates it to
the same virtual key code. If you’d like to implement a textfield
to type for example the user’s username - case senitive - the
solution to go for is to handle the shift event and so toggle the
next character. But this workaround wouldn’t care about special
chars especially on international keyboards.

So in other terms is there a nice & beautiful solution how to use
SDL key down events to get the real pressed char like in any
Qt/Win32 textfield?

Andre_Stein · May 21, 2004, 10:47am

Hi David,

Forget about scan codes, qualifier keys and stuff. You’ll just get a
headache and a non-portable and/or missbehaved application.

In your initialization:

SDL_EnableUNICODE(1);

and then when you get a keyboard event: (From ‘man SDL_keysym’)

if(!(event.key.keysym.unicode & 0xff80))
ascii = event.key.keysym.unicode;
else
;

This method actually works, even with weird keyboard layouts like my
custom swedish Dvorak variant.

Actually those are the people I'd like to help ;-) Thanks for your

quick answer ; I’ll try this method as soon as possible to get finally
my swiss-french keyboard working.

Regards,
-Andr?.–
http://www.steinsoft.net
cout << “Happy Coding!” << endl;

Michael_Rickert · May 21, 2004, 10:49am

The keysyms are meant more for use in game controls
IMHO… for text, I enable unicode (which allows for
international input as well) and use that to read my
text, as it directly differentiates between ‘a’ and
’A’ rather than simply telling you what key was
pressed. The ‘unicode’ property of the SDL_keysym
structure is a ‘Uint16’ FYI.

— Andr?_Stein wrote:> Hi all,

I am wondering whether it’s possible with SDL to
get the "real"
character pressed during a keydown event… It seems
like SDL doesn’t
make a difference between e.g. a and A and
translates it to the same
virtual key code. If you’d like to implement a
textfield to type for
example the user’s username - case senitive - the
solution to go for is
to handle the shift event and so toggle the next
character. But this
workaround wouldn’t care about special chars
especially on international
keyboards.

So in other terms is there a nice & beautiful
solution how to use SDL
key down events to get the real pressed char like in
any Qt/Win32 textfield?

Thanks in forward for any help!
Regards,
-Andr?.

–
http://www.steinsoft.net
cout << “Happy Coding!” << endl;

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Do you Yahoo!?
Yahoo! Domains ? Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer

David_White · May 22, 2004, 4:04am

Forget about scan codes, qualifier keys and stuff. You’ll just get a
headache and a non-portable and/or missbehaved application.

In your initialization:

SDL_EnableUNICODE(1);

and then when you get a keyboard event: (From ‘man SDL_keysym’)

if(!(event.key.keysym.unicode & 0xff80))
ascii = event.key.keysym.unicode;
else
;

This method actually works, even with weird keyboard layouts like my
custom swedish Dvorak variant.

Except that it seems that, at least on Win32, there is a problem that SDL
will take the shift-state at the time that the key event is processed,
rather than what it was when the key was pressed.

David White
Lead Developer
Battle for Wesnoth (http://www.wesnoth.org)

Michael_Rickert · May 22, 2004, 4:45am

— David White wrote:

Forget about scan codes, qualifier keys and stuff.
You’ll just get a
headache and a non-portable and/or missbehaved
application.

In your initialization:

SDL_EnableUNICODE(1);

and then when you get a keyboard event: (From ‘man
SDL_keysym’)

if(!(event.key.keysym.unicode & 0xff80))
ascii = event.key.keysym.unicode;
else
;

This method actually works, even with weird
keyboard layouts like my
custom swedish Dvorak variant.

Except that it seems that, at least on Win32, there
is a problem that SDL
will take the shift-state at the time that the key
event is processed,
rather than what it was when the key was pressed.

This would occur with the non unicode version too I
believe? If not (or even if it does) I think this
would be classified as a bug, the unicode letter state
should be dependant on shift state at keypress.> David White

Lead Developer
Battle for Wesnoth (http://www.wesnoth.org)

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Do you Yahoo!?
Yahoo! Domains ? Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer

David_White · May 23, 2004, 7:11am

Except that it seems that, at least on Win32, there
is a problem that SDL
will take the shift-state at the time that the key
event is processed,
rather than what it was when the key was pressed.

This would occur with the non unicode version too I
believe? If not (or even if it does) I think this
would be classified as a bug, the unicode letter state
should be dependant on shift state at keypress.

I don’t know whether it happens with the non-unicode version, but yes I
think it is a bug.

The thing is, it’s a much bigger problem with the unicode version, because
you can’t just track the shift state yourself and call toupper/tolower so
easily.

David White
Lead Developer
Battle for Wesnoth (http://www.wesnoth.org)

slouken · May 23, 2004, 10:02pm

Except that it seems that, at least on Win32, there
is a problem that SDL
will take the shift-state at the time that the key
event is processed,
rather than what it was when the key was pressed.

This would occur with the non unicode version too I
believe? If not (or even if it does) I think this
would be classified as a bug, the unicode letter state
should be dependant on shift state at keypress.

I don’t know whether it happens with the non-unicode version, but yes I
think it is a bug.

The thing is, it’s a much bigger problem with the unicode version, because
you can’t just track the shift state yourself and call toupper/tolower so
easily.

You really shouldn’t do any processing of the shift state with respect
to the key presses, aside from checking control combinations. Not only
is the modifier state only correct for the time the event is processed,
but you won’t correctly handle international keyboard input. If you are
expecting text input, you should always enable unicode and look at that
field in the key down event.

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

David_White · May 24, 2004, 2:55am

Except that it seems that, at least on Win32, there
is a problem that SDL
will take the shift-state at the time that the key
event is processed,
rather than what it was when the key was pressed.

This would occur with the non unicode version too I
believe? If not (or even if it does) I think this
would be classified as a bug, the unicode letter state
should be dependant on shift state at keypress.

I don’t know whether it happens with the non-unicode version, but yes I
think it is a bug.

The thing is, it’s a much bigger problem with the unicode version,
because

you can’t just track the shift state yourself and call toupper/tolower
so

easily.

You really shouldn’t do any processing of the shift state with respect
to the key presses, aside from checking control combinations. Not only
is the modifier state only correct for the time the event is processed,
but you won’t correctly handle international keyboard input. If you are
expecting text input, you should always enable unicode and look at that
field in the key down event.

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

I agree I shouldn’t (have to) do any processing of the shift state, and just
look at the ‘unicode’ field, but as far as I can see there is a problem in
the way key events occur, at least on Windows, that causes them to report
the unicode character value with key modifiers at the time the event is
processed, not the time it occurs. See
http://twomix.devolution.com/pipermail/sdl/2004-May/062159.html for my
report of this apparent bug. I received only one reply, which recommended
that I track shift state myself.

David White
Lead Developer
Battle for Wesnoth (http://www.wesnoth.org)

Florian_Hufsky · June 6, 2004, 10:50am

this should be posted in a faq or something.
this question comes up far too often and the solution is so damn easy.

David Olofson wrote:>On Friday 21 May 2004 12.20, Andr? Stein wrote:

Hi all,

I am wondering whether it’s possible with SDL to get the "real"
character pressed during a keydown event… It seems like SDL
doesn’t make a difference between e.g. a and A and translates it to
the same virtual key code. If you’d like to implement a textfield
to type for example the user’s username - case senitive - the
solution to go for is to handle the shift event and so toggle the
next character. But this workaround wouldn’t care about special
chars especially on international keyboards.

So in other terms is there a nice & beautiful solution how to use
SDL key down events to get the real pressed char like in any
Qt/Win32 textfield?

Forget about scan codes, qualifier keys and stuff. You’ll just get a
headache and a non-portable and/or missbehaved application.

In your initialization:

SDL_EnableUNICODE(1);

and then when you get a keyboard event: (From ‘man SDL_keysym’)

if(!(event.key.keysym.unicode & 0xff80))
ascii = event.key.keysym.unicode;
else
;

This method actually works, even with weird keyboard layouts like my
custom swedish Dvorak variant.

//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl