Re: About events propagation in gtk+-1.3.3



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]