| >> And call it as often as I can... Right?
But beware of REENTRANCY. What will you do if the user does the
necessary menu pulldowns, etc, to call your long-running proc
reentrantly from inside the XtDispatch which is inside the long-running proc?
The toolkit will not prevent or detect reentrancy of this type.
But things can get very messy nevertheless...
You might consider handling only certain types of events in your inner loop,
deferring or discarding other event types (like buttonpress, release, etc).
Then, you have to be careful that you don't do things like throw away a
downclick but not the upclick, and that the relative order of
events stays "sane". That is, you'll have to maintain the relative
order of MapNotifies and Expose, etc, so that widgets don't get
confused.
Detecting reentrant calls to your proc may be the best idea. But
you have to watch out for secondary effects. For example, suppose
that while your long-running proc is running, the user selects
something from the menu that depends on the results of the long-running
operation. The second operation needs to either wait for the
first one to complete, or you need to report to the user that
he can't do both things at once. Selecting the original action
reentrantly is just a special case of this general dependency problem.
So, it isn't *that* simple.
-steve-
|
| You can prevent the reentrancy problem by displaying a modal work in progress
box. The toolkit will then throw away any mouse and button events which
are not sent to the work in progress box itself.
> static void ProcessXInputQueue()
> {
> XEvent *event
>
> while(XtPending) {
> XtNextEvent(event);
> XtDispatchEvent(event);
> }
> }
Should be this instead:
static void ProcessXInputQueue()
{
XtInputMask mask;
while(mask = XtPending()) {
XtProcessEvent(mask);
}
}
The reason is that XtPending will return true under three cases:
1. X event pending
2. Timeout callback pending
3. Alternate input callback pending.
For case 1, your loop is equivalent. But for case 2 or 3, the call
to XtNextEvent will execute the callback and then *BLOCK* waiting for
a *REAL* x event. Your application will appear to "freeze" until the
server generates an event.
Leo
|