GNOME Bugzilla – Bug 537319
EntryCompletion not emitting signal_match_selected ()
Last modified: 2008-09-30 15:06:23 UTC
Something's wrong with EntryCompletion::signal_match_selected (). The code connected to that signal is never executed, although I haven't had time today to look into it in more detail. I'm attaching a patch for the example in gtkmm-documentation which should be a sufficient test case, including a C (gobj()) version of this that works as expected.
Created attachment 112377 [details] test case patch, apply within gtkmm-documentation/examples/book/entry/completion
I notice that this returns a bool. Does it make a difference to connect before rather than after the default signal handler?
From looking at the code, I think that the condition if(obj && obj->is_derived_()) in EntryCompletion_Class::match_selected_callback_custom() is preventing the handler from being invoked. That allows only derived classes to set a custom handler function.
> That allows only derived classes to set a custom handler function. That deals only with default signal handler, so I don't think it's relevant. You can't override a default signal handler without deriving. That's just an optimization.
Ok. Connecting before does make the custom handler be invoked. I guess we could add a comment about this in code documentation?
A patch would be welcome.
Created attachment 119640 [details] [review] proposed addition to the signal proxy doc text
Please apply, but mention a little more about about why. For instance, "so that it is called before the default signal handler, which would otherwise claim to have fully handled the signal by returning false/true/iforget"
Committed, with an explanation in the doc.