Re: Cocoa alternative for method aliasing?
Re: Cocoa alternative for method aliasing?
- Subject: Re: Cocoa alternative for method aliasing?
- From: Lou Zell <email@hidden>
- Date: Tue, 29 Mar 2011 20:36:05 -0700
On Tue, Mar 29, 2011 at 5:16 PM, WT <email@hidden> wrote:
> On Mar 29, 2011, at 4:25 PM, Matt Neuburg wrote:
>
> > On Tue, 29 Mar 2011 11:20:31 -0700, Lou Zell <email@hidden> said:
> >> I have a subclass of UIButton, call it MyButton, that I would like to
> >> function as a vanilla UIButton but also pass touch events to the next
> >> responder (I'm interested in eventually getting the events in
> >> UIViewController). I can do something like this in MyButton:
> >>
> >> -(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
> >> {
> >> [[self nextResponder] touchesBegan:touches withEvent:event];
> >> }
> >
> > Don't do that. The way to pass touches up the responder chain is by
> calling super. This will do exactly what you're after, I think.
> >
> > However, as already implied, you might be better off with a different
> architecture. It isn't at all clear why you'd do what you're describing. Let
> the button act as a button. If you need further information about what's
> going on, consider a gesture recognizer, perhaps, or just use the button's
> control events. In any case there should be no need to interfere at the very
> low level of the touches... responder methods. There are *many* ways to
> interfere with aspects of touch delivery; they are quite interesting, but be
> careful or you'll break something.
> >
> > m.
>
> Moreover, according to the Event Handling Guide for iOS,
>
>
> http://developer.apple.com/library/ios/#documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/MultitouchEvents/MultitouchEvents.html
>
> "Important: If your custom responder class is a subclass of UIView or
> UIViewController, you should implement all of the methods described in “The
> Event-Handling Methods.” If your class is a subclass of any other UIKit
> responder class, you do not need to override all of the event-handling
> methods; however, in those methods that you do override, be sure to call the
> superclass implementation of the method (for example, super
> touchesBegan:touches withEvent:theEvent];). The reason for this guideline is
> simple: All views that process touches, including your own, expect (or
> should expect) to receive a full touch-event stream. If you prevent a UIKit
> responder object from receiving touches for a certain phase of an event, the
> resulting behavior may be undefined and probably undesirable."
>
> and, further down,
>
> "Handling Events in Subclasses of UIKit Views and Controls
> If you subclass a view or control class of the UIKit framework (for
> example, UIImageView or UISwitch) for the purpose of altering or extending
> event-handling behavior, you should keep the following points in mind:
>
> - Unlike in a custom view, it is not necessary to override each
> event-handling method.
> - Always invoke the superclass implementation of each event-handling method
> that you do override.
> - Do not forward events to UIKit framework objects."
>
> W.
Yikes, thanks for pointing that out!
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden