On Tue, Mar 29, 2011 at 5:16 PM, WT <jrca...@gmail.com> wrote: > On Mar 29, 2011, at 4:25 PM, Matt Neuburg wrote: > > > On Tue, 29 Mar 2011 11:20:31 -0700, Lou Zell <lzel...@gmail.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com