Hi,
Sam Lantinga wrote:
The problem with that fix is that it breaks IME events again. Maybe
we can handle keyboard events differently to prevent this issue?
Spending an hour reading MSDN, analysing SDL and another hour testing
the reality on XP I am really wondering how patch r4990 could have ever
worked in any situation. It’s main effect is to break the unicode
translation and causing spurious activation events!
Why does TranslateMessage(&msg) nothing useful? Simply because it does
not affect “msg” at all! All keyboard events are dispatched without the
slightest change (see MSDN). TranslateMessage() just appends additional
WM_CHAR, WM_DEADCHAR, WM_SYSCHAR, WM_SYSDEADCHAR event messages to the
queue. But I could not find any SDL event handling routine that catches
these events and transforms them to proper SDL keyevents while
eliminating the corresponding WM_KEYDOWN, etc. events. Thus any IME
input like the ‘@’ generated by “Alt + 6(Numpad) + 4(Numpad)” is simply
lost.
But the situation is even worse! Up to r4990 the
TranslateKey()/ToUnicode() calls did evaluate dead keys and did deliver
proper key events for subsequent key strokes like ‘?’ + ‘e’ resulting in
’?’. ToUnicode() needs proper key state informations to be able to
handle these substitutions. But unfortunatly TranslateMessage() needs
the same state information and eats it up while generating the WM_CHAR
messages 
Thus the current 1.2.14 breakes the partial IME support of
previous releases, too.
The key state race condition between ToUnicode() and TranslateMessage()
requires to avoid any ToUnicode() usage for receiving proper WM_CHAR,
etc. messages generated by TranslateMessage(). (Yes - the ‘@’ and '?'
appear as WM_CHAR messages when unicode is switched off).
The spurious SDL activation events are not caused by additional
WM_ACTIVATE Windows messages! Besides DIB_HandleMessage()
SDL_PrivateAppActive() is called by another source which I am not yet
aware of - any hints?
Thus I do strongly recommend the deletion of the TranslateMessage(&msg)
call as a quick fix.
A proper support of unicode and IME requires a clean SDL keyboard input
concept first. Which SDL keyboards events should be transmitted to the
app when the user presses ‘?’ + ‘e’ ? Within the current unicode
handling the first key stroke is hidden. Even though ToUnicode()
delivers the proper key SDL does ignore it in TranslateKey(). Just the
composed key event is transmitted to the app. That is what you expect
for text input, but the app can no longer use keys like ‘^’ as a key
button because it will never receive a key event for it!
With a given concept it seems to be necessary to regenerate SDL key
events out of the WM_CHAR, etc. events and to drop all related direct
WM_KEYDOWN, etc. events while the remaining basic WM_KEYDOWN, etc.
events would still have to result in SDL key events.
Anyway the source of the spurious WM_ACTIVATE should be located to avoid
future trouble.
Greets,
Ronald> Just checked 1.2.14 on XP with the TranslateMessage by typing Alt +
6(Keypad) + 4(Keypad) - release Alt. With IME this should deliver a key
event ‘@’. But the app receives ‘6’ + ‘4’! In which usage cases does
this TranslateMessage() work anyway?
The lost gain event looks like the IME is done by another process and
SDL gets informed that the input is handled by someone else. But in this
case it would be the task of SDL to catch and ignore these ACTIVEEVENTs.
The app itself can not distinguish spurious ACTIVEEVENTs from real ones
like those caused by an Alt + Tab.
Ronald Lamprecht wrote:
just noticed that on Windows our application receives a spurious
SDL_ACTIVEEVENT with gain 0 whenever the user presses Alt + any key.
This
event follows the Alt and the key SDL_KeyboardEvent events.
I filed this bug report as #882 a few days ago. The source of trouble
has
been introduced with revision 4990 on fixing bug #634. It is just the
single
line added in src/video/windib/SDL_dibevents.c - line 366:
TranslateMessage(&msg);
If you delete this line again, or include it in
#ifdef NO_GETKEYBOARDSTATE
TranslateMessage(&msg);
#endif
the event queue seems to be reliable again.
This fix fixes Bugreport #865 (Windows “default beep” when any
Alt+Key is
used), too!