[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat Jan 7, 2012, Elias Pschernig wrote:
> On Sat, 7 Jan 2012 02:46:24 -0600
>
> Matthew Leverton <meffer@xxxxxxxxxx> wrote:
> > Lastly, is there any (preferred) way to make events in add-ons look
> > less like they are hacked on as an after thought via the user event?
>
> I guess the only way for things to look properly for the user right
> now would be if they could do:
>
> al_get_next_event(queue, &event);
> if (event.type == ALLEGRO_EVENT_AUDIO) {
> buffer = event.audio.buffer;
> }
>
> But I don't see any possibility to make that work.
>
> Maybe we should add an alternate way to access event fields which looks
> something like:
>
> al_get_next_event(queue, &event);
> if (event.type == ALLEGRO_EVENT_AUDIO) {
> buffer = ALLEGRO_AUDIO_EVENT(event).buffer;
> }
>
> the macro could then simply be something like:
>
> #define ALLEGRO_AUDIO_EVENT(event)\
> (*(ALLEGRO_AUDIO_EVENT_STRUCT *)&event))
>
> We should also make a macro for each builtin event type so you can
> handle all your events consistently, e.g.:
>
> keycode = ALLEGRO_KEYBOARD_EVENT(event).keycode;
>
> The union way would of course stay valid for backwards compatibility.
I don't know how well that'll work since the ALLEGRO_EVENT struct is of a fixed
size. If someone makes a type that doesn't fit in that space, bad things can
happen. One of the main reasons for the fixed size (at least I think so) is so
that managing events in queues is simple and fast.
> ---------------------------------------------------------------------------
> --- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a
> complex infrastructure or vast IT resources to deliver seamless, secure
> access to virtual desktops. With this all-in-one solution, easily deploy
> virtual desktops for less than the cost of PCs and save 60% on VDI
> infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx