Re: About events propagation in gtk+-1.3.3
- From: Paul Davis <pbd Op Net>
- To: "gtk-list gnome org" <gtk-list gnome org>
- Subject: Re: About events propagation in gtk+-1.3.3
- Date: Thu, 12 Apr 2001 21:34:02 -0400
Havoc writes:
>That's correct; returning TRUE from an event callback now stops the
>current signal emission. It should not however affect subsequent
>emissions, it sounds like you are saying it does?
>
>Callbacks should return TRUE if they have handled the event, and FALSE
>if they just listened to it, and someone else can still handle it.
>In what case would it be impossible or inconvenient to type FALSE
and
>instead of TRUE? The return value simply means "run further handlers,
>I didn't handle it" or "do not run further handlers, I consumed the
>event." So you have to return the one you mean. (This was also true in
>GTK 1.2, it's just that the consequences of getting it wrong weren't
>very noticeable.)
Does all of this mean that returning TRUE will stop the default
handler as well ? I have always found this a confusing aspect of the
GTK+ signal system: returning TRUE stops other explicitly connected
handlers, but it (often?) doesn't seem to stop the default handler ...
--p
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]