Chris, You were right on with using Gtk::Dispatcher. Once I converted everything over it work as it should. No more strange things occurring. I had quite a few changes to make thats what took me so long to respond.
Thanks again for your help. Steve On Tue, Oct 27, 2009 at 8:09 PM, Chris Vine <[email protected]>wrote: > On Tue, 27 Oct 2009 13:49:54 -0500 > Steve Scott <[email protected]> wrote: > > I got a Gtk:Window (This is my main window). I also have a dialog > > box( which is still part of the main thread, and created by my main > > window). In the dialog I create a new thread and register with the > > new thread a callback(e.g. g_FileCopyDialog::progressBarUpdate). So > > it looks like this: > > > > Thread 1 - Main Gtk App (MainWindow, g_FileCopyDialog) > > Thread 2 - File COPY THREAD. This is a thread created in > > g_FileCopyDialog, (DirectFile::runCopyThread) > > > > Thread 1 registers the a callback to thread 1 via: > > file->copy_progress.connect( sigc::mem_fun(*this, > > &g_FileCopyDialog::progressBarUpdate) ); > > > > Thread 1 creates the file copy thread via: Glib::Thread *const > > thread = Glib::Thread::create(sigc:: > > mem_fun(*file, &DirectFile::runCopyThread), true ); > > > > Thread 1 does NOT join thread 2 after its created > > > > Thread 2 will then "run" and call > > g_FileCopyDialog::progressBarUpdate every time 512 bytes are copied. > > This works like a charm. > > > > The problem is that even though the > > g_FileCopyDialog::progressBarUpdate is being called everytime like it > > should, the progress bar does not update unless I call > > m_pcopyprogressbar->set_fraction( .01) first with some fictionous > > value in THREAD 1. > > You are almost certainly doing something wrong with the way your > threads interface with gtkmm and libsigc++. It may well not be the > cause of your problem but I notice for example (so far as I can make > sense of your explanation) that you connect a signal 'copy_press' to a > slot representing g_FileCopyDialog::progressBarUpdate() in thread 1, and > appear to emit that signal in thread 2 (you say that thread 2 will "call > g_FileCopyDialog::progressBarUpdate every time 512 bytes are copied"). > That in itself is going to lead to trouble because libsigc++ is not > thread safe and you would need a synchronising mutex to be locked every > time that the signal object is manipulated in some way, including when > it is emitted. sigc::trackable is also not thread safe and can be a > cause of various side effects (and cannot sensibly be protected by an > external mutex). > > Using the GDK global lock will not save you with respect to libsigc++, > even if you are using the global lock correctly. You will probably be a > lot better off using Glib::Dispatcher. > > Chris > > >
_______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
