Disable touches on UIView background so that buttons on lower views are clickable

Question

Basically, here is my view hierarchy (and I appologize if this is hard to read... I'm new here so posting suggestions happily accepted)

--AppControls.xib
-------(UIView)ControlsView
----------------- (UIView)TopBar
----------------- -------------- btn1, btn2, btn3
----------------- UIView)BottomBar
----------------- --------------slider1 btn1, btn2
--PageContent.xib
----------------- (UIView)ContentView
----------------- --------------btn1, btn2, btn3
----------------- --------------(UIImageView)FullPageImage

My situation is that I want to hide and show the controls when tapping anywhere on the PageContent thats not a button and have the controls show, much like the iPhone Video Player. However, when the controls are shown I still want to be able to click the buttons on the PageContent.

I have all of this working, except for the last bit. When the controls are showing the background of the controls receives the touch events instead of the view below. And turning off user interaction on the ControlsView turns it off on all its children.

I have tried overriding HitTest on my ControlsView subclass as follows which I found in a similar post:

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event{
UIView *hitView = nil;
NSArray *subviews = [self subviews];
int subviewCount = [subviews count];
for (int subviewIndex = 0; !hitView && subviewIndex < subviewCount; subviewIndex++){
hitView = [[subviews objectAtIndex:subviewIndex] hitTest:point withEvent:event];
}   
return hitView;
}

However, at this point my slider doesn't work, nor do most of the other buttons, and really, things just start getting weird.

So my question is in short: How do I let all the subviews of a view have touch events, while the super view's background is unclickable, and the buttons on views below can receive touch events.

Thanks!

score 76 · Accepted Answer · edited Aug 09 '12 at 19:58

76

You're close. Don't override -hitTest:withEvent:. By the time that is called, the event dispatcher has already decided that your subtree of the hierarchy owns the event and won't look elsewhere. Instead, override -pointInside:withEvent:, which is called earlier in the event processing pipeline. It's how the system asks "hey view, does ANYONE in your hierarchy respond to an event at this point?". If you say NO, event processing continues below you in the visible stack.

Per the documentation, the default implementation just checks whether the point is in the bounds of the view at all.

Your strategy is to say "yes" when any of your subviews is at that coordinate, but say "no" when the touch would be hitting the background.

- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
    for (UIView * view in [self subviews]) {
        if (view.userInteractionEnabled && [view pointInside:[self convertPoint:point toView:view] withEvent:event]) {
            return YES;
        }
    }
    return NO;
}

edited Aug 09 '12 at 19:58

Community

1
1

answered Aug 06 '10 at 20:44

Ben Zotto

70,108
23
141
204

1

You're welcome. I fought with this same issue for many hours once. Happy to help. – Ben Zotto Aug 06 '10 at 21:25
By the way, is that more or less a propper way to graph display hierarchy? Or is there a standard practice? – averydev Aug 06 '10 at 21:28
6

Sure. :) I don't see display hierarchies modeled so completely on SO very often, but it's useful to see it like that. FYI, here's a fun debugging tip: in gdb when stopped at a breakpoint, try running `po [myView recursiveDescription]`. It dumps out the whole hierarchy from that point down. – Ben Zotto Aug 06 '10 at 21:39
Holy cow. Thats a whole other world of debugging goodness. Thanks for the heads up! – averydev Aug 08 '10 at 00:43
1

This answer put an end to a long, tortuous journey to allow for overlapping views to handle the events. Thank you so much. – supertodda Dec 02 '10 at 23:09
1

Brilliant. Thanks a lot. I wonder how come such a simple behavior isn't already part of UIKit. – Ben G Mar 03 '12 at 16:35
1

Note - this may behave in unexpected ways if a child extends beyond the boundary of the parent and the CGpoint is in the child but outside the parent. A quick test shows that w/ stock behavior, such a point is considered outside, but with this modification it's considered inside. i don't have room for the code in the comments here, so i'll post another answer. – orion elenzil Sep 13 '12 at 15:20
1

Great solution. I would recommend adding a `!view.hidden` clause to the if-statement, to avoid hidden views consuming the touch. – William Denniss Oct 14 '13 at 03:31

score 11 · Answer 2 · edited Dec 20 '17 at 01:13

11

Thanks to @Ben Zutto, Swift 3 solution:

override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
    for view in self.subviews {
        if view.isUserInteractionEnabled, view.point(inside: self.convert(point, to: view), with: event) {
            return true
        }
    }

    return false
}

edited Dec 20 '17 at 01:13

Stleamist

193
2
12

answered Nov 25 '16 at 13:11

Roman Barzyczak

3,785
1
30
44

1

or `return subviews.first { $0.isUserInteractionEnabled && $0.point(inside: convert(point, to: $0), with: event) } != nil` – Alexandre G Jul 04 '18 at 02:29
note: in order for this to work properly the parent's User Interaction also needs to be enabled – Merricat Jul 07 '19 at 23:38

score 1 · Answer 3 · answered Sep 13 '12 at 15:23

A slight variant on Ben's answer, dealing w/ children which extend outside their parent. If clipChildren is YES, then this will not return YES for points which are outside the main control but inside some child. if clipChildren is NO, this is the same as Ben's.

- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event
{
    BOOL clipChildren = YES;

    if (!clipChildren || [super pointInside:point withEvent:event]) {
        for (UIView * view in [self subviews]) {
            if (view.userInteractionEnabled && [view pointInside:[self convertPoint:point toView:view] withEvent:event]) {
                return YES;
            }
        }
    }
    return NO;
}

score 1 · Answer 4 · answered Nov 04 '11 at 08:43

1

Another approach may be to have an invisible full-screen button behind everything else, and take appropriate action when it is hit.

answered Nov 04 '11 at 08:43

P i

29,020
36
159
267

2

That sounds like a terrible idea. – Brandon Zacharie Aug 24 '17 at 01:00

Disable touches on UIView background so that buttons on lower views are clickable

4 Answers4

Linked