On 4/18/08, Dunk Fordyce <[EMAIL PROTECTED]> wrote:
>
>  >  Perhaps you could give some more description regarding what you've
>  >  changed, and why; what more complicated event structures benefit from
>  >  this change?  And does it break backward compatibility?
>
>
> Ah sorry, here's a diff against trunk to show the changes a little
>  more clearly ( should of done that in the first place! ):
>
>  Index: event.py
>  ===================================================================
>  --- event.py    (revision 2016)
>  +++ event.py    (working copy)
>  @@ -338,7 +338,7 @@
>
>              if handler:
>                  try:
>                      if handler(*args):
>  -                        return
>
> +                        return True
>
>                  except TypeError:
>                      self._raise_dispatch_exception(event_type, args, handler)
>
>
> @@ -346,11 +346,13 @@
>
>          # Check instance for an event handler
>          if hasattr(self, event_type):
>              try:
>
> -                getattr(self, event_type)(*args)
>
> +                return getattr(self, event_type)(*args)
>
>              except TypeError:
>                  self._raise_dispatch_exception(
>                      event_type, args, getattr(self, event_type))
>
>  +        return False
>
> +
>      def _raise_dispatch_exception(self, event_type, args, handler):
>          # A common problem in applications is having the wrong number of
>          # arguments in an event handler.  This is caught as a TypeError in
>
>  The added return statements allow you to check if an event has been
>  processed or not ( as long as your callbacks return something anyway
>  ). It allows you to create schemes where dispatchers need to check if
>  an event has been processed and then possibly send it on to
>  parent/child/other handlers. Personally I've been using this for a
>  widget system where each control is an event dispatcher and so I need
>  a return value to decide whether to continue sending the event to
>  child controls or not.
>
>  As far as I know it doesn't break backward compatibility anywhere.

Ok, seems a little odd to me, but I have no real objection.  I've
opened issue 275 for it to be included in pyglet 1.2.

Alex.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to