|
|
|
This thread is locked; no one can reply to it.
|
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 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}
Agui GUI API -> https://github.com/jmasterx/Agui |
|
Matthew Leverton
Supreme Loser
January 1999
 |
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? Agui GUI API -> https://github.com/jmasterx/Agui |
|
Karadoc ~~
Member #2,749
September 2002
 |
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
 |
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
 |
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. -- |
|
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. -- |
|
Michał Cichoń
Member #11,736
March 2010
|
If that was too late for 5.0, how about 5.1? "God starts from scratch too" |
|
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. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
Don't forget multi touch, which isn't the same as multiple input devices. -- |
|
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. -- |
|
Thomas Fjellstrom
Member #476
June 2000
|
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. -- |
|
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 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. -- |
|
Matthew Leverton
Supreme Loser
January 1999
|
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 Agui GUI API -> https://github.com/jmasterx/Agui |
|
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" |
|
Thomas Fjellstrom
Member #476
June 2000
|
Michał Cichoń said: 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. -- |
|
Michał Cichoń
Member #11,736
March 2010
|
Forgot about that, but still. WIP is good place for changes IMHO. "God starts from scratch too" |
|
Matthew Leverton
Supreme Loser
January 1999
|
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 Agui GUI API -> https://github.com/jmasterx/Agui |
|
Goalie Ca
Member #2,579
July 2002
 |
I'm thinking so too. It's easier to deal with a small bug than design around false assumptions. ------------- |
|
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
|
Peter Wang said: 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
 |
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
|
