ALLEGRO_EVENT(3alleg5) | ALLEGRO_EVENT(3alleg5) |
ALLEGRO_EVENT - Allegro 5 API
#include <allegro5/allegro.h> typedef union ALLEGRO_EVENT ALLEGRO_EVENT;
An ALLEGRO_EVENT is a union of all builtin event structures, i.e. it is an object large enough to hold the data of any event type. All events have the following fields in common:
By examining the type field you can then access type-specific fields. The any.source field tells you which event source generated that particular event. The any.timestamp field tells you when the event was generated. The time is referenced to the same starting point as al_get_time(3alleg5).
Each event is of one of the following types, with the usable fields given.
A joystick axis value changed.
A joystick button was pressed.
A joystick button was released.
A joystick was plugged in or unplugged. See al_reconfigure_joysticks(3alleg5) for details.
A keyboard key was pressed.
Note: this event is about the physical keys being pressed on the keyboard. Look for ALLEGRO_EVENT_KEY_CHAR events for character input.
A keyboard key was released.
A character was typed on the keyboard, or a character was auto-repeated.
Some special keys will set the unichar field to their standard ASCII values: Tab=9, Return=13, Escape=27. In addition if you press the Control key together with A to Z the unichar field will have the values 1 to 26. For example Ctrl-A will set unichar to 1 and Ctrl-H will set it to 8.
As of Allegro 5.0.2 there are some inconsistencies in the treatment of Backspace (8 or 127) and Delete (127 or 0) keys on different platforms. These can be worked around by checking the keycode field.
Note: in many input methods, characters are not entered one-for-one with physical key presses. Multiple key presses can combine to generate a single character, e.g. apostrophe + e may produce `é'. Fewer key presses can also generate more characters, e.g. macro sequences expanding to common phrases.
One or more mouse axis values changed.
Note: Calling al_set_mouse_xy(3alleg5) also will result in a change of axis values, but such a change is reported with ALLEGRO_EVENT_MOUSE_WARPED(3alleg5) events instead which are identical except for their type.
Note: currently mouse.display may be NULL if an event is generated in response to al_set_mouse_axis(3alleg5).
A mouse button was pressed.
A mouse button was released.
al_set_mouse_xy(3alleg5) was called to move the mouse. This event is identical to ALLEGRO_EVENT_MOUSE_AXES otherwise.
The mouse cursor entered a window opened by the program.
The mouse cursor left the boundaries of a window opened by the program.
The touch input device registered a new touch.
5.1.0
A touch ended.
Has the same fields as ALLEGRO_EVENT_TOUCH_BEGIN(3alleg5).
5.1.0
The position of a touch changed.
Has the same fields as ALLEGRO_EVENT_TOUCH_BEGIN(3alleg5).
5.1.0
A touch was cancelled. This is device specific but could for example mean that a finger moved off the border of the device or moved so fast that it could not be tracked any longer.
Has the same fields as ALLEGRO_EVENT_TOUCH_BEGIN(3alleg5).
5.1.0
A [timer]ALLEGRO_TIMER(3alleg5) counter incremented.
The display (or a portion thereof) has become visible.
Note: The display needs to be created with ALLEGRO_GENERATE_EXPOSE_EVENTS flag for these events to be generated.
The window has been resized.
You should normally respond to these events by calling al_acknowledge_resize(3alleg5). Note that further resize events may be generated by the time you process the event, so these fields may hold outdated information.
The close button of the window has been pressed.
When using Direct3D, displays can enter a “lost” state. In that state, drawing calls are ignored, and upon entering the state, bitmap’s pixel data can become undefined. Allegro does its best to preserve the correct contents of bitmaps (see the ALLEGRO_NO_PRESERVE_TEXTURE flag) and restore them when the device is “found” (see ALLEGRO_EVENT_DISPLAY_FOUND(3alleg5)). However, this is not 100% fool proof (see discussion in al_create_bitmap(3alleg5)’s documentation).
Note: This event merely means that the display was lost, that is, DirectX suddenly lost the contents of all video bitmaps. In particular, you can keep calling drawing functions – they just most likely won’t do anything. If Allegro’s restoration of the bitmaps works well for you then no further action is required when you receive this event.
Generated when a lost device is restored to operating state. See ALLEGRO_EVENT_DISPLAY_LOST(3alleg5).
The window is no longer active, that is the user might have clicked into another window or “tabbed” away. In response to this event you might want to call al_clear_keyboard_state(3alleg5) (possibly passing display.source as its argument) in order to prevent Allegro’s keyboard state from getting out of sync.
The window is the active one again.
Generated when the rotation or orientation of a display changes.
When a display receives this event it should stop doing any drawing and then call al_acknowledge_drawing_halt(3alleg5) immediately.
This is currently only relevant for Android and iOS. It will be sent when the application is switched to background mode, in addition to ALLEGRO_EVENT_DISPLAY_SWITCH_OUT(3alleg5). The latter may also be sent in situations where the application is not active but still should continue drawing, for example when a popup is displayed in front of it.
Note: This event means that the next time you call a drawing function, your program will crash. So you must stop drawing and you must immediately reply with al_acknowledge_drawing_halt(3alleg5). Allegro sends this event because it cannot handle this automatically. Your program might be doing the drawing in a different thread from the event handling, in which case the drawing thread needs to be signaled to stop drawing before acknowledging this event.
Note: Mobile devices usually never quit an application, so to prevent the battery from draining while your application is halted it can be a good idea to call al_stop_timer(3alleg5) on all your timers, otherwise they will keep generating events. If you are using audio, you can also stop all audio voices (or pass NULL to al_set_default_voice(3alleg5) if you use the default mixer), otherwise Allegro will keep streaming silence to the voice even if the stream or mixer are stopped or detached.
5.1.0
ALLEGRO_EVENT_DISPLAY_RESUME_DRAWING(3alleg5)
When a display receives this event, it may resume drawing again, and it must call al_acknowledge_drawing_resume(3alleg5) immediately.
This is currently only relevant for Android and iOS. The event will be sent when an application returns from background mode and is allowed to draw to the display again, in addition to ALLEGRO_EVENT_DISPLAY_SWITCH_IN(3alleg5). The latter event may also be sent in a situation where the application is already active, for example when a popup in front of it closes.
Note: Unlike ALLEGRO_EVENT_DISPLAY_FOUND(3alleg5) it is not necessary to reload any bitmaps when you receive this event.
5.1.0
ALLEGRO_EVENT_DISPLAY_HALT_DRAWING(3alleg5)
This event is sent when a physical display is connected to the device Allegro runs on. Currently, on most platforms, Allegro supports only a single physical display. However, on iOS, a secondary physical display is supported.
5.1.1
This event is sent when a physical display is disconnected from the device Allegro runs on. Currently, on most platforms, Allegro supports only a single physical display. However, on iOS, a secondary physical display is supported.
Allegro reference manual |