I'm working on an app the builds a lot of stacked views dynamically and I initially had event handling problems described here. That post solved most of my problems but I still have one issue. When a user clicks on a summary of an rss feed item, I create an almost-full screen web view with just a single "close" button. The close button works but the web view refuses to scroll. I use a variation on the code described in the the above link that is meant to work for "screens" and "gadgets" on those screens where the screens are always 1024x768 but never need to deal with events but other views and buttons on those screens do deal with events. A "screen" has a base template that never changes and another "screen" on top that does change. The code to handle the "gadget" event dispatching is:
@implementation ContainerView
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event {
for (int i=self.subviews.count-1; i >= 0; i--) {
UIView *view = [self.subviews objectAtIndex:i];
BOOL isContainerView = [view isMemberOfClass:[ContainerView class]];
if (isContainerView) {
return [super hitTest:point withEvent:event];
}
else {
CGPoint viewPoint = [view convertPoint:point fromView:self];
if ([view pointInside:viewPoint withEvent:event]) {
return view;
}
}
}
return nil;
}
@end
This correctly dispatches events to "Btn 1" and "Btn 2" (see diagram). I also see that this same code returns my UIWebVIew when I try to scroll it but it still doesn't scroll. The following is a diagram of how the views stack up:
Maybe UIWebView scrolling is handled in some special way that circumvents the hitTest hacking?
I sent a support email to Apple about this and all they could really say was "UIWebView does a lot of custom touch handling that makes it elusive to catch with hitTest". So, if you have this situation and want to use this hitTest override solution, don't expect it to work for UIWebView. In may case, I'm probably going to have to make some design changes to not stack my views this way.