RE: [gtk-list] Forcing a widget redraw
- From: Martynas Kunigelis <mkunigelis alna lt>
- To: "'gtk-list redhat com'" <gtk-list redhat com>
- Cc: "'David Given'" <david_given tao co uk>
- Subject: RE: [gtk-list] Forcing a widget redraw
- Date: Tue, 24 Nov 1998 12:34:50 +0100
-----Original Message-----
From: David Given [SMTP:david_given@tao.co.uk]
Sent: 1998 m. Lapkritis 24 d. 11:40
To: gtk-list@redhat.com
Subject: [gtk-list] Forcing a widget redraw
Is it possible to make a widget redraw *now*, i.e. don't put an event on
the
queue?
I have a program that's doing major processing (a CD sound file editor, if
you're interested). When it's processing tens of megabytes of data it can
take
a while. I'd like to have a progress bar.
Unfortunately, if I change the value of the progress bar in the usual way,
the
signal is deferred until my function returns. By which time the whole
operation has finished.
Yes, I *know* I should be doing the processing in small chunks in the
background but that's hard.
No it's not that hard. Do it the other way -- make a small dialog with a
progress bar (you know, the usual thing), make it grab the keyboard and
mouse (i.e. make it modal with gtk_main_grab_add()). Then after you update
the progress bar do a simple loop:
/* The function names here are from memory, check gtkmain.h */
while (gtk_main_events_pending())
gtk_main_iteration();
The grab ensures that no input events from other windows are processed and
the scrollbar should repaint nicely. In addition, you might check if the
user clicked the "Cancel" button on your dialog (I suppose you put one
there ;) and cancel the whole operation then.
I apologize if this message is malformed or in HTML format -- I have no
idea what the evil MS Outlook will do to it. I _have_ to use it now, though
:(
-Martynas
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]