Quote:
Originally Posted by anils_das
Issue: Touches are no longer forwarded to a UIScrollView in 3.0. ... how can we solve that?
|
The answer is, you must handle touch events in the subview and modify the behavior of the scroll view by setting its canCancelContentTouches and delaysContentTouches flags appropriately.
When delaysContentTouches is set to YES, no event is sent to your subView until it can be determined that it is NOT a scroll gesture. Thus this flag always causes a delay (unless you tap very quickly).
With delaysContentTouches set to NO, the event is sent immediately to your subview. If canCancelContentTouches is set to YES then any gesture that is "scrolly enough" will (by default) cancel events to your subview and initiate scrolling. If canCancelContentTouches is set to NO then no scrolling will occur, no matter what gesture occurs.
With canCancelContentTouches set to YES you can use the touchesShouldCancelInContentView method in your UIScrollView subclass to allow or disallow scrolling based on whatever criteria you want. For example, if you only want to allow scrolling when a finger swipe is mostly vertical, but not if it's at or under 45°, you can test for this in your subView's touch processing and set the value of a BOOL variable that touchesShouldCancelInContentView can return.
This should work in theory, though I haven't fully implemented it yet. It may happen that a swipe at 10° will cause scrolling to start before the subView can determine that the angle is too oblique (or too obtuse, for that matter).
The delaysContentTouches flag causes the scrollView to start a timer when it's first touched, and when the timer runs out it either scrolls its contents or starts streaming events to the subview. (A sufficiently scrolly gesture will also cancel the timer and start scrolling.) Unfortunately there's no documented way to change the duration of the timer or to implement your own scroll-worthy test in your UIScrollView subclass, so the only option seems to be what I've outlined.
