On Thu, 2005-06-16 at 06:08 -0500, Bob Caryl wrote:
> Murray Cumming wrote:
>
> >And if you must provided a C function pointer, you'll need to provide a
> >pointer to a static method (or global function) and the state
> >information as user_data. See the various SignalProxy classes, for
> >instance, in TreeSelection.
> >
> >
> >
> In other words, the way I've done it (separate executable invoked via
> fork, execv) is the only thread safe way to do this until GtkHTML has a
> C++ wrapper.
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. if you
really want to use C++ objects with GTK widgets, then do this:
class Foo {
public:
static gint my_c_proxy_for_bar (arglist...);
gint my_handler_for_bar (otherarglist...);
};
gint
Foo::my_c_proxy_for_bar (..., gptr user_data, ...)
{
return reinterpret_cast<Foo*>(user_data)->my_handler_for_bar
(relevant_args...);
}
gint
Foo::my_handler_for_bar (otherarglist...)
{
}
and then somewhere, connect
gtk_signal_connect (widget, "signal", ...., SomePtrToFoo);
I have done this a lot with the GtkCanvas widget which has never been
wrapped for C++ (and never will be; we're migrating to GNOME::Canvas
ASAP)
--p
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list
