Re: Thread problem in Windows

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 22 Sep 2009 11:01:09 +0100
Filipe Apostolo <f apostolo cbr gmail com> wrote:
> Chris Vine wrote:
> > On Mon, 21 Sep 2009 14:54:41 +0100
> > Filipe Apostolo <f apostolo cbr gmail com> 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