Re: Problem in updating progress bar
- From: "Michael Ekstrand" <michael elehack net>
- To: DC A <adc4444 hotmail com>
- Subject: Re: Problem in updating progress bar
- Date: Thu, 15 Jun 2006 17:58:10 -0500
On Thu, Jun 15, 2006 at 06:07:09PM +0000, DC A wrote:
> What could be the reason for using gtk_events_pending() and
> gtk_main_iteration() in the following code snippet:
>
> for( gflt=0; gflt<=1; ){
> gtk_progress_bar_update( (GtkProgressBar*)pbar, gflt );
> //update
> while (gtk_events_pending ())
> gtk_main_iteration ();
> gflt += 0.1;
> sleep(1);
> if ( gflt > 1 ) break;
> }
>
> why the code cannot update the progressbar without these two functions? I
> saw the API but still it is not clear to me.
The gtk_progress_bar_update function does not actually draw the updated
progress bar, but it rather schedules an update to happen next time
drawing happens (essentially - the details are probably slightly
different). Flushing the event queue (the point of the two questioned
calls) forces this event to be processed, so that the progress display
is actually updated. It also has the convenient side effect of allowing
any user events to be processed - enables your app to be more responsive
without multithreading.
But yeah, I'm not 100% sure how the progress bar update code looks, but
here is how I would implement such an API call (pseudocode):
update_storage_of_fraction
invalidate_progress_bar
invalidating causes GTK to schedule a redraw, which then calls the same
redraw function that is used when the widget is exposed, etc. That way
you only have drawing code in one place. So it makes the implementation
notably simpler.
- Michael
--
mouse, n: a device for pointing at the xterm in which you want to type.
-- Fortune
Visit me on the Web: http://www.elehack.net
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]