Re: Signals with default handlers

Hi Gavin,

You can try connecting your handler before the default handler by
setting the "after" parameter to false when connecting the signal

view.signal_console_message().connect(..., false);

Otherwise if the default handler returns true any handlers after it
might not get called. The various *_event signal handlers in Gtk::Widget
behave in a similar way.


On Wed, 2011-06-01 at 13:28 +1200, Gavin Lambert wrote:
> I've been writing a program which uses webkitmm (and incidentally, if anyone
> is interested, I have some local updates to webkitmm to bring it up to
> support WebKit 1.4.0 -- though I haven't mm-encapsulated the JS/DOM/libsoup
> types).
> I'm getting some undesirable behaviour from a signal which has a default
> handler (virtual method defined in the underlying GTK+ class) --
> specifically, it appears to be ignoring attempts to connect a signal
> handler, and invoking the original GTK+ handler instead of my own.  Some
> relevant bits of code:
> webkitmm source definition:
>   _WRAP_SIGNAL(bool console_message(const std::string& message, guint line,
> const std::string& source_id), "console-message")
> Webkit/GTK signal definition:
>     webkit_web_view_signals[CONSOLE_MESSAGE] =
> g_signal_new("console-message",
>             G_TYPE_FROM_CLASS(webViewClass),
>             (GSignalFlags)G_SIGNAL_RUN_LAST,
>             G_STRUCT_OFFSET(WebKitWebViewClass, console_message),
>             g_signal_accumulator_true_handled,
>             NULL,
>             webkit_marshal_BOOLEAN__STRING_INT_STRING,
>             G_TYPE_BOOLEAN, 3,
> My attempt to attach signal handler:
>   m_web_view.signal_console_message().connect(sigc::mem_fun(this,
> &MyWindow::on_console_message));
> My handler is never called; the default handler defined inside WebKit/GTK is
> called instead.
> If I instead derive a subclass from WebView and override the virtual
> on_console_message function in that, then it gets called as expected.  (And
> if that calls the base class implementation, then it does both, as
> expected.)
> So: why aren't "traditional" signal handlers getting called for this signal?
> Is this a bug or have I set something up incorrectly?
> (Incidentally, signals wrapped using no_default_handler seem to correctly
> call their connected signal handler.)
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org

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