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



On 25 Jan 2000, Owen Taylor wrote:

> > 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
> 
> Generally what you want to do in this circumstance is to occasionally 
> process the events from the main events loop using:
> 
>  while (g_main_iteration (FALSE))
>    /* Nothing */;
> 
> Then when you get an escape key (using, for instance, a ::key_press_event handler),
> you set a flag that you check after calling g_main_iterate.

Ok, that's sounding do-able (I haven't tried yet though).  However,
there's one caveat that has me concened...

I've already got a key-press signal handler set up on this drawing area
(Case 1) for other purposes.  To do what you suggest, I need to set up a
second key-press signal hander (Case 2) on that drawing area (This is
because the relevant code is in different classes, different parts of the
program, etc.) 

To do what you propose, I HAVE to guarantee that the Case2 signal hander
is called first for that Escape key, so that breaking out of the loop is
the result of the key press.  If the Case1 signal handler is called first,
then something different will be done (resulting in incorrect behaviour),
and Case1 will call gtk_signal_emit_stop_by_name(), meaning that the Case2
signal handler will never be called.
How do I ensure the separate signal handlers are called in the desired
order (or can I)?

So, in light of this, is your suggestion still valid?
Thanks,
Ian



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]