On Jun 6, 2010, at 2:09 AM, glenn andreas wrote: > On Saturday, June 05, 2010, at 05:51PM, "WT" <jrca...@gmail.com> wrote: >> I need to hijack the set of touch events sent to a UITableView instance >> prior to allowing the table to process those events. >> >> I have a custom UIView, of which the table view is a subview, and I override >> -hitTest:withEvent: there (in the custom view) to return self, thereby >> preventing the table from receiving those touches. >> >> Since my custom view does not implement any of the four event-handling >> methods (-touchesBegan:withEvent:, etc), the view controller managing my >> custom view gets the touches, through the regular traversal of the responder >> chain. >> >> There, in the view controller event-handling methods, I determine whether or >> not I need to consume the events. If not, I need to send them back to the >> table view for it to do its normal event handling (for instance, scrolling). >> >> All of the above works fine, except... > > > Probably not as "fine" as you expect - UIViews are not designed to support > UIEvents forwarded to them except under very controlled conditions. From > <http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/EventHandling/EventHandling.html#//apple_ref/doc/uid/TP40007072-CH9-SW17>: > > "The classes of the UIKit framework are not designed to receive touches that > are not bound to them; in programmatic terms, this means that the view > property of the UITouch object must hold a reference to the framework object > in order for the touch to be handled. If you want to conditionally forward > touches to other responders in your application, all of these responders > should be instances of your own subclasses of UIView." > > That document contains a number of suggestions on how to approach those sort > of design issues...
Yes, I'm aware of that recommendation. I think that's precisely the core of my question, namely, how to do what I need to do in the safest possible way. I found a solution, but I don't think it's very elegant: I subclassed UITableView and, in that subclass, I implement the 4 event methods to call their namesakes in the tableview's superview. Since that superview doesn't implement those methods (it's a regular UIView, not a custom view), its view controller gets the calls (through the normal traversal of the responder chain). There I do the analysis to decide whether or not to consume the touches. If not, then I call "fake" event methods in the tableview's subclass, each of which invokes the super version of the true event methods. It works like a charm, but it's not very elegant, in my opinion._______________________________________________ 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
