Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » [AL5] Unichar is always NULL when I get a key up

This thread is locked; no one can reply to it. rss feed Print
 1   2 
[AL5] Unichar is always NULL when I get a key up
Elias
Member #358
May 2000

I think no KEY_CHAR should be posted for the modifier keys.

--
"Either help out or stop whining" - Evert

Matthew Leverton
Supreme Loser
January 1999
avatar

I think it should look like:

KEY_DOWN  code=217, char=' ' (   0), modifiers=00000000, [LCTRL]
KEY_DOWN  code=220, char=' ' (   0), modifiers=00000000, [ALTGR]
KEY_DOWN  code=065, char=' ' (   0), modifiers=00000000, [KEY65]
KEY_UP    code=065, char=' ' (   0), modifiers=00000000, [KEY65]
KEY_UP    code=217, char=' ' (   0), modifiers=00000000, [LCTRL]
KEY_UP    code=220, char=' ' (   0), modifiers=00000000, [ALTGR]
KEY_DOWN  code=005, char=' ' (   0), modifiers=00000000, [E]
KEY_CHAR  code=005, char='é' ( 233), modifiers=00000000, [E]
KEY_UP    code=005, char=' ' (   0), modifiers=00000000, [E]

Peter Wang
Member #23
April 2000

Oops, modifier keys should not send CHAR events. How is this patch? (untested on OS X)

I set my keyboard layout to Norwegian on Windows XP, and pressed AltGr+e and got:

KEY_DOWN  code=217, char=' ' (   0), modifiers=00000000, [LCTRL]
KEY_DOWN  code=220, char=' ' (   0), modifiers=00000000, [ALTGR]
KEY_DOWN  code=005, char=' ' (   0), modifiers=00000000, [E]
KEY_CHAR  code=005, char='€' (8364), modifiers=00000042, [E]
KEY_UP    code=005, char=' ' (   0), modifiers=00000000, [E]
KEY_UP    code=217, char=' ' (   0), modifiers=00000000, [LCTRL]
KEY_UP    code=220, char=' ' (   0), modifiers=00000000, [ALTGR]

torhu
Member #2,727
September 2002
avatar

Looks good to me - haven't tested the patch, though. I don't know why AltGr sends an LCTRL event, but maybe it's Windows that does that.

BAF
Member #2,981
December 2002
avatar

I was going to suggest modeling it after the way .NET does it, but what Peter Wang has posted is exactly that. I assume Matthew's example matches that as well.

Trezker
Member #1,739
December 2001
avatar

I have this code now for inserting a char in ustr. Anything wrong with this?
I noted that if I hold altgr and keep pressing a letter, cursor only moves half the time, why?
The font doesn't support the character that comes out so I just get boxes for this. Recommend a font that has all these symbols?

I do convert to c string before drawing, perhaps this is why things get screwed up?

int pos = al_ustr_offset(text, cursor);
if(al_ustr_insert_chr(text, pos, event.keyboard.unichar)>0)
{
   ++cursor;
   Push_event(Event(this, "changed"));
}

Peter Wang
Member #23
April 2000

Looks okay. You might want to compare with TextEntry::on_key_down() in nihgui.cpp.

torhu
Member #2,727
September 2002
avatar

I've made a patch that skips sending KEY_CHAR events for dead keys. It also sends two char events when that's appropriate. The output of ex_keyboard_events now matches Matthew's 'é' example. Here are some other examples:

'¨', 'o' to get 'ö':

KEY_DOWN  code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_UP    code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_DOWN  code=015, char=' ' (   0), modifiers=00000000, [O]
KEY_CHAR  code=015, char='ö' ( 246), modifiers=00000000, [O]
KEY_UP    code=015, char=' ' (   0), modifiers=00000000, [O]

'¨', 'k', which is an invalid combination, and produces two characters:

KEY_DOWN  code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_UP    code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_DOWN  code=011, char=' ' (   0), modifiers=00000000, [K]
KEY_CHAR  code=011, char='¨' ( 168), modifiers=00000000, [K]
KEY_CHAR  code=011, char='k' ( 107), modifiers=00000000, [K]
KEY_UP    code=011, char=' ' (   0), modifiers=00000000, [K]

'¨', space, to get just the accent:

KEY_DOWN  code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_UP    code=068, char=' ' (   0), modifiers=00000000, [KEY68]
KEY_DOWN  code=075, char=' ' (   0), modifiers=00000000, [SPACE]
KEY_CHAR  code=075, char='¨' ( 168), modifiers=00000000, [SPACE]
KEY_UP    code=075, char=' ' (   0), modifiers=00000000, [SPACE]

Maybe sending two char events for invalid combinations is a bit over the top, but that's how Windows does it.

I don't know why Allegro doesn't use the WM_CHAR messages, but that might be a better fix than checking the return value of ToUnicode to detect dead keys, like I did.

Peter Wang
Member #23
April 2000

That looks better, thanks. I will commit it, with an analogous change for X11.

Can someone update OS X?

Evert
Member #794
November 2000
avatar

I'm not entirely clear on what the problem is. It seems to have something to do with dead keys, which doesn't quite seem to work the same way on OS X.
I can do "option-e" and the system will wait for me to type another character (say e or k) at which point I will either get é or ´k. In ex_keyboard_events I get CHAR events for "ALT" (with an invalid character code, more on that next) and for "e" and "k", but I don't get character events for é (rather than e) or ´.

I also get "ex_keyboard_events[11907:903] *** -[NSCFString characterAtIndex:]: Range or index out of bounds", which is due to Allegro's keyboard driver asking for the character corresponding to the "ALT" up/down events.

Now, some or all of this is probably due to the way Allegro interprets OS X keyboard events. I can look into it, but I can't give a reliable estimate for when I can do that; it depends on how smoothly some other things I have to do go.

Peter Wang
Member #23
April 2000

The KEY_CHAR event should not be generated for modifier keys (shift, alt, ctrl, etc.), nor for dead keys.

_al_osx_keyboard_handler in keybd.m has this line:

const char upper_character = [[event characters] characterAtIndex: 0];

What it probably should be doing is generating a KEY_CHAR event for each character returned by [event characters]. I think this is the source of the problems you mentioned.

Evert
Member #794
November 2000
avatar

What it probably should be doing is generating a KEY_CHAR event for each character returned by [event characters].

Makes sense.

Quote:

I think this is the source of the problems you mentioned.

Yes, I'm sure it is. Actually, there are two calls to characterAtIndex at that point in the code, and two lines of output complaining about it.

 1   2 


Go to: