On Thu, 2005-06-16 at 07:22 -0500, Bob Caryl wrote: > Paul Davis wrote: > > >what are you thinking? this has nothing to do with threads. it doesn't > >even have a *lot* to do with language, except for the fact that you > >can't use a non-static C++ member function as a C callback. > > > Evidently I have failed to make clear the circumstances surrounding this > situation. > > The callback function involved is one that opens a resource file (like > an image source) to load its content into a GtkHTML widget when that > widget issues a "url-requested" signal. This widget would have been > embedded into a scrolled_window container within a Gtk::Window. The > callback function for the "url-requested" would need to have access to > information within the derived Gtk::Window class itself to be able to do > its job. > > I had originally intended to write my help display routine as part of a > dynamic library intended for use by my applications. If I use a global > function in this setting it would be entirely possible that multiple > applications and/or threads in the same application could try to call > such a global function simultaneously (or nearly simultaneously), > thereby giving indeterminate results. > > *That* is what I was thinking, Paul. If my concerns in this regard are > misplaced I would hope you guys would point out *why*.
Again, please look at the various *SignalProxy classes, as suggested so you can use sigc++ slots and not worry about this state information. Threads still seem to have nothing to do with this. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
