erik@srava.sra.JUNET (Erik M. van der Poel) (02/17/89)
Using XtAppNextEvent() it is possible to fetch an X event, examine it, and decide what to do with it. Ordinarily one would pass it to XtDispatchEvent() but one does not have to; the event can also be ignored, for example. Unless I am "missing something", there does not seem to be a way of doing the same thing with alternate input and timer events. It would be nice if one could check the source (file descriptor) or XtIntervalId before deciding to dispatch the event. -- 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)
swick@ATHENA.MIT.EDU (Ralph R Swick) (02/22/89)
Date: 17 Feb 89 04:57:24 GMT
From: kddlab!icot32!nttlab!gama!etlcom!titcca!sragwa!srava!erik@uunet.uu.
net (Erik M. van der Poel)
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.
There is; since alternate inputs and timers are not "events", the
machinery is slightly different, but you can accomplish the same
effect. 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). If you have multiple alternate
input sources, you'll have to determine your own mechanism to
assign priority between them, though; Xt will only treat them
as a group.asente@decwrl.dec.com (Paul Asente) (02/22/89)
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. Ordinarily one would pass it to >XtDispatchEvent() but one does not have to; the event can also be >ignored, for example. > >Unless I am "missing something", there does not seem to be a way of >doing the same thing with alternate input and timer events. It would be >nice if one could check the source (file descriptor) or XtIntervalId >before deciding to dispatch the event. 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. -paul asente asente@decwrl.dec.com decwrl!asente
erik@srava.sra.JUNET (Erik M. van der Poel) (02/22/89)
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)
swick@ATHENA.MIT.EDU (Ralph R Swick) (02/23/89)
> 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. So why can't you use XtAppProcessEvent(ctx, XtIMXEvent) to block, ignoring everything, until the next XEvent comes along? Or, if you're _really_ trying to get your hands on that event before Xt dispatches it then just call XNextEvent directly. > Enough griping. Apart from this, Xt is OK, thanks to all involved. no problem; I'm just trying to figure out whether we really did leave out something that you need or whether we just didn't document something else well enough.