Re: Refreshing the text widget
Veena Makal wrote:[color=blue]
> I am working on a application wherein i need to display the status on to
> the dialog as the progress is done. This may take upto 10/15 minutes.
> For this , We are using XMotif. I have created a Text Widget using
> XmCreateScrolledText(form, "textWidget", args, n) call.
> As the work is continues, We parallely keep updating status messages
> onto the Text widget using XmTextInsert() call.
> It works.
> But i have a problem here. If this window is the only active
> window/dialog for entire duration then this is absolutely fine.
> But in case, if any other window is activated, then that part of the
> text window gets hazed out.
> I am new to XMotif.
> How do i refresh the text dialog?
> I tried with registering with events for Focus as below,
> But it doesn't seem to solve my problem..
> // Snapshot of the c++ code
> (void) XtAppAddTimeOut(app, 100L, getAttributes, (XtPointer) top);
> // Method gain_focus
> void gain_focus(Widget text_w, XtPointer client_data, XtPointer
> logger->log(generalModule, debug, "Got the CallBack!! - Focus Call
> XmTextSetCursorPosition(text_w, XmTextGetCursorPosition(text_w));
> Any help is highly appriciated
This is the classic example of not understanding how an event-driven GUI
When part of your GUI gets damaged by covering it with another window
and then uncovering it, an expose event is placed on the event queue.
But your program is merrily off doing some long process, and never gets
back to the mainloop, where the expose event will be processed. Thus the
newly exposed area remains blank, since the widget redraws itself only
in response to the handling of the expose event.
You have a few choices on how to handle this kind of thing.
One is to execute the time-intensive part in a separate thread, allowing
the GUI thread to return to the main loop and continue processing
events. If your text dialog is modal, then all expose events will be
processed properly, but the user will not be able to interact with other
dialogs until the modal dialog is dismissed.
Another way is available if the time-consuming part is really just a
long loop; in this case you can use a WorkProc, where the workproc
executes the "inside" of the loop once, increments a static counter,
then returns False if the last iteration has not been performed, or True
on the lats iteration. This allows the mainloop to handle any events
between each iteration.
Still another way is to process all expose events periodically, from
within the time-consuming code, using your own mini-main loop that exits
if there are no more expose events on the queue.
Fred L. Kleinschmidt
Associate Technical Fellow
Boeing Common User Interface Services