Re: Intercepting events and touches in UIPickerView subclasses? (or, WTF is going in the UIPickerView's responder chain?)
Re: Intercepting events and touches in UIPickerView subclasses? (or, WTF is going in the UIPickerView's responder chain?)
- Subject: Re: Intercepting events and touches in UIPickerView subclasses? (or, WTF is going in the UIPickerView's responder chain?)
- From: David Duncan <email@hidden>
- Date: Fri, 18 Dec 2009 09:12:48 -0800
On Dec 18, 2009, at 7:32 AM, glenn andreas wrote:
> 2) Subclass UIApplication and override sendEvent: - this can get ugly from an architecture point of view (since you no longer have a nice little reusable view - you've got to do major surgery on the application itself), and sendEvent: does a whole lot of work that you'll want to be careful not to break.
The general recommendation is to subclass UIWindow instead of UIApplication. Still override -sendEvent:, but realize that the event has already been given its destiny, you only get to peek at it and possibly embellish, and you should send it on its way ([super sendEvent:]) before you do anything else.
And whatever else you do, make sure your quick with it, because -sendEvent: gets called a LOT.
--
David Duncan
Apple DTS Animation and Printing
_______________________________________________
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