|
|
Bob Pendleton wrote:
> I now see how you got to the magic keypad bit. But, I don't think it is
> the correct solution because, as I understand it,
>
> SDL_GetLayoutKey(SDLK_1) == code point for 1
>
> and
>
> SDL_GetLayoutKey(SDLK_KP_1) == code point for 1 | magic key pad bit.
>
> But, there is no good way for a developer to test for 1 | magic key pad
> bit. There is no enumeration of these values and it forces the
> programmer to create them and know what they are. Adding that bit means
> that SDL_GetLayoutKey really returns 3 different types of value, SDLK_*,
> Unicode code points, and something that is not a code point nor an
> SDLK_*.
Hmm, you're right. In that case I was wrong about SDL_KEY_KEYPAD_BIT
"not being intended" for the library user. But do you see a better
solution than just making that constant an official part of the API and
having developers specify
'1' | SDL_KEY_KEYPAD_BIT
in that situation (maybe #define SDL_KEYPAD_KEY(n) ((n) |
SDL_KEY_KEYPAD_BIT) )?
Come to think of it, is this even a common situation? Testing against
hardcoded layout key codes seems like a bad idea to me, because the
user's keyboard layout likely doesn't have these keys. If you're using
layout key codes, you should make them user-configurable (i.e. you store
a value coming out of SDL_GetLayoutKey() at one point and test against
that stored value later, the value is never explicitly specified in
source code).
-Christian
_______________________________________________
SDL mailing list
SDL@xxxxxxxxxxxxxxxx
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
|
|