Not bad, but we'll have to port this to Linux, Android, OSX and iOS too, though...

I think 'solve' is pretty strong here. In my testing this:

• Generates an unpaired KEY_DOWN event

• Breaks US International keyboard layout:

Log from ex_keyboard_events with this patch:

KEY_DOWN  code=215, char=' ' (   0), modifiers=00000000, [LSHIFT]
KEY_DOWN  code=069, char=' ' (   0), modifiers=00000000, [KEY69]
KEY_CHAR  code=069, char='"' (  34), modifiers=00000001, [KEY69]
KEY_CHAR  code=069, char='"' (  34), modifiers=00000001, [KEY69]
KEY_UP    code=069, char=' ' (   0), modifiers=00000000, [KEY69]
KEY_UP    code=215, char=' ' (   0), modifiers=00000000, [LSHIFT]
KEY_DOWN  code=005, char=' ' (   0), modifiers=00000000, [E]
KEY_CHAR  code=005, char='e' ( 101), modifiers=00000000, [E]
KEY_UP    code=005, char=' ' (   0), modifiers=00000000, [E]

And without:

KEY_DOWN  code=215, char=' ' (   0), modifiers=00000000, [LSHIFT]
KEY_DOWN  code=069, char=' ' (   0), modifiers=00000000, [KEY69]
KEY_UP    code=069, char=' ' (   0), modifiers=00000000, [KEY69]
KEY_UP    code=215, char=' ' (   0), modifiers=00000000, [LSHIFT]
KEY_DOWN  code=005, char=' ' (   0), modifiers=00000000, [E]
KEY_CHAR  code=005, char='ë' ( 235), modifiers=00000000, [E]
KEY_UP    code=005, char=' ' (   0), modifiers=00000000, [E]

• Doesn't work with the Chinese IME I was using (the one built into Windows)

to torhu

in my patch i have handled both ANICODE window and UNICODE window

to SiegeLord
i only add handle the WM_IME_CHAR message. if you do not use ime to input, it should be no effect.
and i do not have a us layout keyboard, so i cant test that.

this patch only effect windows, have no effect to other os.

The TranslateMessage call breaks some other input types.

The current code works fine for everything except IME. My patch in the other thread catches all characters in all input methods I tried, but sometimes generates bogus events. This patch breaks a whole bunch of input methods and doesn't work for the Chinese IME input I am using.

The difference between this patch and mine is that I also rewrite the rest of the unicode input, thus preserving the functionality of other input methods. Unfortunately, it generates bogus events which I don't think is acceptable.

E.g. entering the ë key (compare with above):

KEY_DOWN  code=215, char=' ' (   0), modifiers=00000000, [LSHIFT]
KEY_DOWN  code=069, char=' ' (   0), modifiers=00000000, [KEY69]
KEY_CHAR  code=069, char=' ' (   0), modifiers=00000001, [KEY69]
KEY_UP    code=069, char=' ' (   0), modifiers=00000000, [KEY69]
KEY_UP    code=215, char=' ' (   0), modifiers=00000000, [LSHIFT]
KEY_DOWN  code=005, char=' ' (   0), modifiers=00000000, [E]
KEY_CHAR  code=005, char='ë' ( 235), modifiers=00000000, [E]
KEY_UP    code=005, char=' ' (   0), modifiers=00000000, [E]

So you're saying you shouldn't get a KEY_CHAR event for KEY69 when making that foreign e? How are you supposed to know in advance that they didn't want a KEY_CHAR with KEY69? That may illustrate my lack of knowledge, because I don't even know what key 69 is.

The first one is probably saying "Hey, I'm getting a composed char here...". Getting a CHAR event with an unprintable char should just be ignored in most cases no? (Except for when you actually want to know when you're getting some kind of compose or IME event)

I guess what we need to do is:

1. Create an ALLEGRO_EVENT_CHAR if and only if there is a WM_CHAR

2. Except, for some known special cases, like cursor keys, we create extra ALLEGRO_EVENT_CHAR

The first rule should ensure that there are no unexpected ALLEGRO_EVENT_CHAR. Only when Windows thinks there should be a unicode character added Allegro will do the same.

The second would be a somewhat unfortunate hack and not really necessary, but for backwards compatibility makes sense to have the ALLEGRO_EVENT_CHAR for some other control keys which do not produce unicode as that's just how Allegro works now.

Yes, but it shouldn't be too many. Cursors, home, end, delete, backspace, escape, page up/down, return, tab. If we special case those and then have all the printable Unicode characters, that will be what is expected.