On Monday 08 December 2003 10:37 am, Gustavo J. A. M. Carneiro wrote:
. This would be a Bad Idea (TM)!
>
> Anyway, an alternative to signal handler blocking, which doesn't seem
> to be working (I read down the thread), would be a simple trick of
> locking:
>
> def area_expose_cb(self, area, event):
> """ Update the DrawingArea """
> if self.__area_expose_cb_lock: return True
> self.__area_expose_cb_lock = True
> ...
> Do something on the Drawing Area
> ...
> self.__area_expose_cb_lock = False
> return gtk.TRUE
I've done similar things, only it was with mouse handling, and it worked very
consistantly. ( Whenever the mouse was being moved, I needed to warp it back
to the starting point, which generated another mouse event. )
I had to structure it a bit differently though, more like:
#Ignores the next event, whether it is recursive or not.
def handle_event( self, widget, event ):
if self.locked:
self.locked = false:
return
#stuff that might generated another event.
self.locked = true
I found (atleast with mouse events ) that emitting the new event signal didn't
necessarily mean it would get processed right away, rather it is put on the
event queue to get executed after the current event is finished, so it isn't
recursive.
Jon
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
