dsseewe@SUPER.ORG (Daniel Seewer) (07/28/90)
I have noticed a problem updating the values of several widgets (mostly labels) during one of my callback routines. The callback routine is a computationally intensive routine, where through the first iteration of the loop it calls XtSetValue() on various widgets to update their values. I am noticing that these labels go blank and are not updated until the "Big loop" is finished. I understand why this is happening (I think) but I thought if I put XFlush(XtDisplay(toplevel)) after the widget values are changed the events would be handled. But this is not the case. Must I dispatch events during this "Big loop" to guarantee updates? Any input that sheds light on this subject would be appreciated!! Thanks. Dan Seewer (dsseewe@super.org)
rlh2@ukc.ac.uk (Richard Hesketh) (07/28/90)
In article <9007271833.AA26394@metropolis.super.org> dsseewe@SUPER.ORG (Daniel Seewer) writes: > > I have noticed a problem updating the values of several widgets >(mostly labels) during one of my callback routines. This is a feature of how Xt does its refreshing of a widget after a SetValues call. If the widget indicates that it requires updating after the SetValues call then the Intrinsics clears the widgets window, which generates an expose event that causes the widget to be *later* redrawn. >Must I dispatch events during this "Big loop" to guarantee updates? Essentially yes. There are two general approaches to what you are doing. You can either get some events and dispatch them during your "Big loop", at a convenient point: while (XtAppPending(app_context)) { XEvent ev; XtAppNextEvent(app_context, &ev); (void)XtDispatchEvent(&ev); } Or you make your "Big loop" a sub-process, with i/o via pipes etc., which leaves the event processing loop to carry on doing its job. The pipe i/o can be handled as an extra event source thus leaving you with only one event processing loop. I find this a much better approach because it allows you to separate the user interface from the application in a fairly clean manner. It also looks really neat when you can cut and paste from output windows while still doing some number crunching 8-). > Dan Seewer > (dsseewe@super.org) Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682