Re: [gtk-list] Re: Event propogation problem

[Ian Britten <britten universal ca>]

On 20 Jan 2000, Owen Taylor wrote:

> Three different sets of handlers are run for each signal emission:
> 
>  - handlers connected with gtk_signal_connect()
>  - the default handler for the widget
>  - handlers connected with gtk_signal_connect_after()
> 
> Only the _last_ return value matters. The default handlers is running
> after your signal handler and returning FALSE.
> 
> So you have two choices:
> 
>  - If you want to override the default handler, use gtk_signal_connect(),
>    and then call gtk_signal_emit_stop_by_name() before returning TRUE
> 
>  - If you want to supplement the default handler use gtk_signal_connect_after().

Ok, now I understand (I think...).  It's not quite the same way Motif
works...  (Not that that's a bad thing :-)

> Key snoopers are called before any other handling of the key press. They
> really aren't intended for general use - perhaps you want an accelerator
> instead. (Or simply want to connect to ::key_press_event on the toplevel.)

Ok, if snoopers aren't for general use, perhaps you can suggest a solution
to my problem for me.
I'm inside I time-consuming loop, and am looking for a way to break out of
the loop in response to a user action (Typically, the Escape key being
pressed).
Because I'm in a loop, I haven't returned to the main loop, meaning that
received events aren't being processed yet.  Thus, I can't set up a signal
handler, as it won't be called until I return from my loop.  What I'm
doing is peeking into the event queue to see if the the key press is
there, and if it is, I break out of the loop.
Under X, I was using XCheckIfEvent().  What should I do under GTK?
Ian