[MonoDevelop] Which sigal for Gtk.Entry...

Michael Hutchinson m.j.hutchinson at gmail.com
Sun Nov 15 17:28:53 EST 2009


On Sun, Nov 15, 2009 at 11:54 AM,  <stacheldraht at interia.pl> wrote:
> Am Mittwoch 11 November 2009 23:31:26 schrieb Oskar Berggren:
>> 2009/11/11 Oskar Berggren <oskar.berggren at gmail.com>:
>> To answer my own question, the "changed" signal comes from the
>> GtkEditable interface, I just discovered. Is it possible that the
>> "changed" signal don't fire until the entry looses keyboard focus (and
>> has had its contents altered)?
>>
> OK, I tried again...and the "Chnged" dignal really works! :-] In fact, it is
> fired every time the content of the entry changes. And why didn't it work for
> the first time? Well, I have found MD several times "eat up" a signal I
> defined for some widget...and in this particular case it happened. :-[

GTK# connects your events as signal handler *after* the widget's own
signal handler. For example, Gtk.Button subscribes to the mouse button
signals on it its base class, Gtk.Widget, to catch mouse clicks. It
then uses a property on the signal arguments to stop the signal
propagating to further handlers, so your handlers for these events
would not get called.

However, in the above case the Button has a Clicked event that you
should really use rather than using the mouse events directly. The
connect before/after issue is generally only a problem when you want
to mess with built-in widget behaviours. In such cases, you can use
[GLib.ConnectBefore] on your event handlers to make them get connected
*before* the built-in handler. You can then use the args.RetVal to
prevent them being propagated to the built-in handler, if you want.

This doesn't apply to the Gtk.Entry.Changed event AFAIK, but it's
*usually* the reason why GTK# signals appear not be be emitted.

-- 
Michael Hutchinson
http://mjhutchinson.com


More information about the Monodevelop-list mailing list