Back in 1.1.3 or whenever it was no unicodes would be generated on
SDL_KEYUP, and I thought
this was fixed in 1.1.6 because it now works correctly under windows 95,
but still under NT
event.key.keysym.unicode is always 0
Can this be fixed? unicode conversion is only useful if done on both
KEYDOWN and KEYUP, because
otherwise there is no way to track which key was released in the context
of simultanuous keypresses.
Oh, and a minor issue: the SDL_RegisterApp prototype in SDL_main.h is
missing a C_LINKAGE
Back in 1.1.3 or whenever it was no unicodes would be generated on
SDL_KEYUP, and I thought
this was fixed in 1.1.6 because it now works correctly under windows 95,
but still under NT
event.key.keysym.unicode is always 0
Can this be fixed? unicode conversion is only useful if done on both
KEYDOWN and KEYUP, because
otherwise there is no way to track which key was released in the context
of simultanuous keypresses.
yes, i was trying to help figure this one out. i prematurely
assumed it was an SDL_RegisterApp issue. turns out that wasn’t
it, but that WinNT never translates the unicode value on KEY_UPs.
should be an easy patch. i can submit it in if someone decides
that, ‘yes, KEY_UP on winnt should also translate the unicode’
Oh, and a minor issue: the SDL_RegisterApp prototype in SDL_main.h is
missing a C_LINKAGE
heh, this one threw us for a loop. the program was using C++. we
tried not using SDLmain.lib and properly handling things for
ourselves. sadly we could not link until we had fixed the prototype
for SDL_RegisterApp.
should be an easy one to take care of. i couldn’t think of any
reasons why SDL_RegisterApp shouldn’t include C_LINKAGE ?
Back in 1.1.3 or whenever it was no unicodes would be generated on
SDL_KEYUP, and I thought
this was fixed in 1.1.6 because it now works correctly under windows 95,
but still under NT
event.key.keysym.unicode is always 0
Unicode for key release events make no sense. Unicode values are produced
by a sequence of key presses (compose handling, dead accent keys, modifiers).
Consider the following simple sequence:
key press event: shift key
key press event: ‘4’ key
key release event: ‘4’ key
key release event: shift key
On a US-localised keyboard, event 2 produces the Unicode value ‘$’.
None of the other events have any reasonable Unicode values.
Can this be fixed? unicode conversion is only useful if done on both
KEYDOWN and KEYUP, because
otherwise there is no way to track which key was released in the context
of simultanuous keypresses.
I think the keysym value is there for exactly that
On a US-localised keyboard, event 2 produces the Unicode value ‘$’.
None of the other events have any reasonable Unicode values.
I don’t see why #3 can’t give me ‘$’ again.
I think the keysym value is there for exactly that
So I need to use the keysym to figure out which unicode this is the
release of, using some kind of lookup mechanism? That kinda defeats
the purpose of using unicodes in the first place. Don’t assume that
everyone that uses unicodes is only ever listening to KEYDOWN.
Besides that, KEYUP does give me unicodes on win95, just not
on NT. Whatever way SDL was intended, it should be implemented
consistantly, and gasp documented.
Besides that, KEYUP does give me unicodes on win95, just not
on NT. Whatever way SDL was intended, it should be implemented
consistantly, and gasp documented.
I imagine that it’s a bug in NT, as the code for Win95 and WinNT
is exactly the same.
By the way, just so you understand, there is no such thing as a
character down/up event. There is a physical key down/up event,
which along with a set of modifiers may be translated into an
ASCII or Unicode value. I recommend that you either use key
up/down, or pay attention to input characters, which technically
only happens when a key is pressed. (the reason why key repeat works)
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
So I need to use the keysym to figure out which unicode this is the
release of, using some kind of lookup mechanism?
No, because a unicode is the code for a character, not for a key.
A character is produced by a sequence of key events. Some sequences produce
nothing at all; some more than one character.
That kinda defeats
the purpose of using unicodes in the first place. Don’t assume that
everyone that uses unicodes is only ever listening to KEYDOWN.
Then you have misunderstood the purpose of unicodes. It’s for text input,
not key identification. Keysyms are for identifying keys.
Besides that, KEYUP does give me unicodes on win95, just not
on NT. Whatever way SDL was intended, it should be implemented
consistantly, and gasp documented.
If anything we should remove unicodes from keyups on all platforms,
since they don’t make sense
I imagine that it’s a bug in NT, as the code for Win95 and WinNT
is exactly the same.
That is highly likely. Still, I am just arguing about the functionality
SDL gives me, what the implementation issues are on win32 shouldn’t
affect me.
By the way, just so you understand, there is no such thing as a
character down/up event. There is a physical key down/up event,
which along with a set of modifiers may be translated into an
ASCII or Unicode value. I recommend that you either use key
up/down, or pay attention to input characters, which technically
only happens when a key is pressed. (the reason why key repeat works)
That’s fair enough if that is the intention. But I guess it should then
consistently have unicode set to 0. Actually, the fact that unicodes
are delivered with KEYDOWN is confusing, as they don’t correspond to
the up/down pattern as you describe (a seperate type of message would
have been better).
That’s fair enough if that is the intention. But I guess it should then
consistently have unicode set to 0. Actually, the fact that unicodes
are delivered with KEYDOWN is confusing, as they don’t correspond to
the up/down pattern as you describe (a seperate type of message would
have been better).
Fair enough. I’ll fix the keyboard drivers to only do key translation
on key-down, which will speed up keyboard processing a little bit.
Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
I imagine that it’s a bug in NT, as the code for Win95 and WinNT
is exactly the same.
That is highly likely. Still, I am just arguing about the functionality
SDL gives me, what the implementation issues are on win32 shouldn’t
affect me.
By the way, just so you understand, there is no such thing as a
character down/up event. There is a physical key down/up event,
which along with a set of modifiers may be translated into an
ASCII or Unicode value. I recommend that you either use key
up/down, or pay attention to input characters, which technically
only happens when a key is pressed. (the reason why key repeat works)
That’s fair enough if that is the intention. But I guess it should then
consistently have unicode set to 0. Actually, the fact that unicodes
are delivered with KEYDOWN is confusing, as they don’t correspond to
the up/down pattern as you describe (a seperate type of message would
have been better).
I will have to use keysyms then.
Wouter
Suppose the sequence of events is as follows:
press shift
press ‘4’
release shift
release ‘4’
What should the keyup for the release of ‘4’ return as the unicode
value?
