On Tue, 22 Sep 2009 11:01:09 +0100 Filipe Apostolo <[email protected]> wrote: > Chris Vine wrote: > > On Mon, 21 Sep 2009 14:54:41 +0100 > > Filipe Apostolo <[email protected]> wrote: > > > > > >> Hi gtkmm developers and users.. > >> > >> First of all I like to say that I'm working with gtkmm since one > >> year and I'm very pleased with this great tool... > >> > >> I'm doing a software that provides an user interface to communicate > >> with some hardware, > >> The software is finished but I want to add a very important > >> feature. Because this feature can have more solutions I will > >> explain the process a little more detailed, to obtain more advises > >> and/or more opinions. > >> > >> At some point in my software the user will click on a Button to > >> write his configuration options (that he chooses trough the GUI)to > >> the hardware, this action takes +- 1 second, but during this > >> waiting time the user does not have a feed back of what is > >> happening. Actually the user sees the Button pushed down and when > >> the write is done he sees a message dialog telling that the action > >> succeeded or not. If I launch a message dialog to with a simple > >> message (after I would upgrade it with a progress bar) like > >> "Configuring", the message must be closed/ hided before I call the > >> routine. Right? but then user dont sees the message anymore It's > >> not what i want. > >> > >> So I created a Thread using glib/thread > >> And made some unsuccessful tests... > >> > > > > Threading is almost certainly the wrong solution. You cannot have > > more than one thread accessing GTK+ in windows, and even in > > unix-like systems using the the GDK global lock is usually a bad > > idea. > > > > If you want to provide a progress dialog, then use a timeout > > attached to the main loop. > > > > Chris > > > > > Thanks, > So you say that I have to use show() instead of run () and have a > timeout handler setting new values in the progressbar obj. Right? > I think in this case it can be the best solution, I'll try it.
Yes, that's the idea. Gtk::Dialog::run() makes it a blocking dialog, and you don't want that. Create it on freestore, update it with a timeout handler and delete it when you are finished with it (ie when progress has reached 100%, or if the user causes a delete event or presses the Cancel button if there is one). Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
