Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: Re: Detecting/Compressing Multiple Exposure Events - how ?
Message-ID: <19880831130506.7.RWS@KILLINGTON.LCS.MIT.EDU>
Date: 31 Aug 88 13:05:00 GMT
References: <4652@mit-vax.LCS.MIT.EDU>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 27


    Date: 31 Aug 88 01:30:19 GMT
    From: mit-vax!josh@bloom-beacon.mit.edu  (Joshua Marantz)

	    XIfPending (display, event_return, predicate, arg);
	    XMaskPending (display, event_return, event_mask, arg);

    Currently, I have to emulate that functionality with an XCheckIfEvent followed
    by an XPutBackEvent, which has the annoying side effect of rearranging the
    event queue.

As I pointed out in a previous posting, by using the arg value you can
avoid having to pull anything out of the queue.  In general, Xlib
functionality is rather unlikely to change if there are reasonable ways
to build "convenience" routines on top of existing functionality.  That
isn't to say that additional convenience routines aren't useful, just
that they probably won't go into Xlib.  If people feel strongly that
additional routines ought to be provided in some sort of utility library
on the MIT release, we're willing to listen (and take code that comes
with documentation).

    Another advantage of defining your own event queue is that you can efficiently
    filter out uninteresting events, check for user interrupts (like Control-C), 
    and so on.

If you want efficient handling of "out of band" events, you can install your
own wrapper routine for the WireToEvent conversion, and trap it before it
ever even enters the queue.  See Appendix C of the Xlib manual.