Re: Added tooltip to display details of items in TreeView

[Chris Vine <chris cvine freeserve co uk>]

On Friday 06 May 2005 15:41, Andrew E. Makeev wrote:
> Bob Caryl wrote:
> > Tony Yum wrote:
> > That connection syntax should probably be:
> >
> > signal().connect(sigc::bind<bool>(sigc::mem_fun(object, &mem_fun),
> > false));
> >
> > where mem_fun expects the boolean value as a formal parmater.
>
> I don't think that was changed in Gtkmm-2.6 comparing to Gtkmm-2.4, but
> connect() function has 2 arguments: 1 - connection slot, 2 - flag after
> = true by default. So, if you would your callback to be called before
> other handlers you should to pass false as second argument. Instead, you
> may wish to use connect_notify() function that "sending" after = false.

You don't use sigc::bind.

Although they are not well documented for those new to gtkmm, these are glibmm 
signal proxies, which are interfaces to the GObject signal system on which 
GTK+ relies.  The connect method for these takes two arguments, the second 
argument determining whether the user's callback is called after the GTK+ 
default handler (if any) - a true value, or before it - a false value.

A glibmm signal proxy has two forms of connect: connect(), which by default 
passes true (after) to the second argument, and connect_notify(), which by 
default passes false (before) to the second argument.  connect_notify() also 
always expects a void return type for the callback, even if the signal 
requires a boolean return type (say it is handling an GDK/X event, all of 
which have "_event" in the signal name).  connect_notify() will supply the 
boolean return value itself, and return false (carry on processing the 
signal).

Confusingly, GObject's g_signal_connect() calls the callback before the 
default handler (g_signal_connect_after() will call it after the default 
handler).  Both these are macro front ends for g_signal_connect_object().  
Returning true from a callback connected using g_object_connect() will 
therefore stop signal emission to the default handler.  I do not know why 
gtkmm does it the other way around but I expect there is a reason.  Of course 
with gtkmm you have access to the equivalent virtual protected member 
function ("on...()") for more fine-grained control of how the default handler 
executes (the GObject signal system offers you before or after, and if 
before, either skip the default handler or don't skip it, whereas with the 
gtkmm virtual protected member function you can call the default handler at 
any point you want).

A sigc signal object does not have the second argument - it knows nothing 
about default handlers, as it is justs a generalised callback mechanism.  
Likewise it has no connect_notify() method.

Chris

-- 
Summer is y-cumen in, lhude sing, cuccu!
Groweth sed and bloweth med, springeth the wude nu.