Re: Thread problem in Windows



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.

Filipe


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]