|
|
|
This thread is locked; no one can reply to it.
|
| [A5] questions about events |
|
axilmar
Member #1,204
April 2001
|
I have some questions regarding A5 event handling: 1) ALLEGRO_EVENT_KEY_UP does not have the unichar field. Should I keep the unichar value from ALLEGRO_EVENT_KEY_UP myself or it is going to be available in the future? 2) ALLEGRO_EVENT_MOUSE_AXES does not have the button field. Should I keep the button value from ALLEGRO_EVENT_MOUSE_BUTTON_DOWN myself or it is going to be available in the future? 3) Is the ALLEGRO_EVENT_MOUSE_ENTER_DISPLAY event followed by a ALLEGRO_EVENT_MOUSE_AXES event? 4) in the event ALLEGRO_EVENT_MOUSE_AXES, do I check if the mouse moved by checking the fields dx and dy? |
|
Mark Oates
Member #1,146
March 2001
 |
axilmar said: 2) ALLEGRO_EVENT_MOUSE_AXES does not have the button field. Should I keep the button value from ALLEGRO_EVENT_MOUSE_BUTTON_DOWN myself or it is going to be available in the future? I'm sure it wont. Since a mouse button press has nothing to do with the mouse moving. -- |
|
axilmar
Member #1,204
April 2001
|
Mark Oates said: I'm sure it wont. Since a mouse button press has nothing to do with the mouse moving. But what if you want to know which button is pressed while the mouse is moving? "Normal" event systems (like Win32) report the mouse button as well as the mouse position. |
|
SiegeLord
Member #7,827
October 2006
 |
axilmar said: But what if you want to know which button is pressed while the mouse is moving? What if you want to know which keyboard button is pressed while the mouse is moving? At which point do you stop from including the entire input state in every input event? Anyway, you have two solutions. The preferred way is to use those events to update a struct/class of yours that holds the mouse state. The less preferred way is to use al_get_mouse_state. axilmar said: 4) in the event ALLEGRO_EVENT_MOUSE_AXES, do I check if the mouse moved by checking the fields dx and dy? Well, in principle there's also dz which can also cause the event to be sent... but yes, that's the idea. "For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18 |
|
Thomas Fjellstrom
Member #476
June 2000
 |
axilmar said: 3) Is the ALLEGRO_EVENT_MOUSE_ENTER_DISPLAY event followed by a ALLEGRO_EVENT_MOUSE_AXES event? Not sure if it's supposed to, but it doesn't seem to. My Canva5 lib handles both messages as if they are a "MOUSE_AXES" event, seems to make sense that way. -- |
|
Peter Wang
Member #23
April 2000
|
axilmar said: 1) ALLEGRO_EVENT_KEY_UP does not have the unichar field. Should I keep the unichar value from ALLEGRO_EVENT_KEY_UP myself or it is going to be available in the future? It will not be made available.
|
|
Trent Gamblin
Member #261
April 2000
 |
What's the problem with making unichar available on key down, just out of curiousity?
|
|
Peter Wang
Member #23
April 2000
|
It is available on key down, but not key up. I conflated two things into the KEY_DOWN event. First, it signals that the user pressed a physical key. But it also indicates that a user entered a particular character, which could be a combination of keys which were hit previously (e.g. dead keys) or currently held down (e.g. shift). As Elias has pointed out, we should actually have separate events for physical key presses and character input. Here's an example. Say you are using dead keys to type é, by hitting two keys in sequence: apostrophe, then E. You get a KEY_DOWN event (keycode=apostrophe, unichar=0), then another KEY_DOWN (keycode=E, unichar=é). Ok so far. But if you hit apostrophe, then T? Assuming there is no character mapped to that sequence, with some input methods, that could produce two characters. At the time we send out the KEY_DOWN event for T, though, the KEY_DOWN event for apostrophe was already sent out. So we only have one event to signal two characters. There are more complicated input methods where character input and keys are even more decoupled. e.g. press a few keys, then pick a character from a graphical list with the mouse. So the answer is: unichar shouldn't even be provided with KEY_DOWN.
|
|
Trent Gamblin
Member #261
April 2000
|
Ok. I misread it as KEY_DOWN not providing a unichar. But what you says makes sense. Is this a 5.0 or later update feature?
|
|
Peter Wang
Member #23
April 2000
|
I don't think anyone is planning to fix this for 5.0, but it should be fixable in a backwards compatible way later.
|
|
axilmar
Member #1,204
April 2001
|
SiegeLord said: What if you want to know which keyboard button is pressed while the mouse is moving? At which point do you stop from including the entire input state in every input event? You stop at the point that the majority of use cases are covered. 99% of mouse moves that need to know the input state is limited to mouse buttons and modifier keys. That's why most Window systems report the mouse button and modifier keys in mouse move events. I think that the mouse button and modifiers should be reported in mouse move events. The mouse event struct even has the button field available, so minimal changes are required. Peter Wang said: So the answer is: unichar shouldn't even be provided with KEY_DOWN. I agree, for the reasons you mention. |
|
Mark Oates
Member #1,146
March 2001
|
axilmar said: You stop at the point that the majority of use cases are covered. 99% of mouse moves that need to know the input state is limited to mouse buttons and modifier keys. That's why most Window systems report the mouse button and modifier keys in mouse move events. I think that the mouse button and modifiers should be reported in mouse move events. The mouse event struct even has the button field available, so minimal changes are required. Interesting. I think you have a convincing point. Using that logic, it certainly makes sense to include the mouse button state with ALLEGRO_EVENT_MOUSE_BUTTON_DOWN. This would make some functionality (dragging, for example) more accessible. After all, ALLEGRO_EVENT_MOUSE_BUTTON_DOWN returns the mouse wheel position, which doesn't seem nearly as practical. -- |
|
|
