Re: Thread problem in Windows

Filipe Apostolo wrote:
Filipe Apostolo wrote:
Armin Burgmeier wrote:
Filipe Apostolo wrote:
Armin Burgmeier wrote:
        Glib::Thread *const opcWriterThread = Glib::Thread::create(
             sigc::mem_fun(this, &MyClass::ThreadTest), true);
Joining a thread means waiting for it to finish. So you are waiting
for the thread here before running the dialog, which explains the
behaviour you are experiencing.

Try joining it afterwards, or make the thread non-joinable.


Thanks it worked, however the the main thread is sucked until the user
closes the window, how can I call it back without user interaction?
Use .show() instead of .run().
I tried so, but the dialog appears only with the decoration, and inside
is transparent. I used .show_all_children() followed by .show_all() and
then by show_now(), but still transparent inside.
To close the Window when the thread finishes, you can set up an idle
handler in the thread right before it exits, and in your handler
(which will then be executed by the main thread), call .hide() on the
I did not test this because of the previous behavior but instead of
using the dispatcher or another thread I used the createdThread->join()
in the parent thread before calling .hide(), assuming that he will stop
waiting for the thread to finish and then call the hide(), do you thing
that the problem is here? Thats the reason of the dialog appears
transparent inside?
Meanwhile I'll try your solution.
I think you can also use Glib::Dispatcher for the same task.


Ok, now it is all working, strangely  I had to  remove the .hide() after
the ->join(), and consequently I removed ->join() to because now it
becomes useless . Then I have declared the message dialog as an class
atributte and filled it in class constructor. Called show and inside the
thread code handler after the routines that i need  I called the .hide()
of the dialoag that I have created.

Don't do this. GTK+ should only be accessed from one thread (normally the main thread), and not from any other threads. This is especially true on Windows. It might be working for you now, but then this is a coincidence. It might fail for others, and it might fail when you try more complex things then just hiding a dialog.

Use an idle handler or Glib::Dispatcher instead. I think for the latter there is an example in the gtkmm and/or glibmm tarball on how to use it.

And in this way it goes as it should go.

I ask if is this not a bug?

join() waits for a thread to finish, and it blocks while it does. This means that other code in the thread calling join() will not run as long as the thread being joined has not finished. So if you join() a thread in your GUI (main) thread, then it's normal that the GUI becomes unresponsive because of this.

Also, if you don't join your thread when it finishes, be sure to create it as non-joinable, because otherwise I think there is a resource leak when you don't ever join it.


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