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
jmasterx
Member #11,410
October 2009

When I get a key down, the unichar is what it is supposed to be, but when I get a key up, unichar is 0. The only thing that has stuff in it is the keycode. Is this normal? If so, how can I get the unichar to get the same value on keyup as on keydown?

Thanks

Using AL5 4.9.22

#SelectExpand
1AguiKeyboard AguiAllegro5EventManager::createKeyboard( 2 ALLEGRO_KEYBOARD_EVENT *event ) 3{ 4 ALLEGRO_KEYBOARD_STATE st; 5 al_get_keyboard_state(&st); 6 7 AguiKeyEnum key = KeyNone; 8 if(event->unichar < 128) 9 { 10 key = (AguiKeyEnum)event->unichar; 11 } 12 13 if(event->keycode == ALLEGRO_KEY_DELETE) 14 { 15 key = KeyDelete; 16 } 17 18 return AguiKeyboard(key,getExtendedKey(event->keycode), 19 event->keycode,event->modifiers,event->unichar,event->timestamp, 20 al_key_down(&st,ALLEGRO_KEY_ALT), 21 al_key_down(&st,ALLEGRO_KEY_LSHIFT) 22 | al_key_down(&st,ALLEGRO_KEY_RSHIFT), 23 al_key_down(&st,ALLEGRO_KEY_LCTRL) 24 | al_key_down(&st,ALLEGRO_KEY_RCTRL)); 25 26}

Matthew Leverton
Supreme Loser
January 1999
avatar

It's only available in key down:

http://www.allegro.cc/forums/thread/604432/872027#target

There really should be something like a KEY_PRESS event that represents a completed unichar sequence, while KEY_DOWN/UP only represent single keys.

jmasterx
Member #11,410
October 2009

Is it then a good idea to store the keyDown data and reuse on keyUp or is that bad practice?

Karadoc ~~
Member #2,749
September 2002
avatar

If you need the unichar data for your handling of key up events, then I suppose storing it from the key down event is the only possible way. But I'm not sure why you'd want the unicode data for key up anyway. Usually unicode is only useful for entering text, and it is conventional to have the text entered on the key down event rather than key up. For controls in a game or such, it's probably best to just use the keycode.

By the way, the post Matthew linked to describes an example that clearly demonstrates the problem with associating unichar with key down (or key up) events. It's worth reading.

-----------

Trezker
Member #1,739
December 2001
avatar

Wait, so things could go wrong having unichar coming from KEY_DOWN to, as described in the post Matthew linked to. Isn't this a bit of a flaw in A5?

I guess a KEY_CHAR event could be added.

Thomas Fjellstrom
Member #476
June 2000
avatar

It sounds like if you have deadkeys or some kind of input method driver setup, things could get funky, it may give you multiple keydown's for a single wanted character. I'm not sure about that, but people have said it does seem possible.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

Yes, as that post says, we kinda agreed that KEY_CHAR would be the better solution but it was too big a change to make before 5.0. There really isn't a problem though with KEY_DOWN, it's just KEY_DOWN and KEY_CHAR rolled into one. If .unichar is 0 you know that it's a dead key (so you completely ignore it for text input - but still use the keycode for things like when you're configuring game key bindings) and if .keycode is 0 (not sure this can ever happen right now) it would be a key only relevant to text input.

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

Michał Cichoń
Member #11,736
March 2010

If that was too late for 5.0, how about 5.1?

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Elias
Member #358
May 2000

Yes, for 5.1 I'd say we add a KEY_CHAR and only produce KEY_DOWN when a physical key is pressed.

We also need better support for multiple mice and multiple keyboards and other input devices, so likely there's another event or two we'll have to add.

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

Thomas Fjellstrom
Member #476
June 2000
avatar

Don't forget multi touch, which isn't the same as multiple input devices.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

Well, multi touch is easy, just need an .id field in the mouse events. Or maybe make separate TOUCH_BEGIN, TOUCH_MOVE, TOUCH_END events instead of using BUTTON_DOWN, MOUSE_AXES, BUTTON_UP.

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

Thomas Fjellstrom
Member #476
June 2000
avatar

Elias said:

Well, multi touch is easy, just need an .id field in the mouse events.

I don't think its that simple. It seems everyone doing multitouch has went with special events for multitouch due to special requirements mt has. You might want to have a look at iOS's mt events, XI2's mt events, and maybe even the linux kernel's mt events.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

Hm, googling for XI2 seems to suggest the opposite. E.g. http://cgit.freedesktop.org/xorg/proto/inputproto/tree/XI2proto.txt says:

Quote:

An XIDeviceEvent is generated whenever the logical state of a device
changes in response to a button press, a button release, a motion, a key
press or a key release. The event type may be one of KeyPress,
KeyRelease, ButtonPress, ButtonRelease, Motion.

So they have the same event now not only for button and touch but even for motion and keyboard keys.

ios also is a special case as there is no mouse. If there was a pointing device for ios most likely it would be reported with TOUCH_BEGIN/TOUCH_END.

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

Matthew Leverton
Supreme Loser
January 1999
avatar

Elias said:

Yes, for 5.1 I'd say we add a KEY_CHAR and only produce KEY_DOWN when a physical key is pressed.

That could break existing programs. How hard would it just be to do something like?:

if (unichar) {
  send(ALLEGRO_EVENT_KEY_UNICHAR);
}

Then on the KEY_DOWN event, always set unichar to 0. For Allegro 5.2, perhaps a more robust unichar system could be implemented, but it seems like doing it this way would prevent potential backward compatibility problems and shouldn't be any worse than the current implementation.

jmasterx
Member #11,410
October 2009

Yea I agree

Michał Cichoń
Member #11,736
March 2010

I think KEY_CHAR may be introduced in 5.1, while config determine if old behavior is required or not. That way Allegro will be improved and backward compatibility will be keep by config. In 5.1 mixed message should be deprecated and removed in 5.2. IMHO

In case of iPad etc multitouch is major input system, therefore they may it directly into virtual keyboard. How about Windows or Linux with multitouch screen? You can still have mouse and use multitouch. TOUCH_BEGIN, TOUCH_MOVE and TOUCH_END seems reasonable to me. If user want, he/she may connect them with MOUSE_UP/DOWN/MOVE.

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Thomas Fjellstrom
Member #476
June 2000
avatar

In 5.1 mixed message should be deprecated and removed in 5.2. IMHO

Odd minor version numbers are used exclusively for WIP releases. 5.2 will be the next stable release.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Michał Cichoń
Member #11,736
March 2010

Forgot about that, but still. WIP is good place for changes IMHO.

"God starts from scratch too"
Windows Allegro Build Repo: http://targonski.nazwa.pl/thedmd/allegro/

Matthew Leverton
Supreme Loser
January 1999
avatar

My point is simply that if we are acknowledging that the current system is "broken," and likely to change, we can minimize backward compatibility (at the source level) problems by introducing a UNICHAR event now and removing the unichar from the KEY_DOWN event.

Even if KEY_DOWN still produces extraneous events and UNICHAR isn't entirely perfect in 5.0, we would be no worse off than we currently are.

It would also minimize the complaints and confusion over why KEY_UP doesn't have unichar.

jmasterx
Member #11,410
October 2009

I agree

Goalie Ca
Member #2,579
July 2002
avatar

I'm thinking so too. It's easier to deal with a small bug than design around false assumptions.

-------------
Bah weep granah weep nini bong!

Peter Wang
Member #23
April 2000

I suppose it won't be too big of a change for users to deal with, on a par with making pre-multiplied alpha the default.

edit: in fact, KEY_CHAR might be exactly like KEY_REPEAT

Attached a patch for SVN (untested on Mac). I think most people are in agreement that this should go in 5.0?

Matthew Leverton
Supreme Loser
January 1999
avatar

KEY_CHAR might be exactly like KEY_REPEAT

It might be useful to know if it came from a repeat. This is probably an abuse of terminology, but keyboard.modifiers & ALLEGRO_KEYMOD_REPEAT would be sufficient.

However, even if that's not possible, I agree that KEY_REPEAT is not necessary.

Peter Wang
Member #23
April 2000

I'm not sure if we should reuse the modifiers field or add a new field, but it's easy either way.

torhu
Member #2,727
September 2002
avatar

I'm a bit confused as to the difference between ALLEGRO_EVENT_KEY_DOWN and ALLEGRO_EVENT_KEY_CHAR. If I type the letter 'ö', I get two KEY_DOWNs, but I also get two KEY_CHARs, even though the '¨' is on a 'dead' key. The first KEY_CHAR has a zero unichar field, the second contains the correct, complete letter.

If I type 'é', I get four KEY_CHARs, last one contains 'é' in the unichar fields. This is the output of the ex_keyboard_events example (console set to UTF-8):

KEY_DOWN  code=217, char=' ' (   0), modifiers=00000000, [LCTRL]
KEY_CHAR  code=217, char=' ' (   0), modifiers=00000002, [LCTRL]
KEY_DOWN  code=220, char=' ' (   0), modifiers=00000000, [ALTGR]
KEY_CHAR  code=220, char=' ' (   0), modifiers=00000042, [ALTGR]
KEY_DOWN  code=065, char=' ' (   0), modifiers=00000000, [KEY65]
KEY_CHAR  code=065, char=' ' (   0), modifiers=00000042, [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]

The sequence of keys pressed on my Norwegian keyboard is AltGr+\, and then E.

The docs for ALLEGRO_EVENT_KEY_CHAR say that "A character was typed on the keyboard, or a character was auto-repeated". But in reality, KEY_CHAR is a superset of KEY_DOWN, and you always get both events. Maybe this isn't a problem, but it strikes me as odd.

 1   2 


Go to: