Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!kddlab!titcca!sragwa!srava!erik
From: erik@srava.sra.JUNET (Erik M. van der Poel)
Newsgroups: comp.windows.x
Subject: Re: querying event sources in Xt
Message-ID: <2043@srava.sra.JUNET>
Date: 22 Feb 89 02:35:24 GMT
References: <2041@srava.sra.JUNET>, <8902211642.AA26009@LYRE.MIT.EDU>, <1122@bacchus.dec.com>
Reply-To: erik%sra.junet@uunet.uu.net (Erik M. van der Poel)
Organization: Software Research Associates, Inc., Japan
Lines: 49

In article <8902211642.AA26009@LYRE.MIT.EDU> swick@athena.mit.edu (Ralph R Swick) writes:
>In article <2041@srava.sra.JUNET> erik%sra.junet@uunet.uu.net (Erik M. van der Poel) writes:
>>Using XtAppNextEvent() it is possible to fetch an X event, examine it,
>>and decide what to do with it.
>>...
>>Unless I am "missing something", there does not seem to be a way of
>>doing the same thing with alternate input and timer events.
>
>...XtAppPending() will tell you whether or not an alternate
>input is ready or a timer is about to fire. XtAppProcessEvent()
>will allow you to tell Xt which of the three queues to process
>(inputs, events, and/or timers)...

Yes, but XtAppPending() does not block, so it probably should not be
used in a loop in the way that XtAppNextEvent() and XtDispatchEvent()
are.

In article <1122@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes:
>You're certainly free to do whatever processing you want in your input and
>timer callback procedures, including doing nothing or queuing up a task
>for later processing.
>
>I'm not sure I understand what it is you're trying to accomplish here.

I bumped into this problem while developing a program that expects X
events and alternate input. Instead of using printf(), I wrote a routine
that prints out the message in a window. There is also an OK button,
which the user presses when the message has been read. So, I want the
application to stop processing while that window is up. But alternate
input is processed by XtAppNextEvent(), which in the case of my program
led to an avalanche of message windows. Right now I have solved this
problem (perhaps somewhat unsatisfactorily) by programming at the lower
(X-library) level.

Of course, I could have ignored the alternate input in the callback by
checking a global boolean set by the message routine, but that's not
very clean.

In the Xt interface, the 3 types of event sources are not always treated
uniformly. XtAppPending() and XtAppProcessEvent() provide uniform power,
but XtAppNextEvent() is biased towards X events (which is to be expected
:-). Why not have XtAppNextEvent() return an XtInputMask? (And have it
return the fd or XtIntervalId.)

Enough griping. Apart from this, Xt is OK, thanks to all involved.
-- 
Erik M. van der Poel                  erik@sra.junet             (Japan)
SRA, 1-1-1 Hirakawa-cho, Chiyoda-ku   erik%sra.junet@uunet.uu.net  (USA)
Tokyo 102 Japan. TEL +81-3-234-2692   erik%sra.junet@mcvax.uucp (Europe)