Re: Cocoa alternative for method aliasing?
On Tue, Mar 29, 2011 at 5:16 PM, WT wrote:
> On Mar 29, 2011, at 4:25 PM, Matt Neuburg wrote:
>
> > On Tue, 29 Mar 2011 11:20:31 -0700, Lou Zell 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
Re: Cocoa alternative for method aliasing?
On Mar 29, 2011, at 4:25 PM, Matt Neuburg wrote:
> On Tue, 29 Mar 2011 11:20:31 -0700, Lou Zell 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 (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
Re: Cocoa alternative for method aliasing?
David, Matt,
Thanks for the responses and pointing me towards UIControlEvents.
> >-(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.
>
>
Using super will call -touchesBegan:withEvent of UIButton. Which, in my
experiments, does not continue to pass the event up the responder chain --
i.e. I never see the touch events reach my UIViewController (where I want
them to end up). My understanding is that once an object is found that
responds to -touchesBegan:withEvent, the event propagation ends unless
explicitly forwarded. Calling super will get the event to my superclass
(UIButton), but not beyond that.
Lou
___
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
Re: Cocoa alternative for method aliasing?
On Tue, 29 Mar 2011 11:20:31 -0700, Lou Zell 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.
--
matt neuburg, phd = m...@tidbits.com,
Re: Cocoa alternative for method aliasing?
On Mar 29, 2011, at 11:20 AM, Lou Zell wrote: > Mornin' Devs, > > Is there a recommended pattern for passing events up the responder chain > without subclassing a class and overriding the methods I'm interested in? > Here is an explanation of what I'm trying to do: There is a certain question of "why?" in this, but I think the answer is that you should use the various control events that are exposed for -addTarget:action:forControlEvents:. By doing so you can get action messages for basically every touch interaction without needing to subclass to forward messages. -- David Duncan ___ 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
