In my Cocos2d 2.0 iOS game, I use a CCMenuAdvanced to create a scrolling menu. The problem is that the invisible portion of the menu also seems to be handling touches.
Here is the code (needed to get boundaryRect to display and crop properly):
// background is full screen, with all pixels transparent
// except the part where menu shows
CCSprite *menuBackground = [CCSprite spriteWithFile:@"scrollingmenubackground.png"];
//...
[self addChild:menuBackground];
//...
//create menu items
CCMenuAdvanced *settingsMenu = [CCMenuAdvanced menuWithItems:item1, item2, item3, nil];
//...
[menuBackground addChild:settingsMenu];
// foreground is full screen, with an image
// with a transparent hole where the menu shows
CCSprite *foreground = [CCSprite spriteWithFile:@"scrollingmenuforeground.png"];
[menuBackground addChild:foreground];
//...
Now this works fine, and the menu displays, is cropped correctly and handles touches. However, the problem is that when I click below the visible menu, it still handles the touches on the menu, even though there is a sprite with non-transparent pixels ahead of it (foreground).
I have tried fiddling with the zorder by setting the foreground with a higher zorder than the menu but that doesn't seem to change anything.
menuBackground.zOrder = 1;
settingsMenu.zOrder = 2;
foreground.zOrder = 3;
I also tried setting the menu priority to INT_MIN as well as kCCMenuHandlerPriority - 1, but no effect.
How do I get the menu to only respond in the portion that is visible to the user?
Thanks Anand
To have an effective 'mask', you should use a layer with touch enabled as foreground. In that layer, you can accept touches outside the menu, and do nothing with them, and pass those inside the mask. However, this will cause issues : if the touchBegan inside the mask, and the user drags its finger outside, the menu will still continue scrolling. You can either subclass CCAdvancedMenu to implement your own touch processing requirements, or create your own version of it. I ended up doing the latter because my game designer wanted many other features from it and subclassing became a hindrance rather than a help. BTW, dont rely on zOrder for the touch processing, they are not related.
Also, the 'touch mask' approach will probably come back and haunt you later on (for example if you add other objects alongside your scrolling menu that also need touch, the touches will be masked out), it would be best if all your objects that are concerned with implementing touch related requirements encapsulate their own implementation.