Hi !
> Well, this is only a problem for broken or really strange apps, but
> I think we should still provide a way around it:
>
> Let gq be the number of events queued in LibGII and kq be the number
> of events queued in the kernel.
> Initial state: gq = 0, kq = 3
> giiEventPoll() is called ==> fetches all events ==> gq = 3; kq = 0;
> giiEventRead() is called, but only twice ==> gq = 1; kq = 0;
> Now the user moves the mouse arround ==> gq = 1; kq = 5;
> giiEventPoll() is called ==> as gq > 0 no events are fetched from kq
> into gq. This is 100% correct due to performance reasons, BUT:
> When giiEventsQueued() is called and returns the number of events in
> the queue you get 1 allthough there are more events that could be
> read.
This is an interesting point, but IMHO this behaviour of the program is
broken. I'd rather document that instead of introducing a new call.
> When I think of it we should definitely add this function, because
> it will allow the following common code:
> ...
> to be replaced with:
>
> n = giiQueuedAfterPoll(inp, mask);
> while (n--) {
> giiEventRead(inp, &ev, mask);
> process_event(%ev);
> }
O.K. - that looks a bit more elegant ... However we should not break the
naming scheme of giiEvent*. Other than that I have no objections.
Even though I generally don't like schemes that do something like "getValue;
while(value--) ...", as they are likely to cause problems with threaded
applications, but well.
CU, ANdy
--
Andreas Beck | Email : <[EMAIL PROTECTED]>
