Re: Cocoa alternative for method aliasing?
Re: Cocoa alternative for method aliasing?
- Subject: Re: Cocoa alternative for method aliasing?
- From: WT <email@hidden>
- Date: Tue, 29 Mar 2011 21:16:48 -0300
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._______________________________________________
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