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:
diagram
Maybe UIWebView scrolling is handled in some special way that circumvents the hitTest hacking?
