[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sat, 7 Jan 2012 07:24:37 -0700
Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> wrote:
> 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.
>
Just use a static assert to guard against accidentally using a too big
event struct - we do that at several places already.