UIKit Subviews Stealing Touch Events

UIKit Subviews Stealing Touch Events
0.0 0


Hi guys,

I’ve traced, researched, and debugged this for days now and can’t seem to knock it down. I have a custom UITextView that I’m creating, and adding to the scene via:

[[EAGLView sharedEGLView] addSubview: textView];

Everything is working pretty great, except when the UITextView becomes the first responder, and the keyboard is present, cocos2d-x no longer receives any touch events. I’ve studied in depth into the responder chain, hit tests, etc, but I can’t find a way to get events delivered to the cocos2d-x setup while the keyboard is active. When the UITextView calls resignFirstResponder, the keyboard is dismissed, and everything goes perfectly back to normal. I’m pretty sure this is a view-level thing, because I’ve set breakpoints in CCTouchDispatcher, and they aren’t being triggered. I can add a UITapGestureRecognizer to the sharedEGL view and it detects gestures. I’ve tried to enable the main view to become a first responder, to no great effect.

The custom UITextView is HPGrowingText (https://github.com/HansPinckaers/GrowingTextView/tree/master/class), and it doesn’t seem to be anything too out of the ordinary. I’ve swapped it with a normal UITextView and the issue still remains. When it gets into the intricacies of cocos2d-x/UIKit plumbing, I’m a bit over my head, and would appreciate any leads or gut-feeling pointers.


iOS Simulator Screen shot Sep 10, 2012 8.33.16 PM.png (86.7 KB)


Turns out, touches are explicitly not processed if the keyboard is shown; in EAGLView.mm:

- (void) touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event

    if (isKeyboardShown_)
        [self handleTouchesAfterKeyboardShow];
    // ....

I assume this was to avoid weird interactions with CCEditBox, etc. I’m curious if it’d be worthwhile to track when the shown keyboard is one handled by Cocos2d-x in this situation, or if that is even the intent of the restriction.