[AD] [ alleg-Bugs-3194187 ] [OS X] ALLEGRO_EVENT_KEY_CHAR not always generated

["SourceForge.net" <noreply@xxxxxxxxxx>]

Bugs item #3194187, was opened at 2011-02-27 16:47
Message generated for change (Comment added) made by eglebbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3194187&group_id=5665

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Mac OSX
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Evert Glebbeek (eglebbk)
Assigned to: Peter Hull (peterhull90)
Summary: [OS X] ALLEGRO_EVENT_KEY_CHAR not always generated

Initial Comment:
When pressing a key with a non-printable character (eg, an arrow key), I don't get KEY_CHAR events, only KEY_DOWN and KEY_UP events. This is fine if the intention for the KEY_CHAR event is to enter text, but from the description in the manual it appears that it should work for non-printable characters as well.
I'm actually fine with the current behaviour (text input and key presses for controling a game are two distinct operations, after all), but I suspect it's not the intended behaviour and not consistent across platforms.
The relevant piece of code in src/macosx/keybd.m is

         ALLEGRO_EVENT event;
                         event.keyboard.type = ALLEGRO_EVENT_KEY_DOWN;
                         event.keyboard.timestamp = al_get_time();
                         event.keyboard.display   = dpy;
                         event.keyboard.keycode   = scancode;
                         event.keyboard.unichar   = 0;
                         event.keyboard.modifiers = 0;
                         event.keyboard.repeat    = false;
                         if (!is_repeat) {
                                 _al_event_source_emit_event(&keyboard.es, &event);
                         }
                         if (unicode > 0)
                         {
                                 event.keyboard.type = ALLEGRO_EVENT_KEY_CHAR;
                                 event.keyboard.unichar = unicode;
                                 event.keyboard.modifiers = modifiers;
                                 event.keyboard.repeat = is_repeat;
                                 _al_event_source_emit_event(&keyboard.es, &event);
                         }


----------------------------------------------------------------------

>Comment By: Evert Glebbeek (eglebbk)
Date: 2011-03-07 16:59

Message:
Could be. I have now check-out 5.1, I'll give it a shot tonight, but the
code looks the same in both.
It's probably not so much different keyboard drivers, but an OS version or
hardware thing. Which for our purpose probably comes down to the same
thing.

----------------------------------------------------------------------

Comment By: Elias Pschernig (elias)
Date: 2011-03-07 15:54

Message:
So there seem to be different keyboard driver behaviors in OSX - some send
63234 and some send 0?

----------------------------------------------------------------------

Comment By: Peter Hull (peterhull90)
Date: 2011-03-06 21:46

Message:
The reason why char is 63234 - it's a private use unicode char that Apple
has assigned to the left key (there are others for all function keys,
dating back to NEXTStep days apparently)
http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/CORPCHAR.TXT


----------------------------------------------------------------------

Comment By: Peter Hull (peterhull90)
Date: 2011-03-06 21:35

Message:
Has this been fixed now? With the latest (14592) svn for the 5.1 branch I
get:
KEY_DOWN  code=082, char=' ' (   0), modifiers=00000000, [LEFT]
KEY_CHAR  code=082, char='' (63234), modifiers=00000000, [LEFT]
KEY_UP    code=082, char=' ' (   0), modifiers=00000000, [LEFT]
when pressing left - is this not correct?


----------------------------------------------------------------------

Comment By: Peter Wang (tjaden)
Date: 2011-03-05 01:43

Message:
I hope to release 5.0.1 in one or two weeks time. If someone could fix this
bug soon that would be great.

----------------------------------------------------------------------

Comment By: Peter Wang (tjaden)
Date: 2011-02-28 00:35

Message:
Yes, bug fixes should go on the 5.1 branch. It makes it easier for me to
collect all the relevant patches at once.

----------------------------------------------------------------------

Comment By: Elias Pschernig (elias)
Date: 2011-02-27 21:26

Message:
It would make things like the Shift key generate a KEY_CHAR. Better than
the current behavior in any case - but different from Linux/Windows I
think.

----------------------------------------------------------------------

Comment By: Evert Glebbeek (eglebbk)
Date: 2011-02-27 17:57

Message:
Thought as much.
It looks like removing the "if (unicode > 0)" clause would be enough to
fix the problem.
Should bug fixes still be commited to the 5.1 branch?

----------------------------------------------------------------------

Comment By: Elias Pschernig (elias)
Date: 2011-02-27 17:01

Message:
This is a bug. Arrow keys of course need to generate KEY_CHAR events (how
can you ever make a text entry box otherwise?) and they do so both in Linux
and Windows as intended. What should happen for a cursor key press is:

KEY_DOWN, KEY_CHAR, KEY_CHAR (repeat), ..., KEY_UP

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105665&aid=3194187&group_id=5665