We are working on a game in cocos2d in which there is a possibility of getting a trivia question. The trivia question is implemented as a new, transparent CCLayer on top of the gameboard, which contains a CCMenu with all of the questions.
Our problem is that we can't seem to get the touches to stop propagating properly. When the trivia menu is up, players should not be able to click on the "roll dice" button on the board layer.
We have tried implementing this by calling dice.isTouchEnabled=NO; right before adding the trivia layer, but we can't figure out how to re-enable the dice button.
We also tried changing ccTouchBegan from NO to YES to always consume all of the touches, but then it stops responding to our menu. It seems that this should be the right way to do it, but why did the menu stop responding then?
Our professor suggested implementing a callback function, which we of course can do, but it seems like it should be easier than that.
Does anyone have any suggestions?
I understand that there are two ways to do this.
Method 1 (method that I am using)
Before trivia question pops up, use the function below to disable menus on the Underlying Scene node. The method is a recursive method so it disables all menus on the node's children too.
When the trivia question is dismissed, send an NSNotification which will be received by the Underlying Scene node and will re-enable menus on the node and its children. You can use the block method of NSNotification to shorten your code.
Docs on addObserverForName:object:queue:usingBlock:
(void) MenuStatus:(BOOL)_enable Node:(id)_node {
for (id result in ((CCNode *)_node).children) {
if ([result isKindOfClass:[CCMenu class]]) {
for (id result1 in ((CCMenu *)result).children) {
if ([result1 isKindOfClass:[CCMenuItem class]]) {
((CCMenuItem *)result1).isEnabled = _enable;
}
}
}
else
[self MenuStatus:_enable Node:result];
}
}
Method 2
Create an invisible layer that will swallow all touches below the Trivia Question layer. Here is a class you can try: https://gist.github.com/christophercotton/1563708
Related
Is there a way to begin a UIPanGestureEvent if the finger is already pressed at the time the object is instantiated?
I have a situation where when a user holds their find on a screen I create a UIView under their finger.
I want them to be able to drag that around and as such I have put a UIPanGestureRecognizer inside the UIView.
Problem is I need to take my finger off and put it back to trigger the UIPanGestureRecognizer to start up. I need it to start from an already pressed state.
Do you know how I can activate a UIPanGesture from an already pressed state i.e. can I get the touch event thats already active at the time of instantiation and pass it along?
You can do it, but the UIPanGestureRecognizer will need to exist already on the view behind the view you create (and you will then have to adjust your calculations based on this; not difficult).
The reason is that, under the circumstances you describe, the touch does not belong to the UIView you create - it belongs to the UIView behind it, the one that the user was originally touching. And given the nature of iOS touch delivery, you can't readily change that. So it will be simpler to let that view, the actual original touch view, do the processing of this touch.
I think Matt's solution is best so I am going to mark it as correct.
However my code structure wasn't going to allow me to cleanly implement it. Compounding the issue was the object listening was listening for a UILongGestureRecognizer.
So my solution was as follows:
Create a callback in my ViewController that would handle the longGestureOverride call
Add a callback to the object listening for the longGesture that would call the longGestureOverride callback and pass along the point
Manually move the object based on the point passed back
If the user lifts their finger, I disable the longGestureOverride callback, and begin using the UIPanGesture inside the new object
I've found a peculiarity with Cocos2D and I cannot seem to fix it. From the AppDelegate I load into a Menu, which is a CCScene. The scene holds a CCLayer, which itself holds the CCMenu. Everything works find the first time through. After my game has ended, I bring the user to a GameOverScene and prompt them to return to the menu. I am reloading the menu scene and calling [[CCDirector sharedDirector] replaceScene:menu]. After entering this menu, though, not all input functions. I can no longer tap on menu items, but I can pan / multi-touch on them to trigger the item. What gives?
Is there some way on initialization to reset the CCScene to receive input, and if so, will this mess up CCMenu's input receiving?
Did you override any of the on* methods like onEnter, onExit, etc. in any of your classes?
If so, you must call the super implementation (ie [super onEnter]) in each, otherwise some cocos2d functionality like scheduling or input may stop working.
I finally figured it out, and the answer was right under my nose. Earlier in my game development I needed a way to stop KKInput from swallowing gestures. I'm not entirely sure of the ramifications of this action, but I was able to do so like this:
KKInput* input = [KKInput sharedInput];
UITapGestureRecognizer* tapGestureRecognizer;
tapGestureRecognizer = input.tapGestureRecognizer;
tapGestureRecognizer.cancelsTouchesInView = NO
It seems that the default Kobold2D behavior is to swallow all touches, which was preventing the CCMenu from receiving any tap gesture.
When I demo my touch apps to remote teams the people on the other end dont know where I am touching. To remedy this, I have been working on an event intercepting view/window that can display touches over applications. No matter how may variations on nextResponder I call, I am unable to react to the touch and pass it along to the controllers underneath. Specifically scroll views dont react nor do buttons.
Is there a way to take an event, get its position, then pass it along to what ever component would have been responding to it initially (the controller underneath)?
Update:
I am making some progress with a UIView. The new view is always returning NO to pointInside.This works great for when the touch starts, but it doesnt track moves or releases. Is there a strategy to adding gesture recognizers to the touch in order to track its event lifecycle?
Joe
You could try creating your own subclass of UIApplication that overrides sendEvent:. Your implementation should call [super sendEvent:event] as well as process the event as needed.
Update your main.m and pass the name of you custom UIApplication class as the 3rd parameter to the call of UIApplicationMain.
After some more due diligence, I found my oversight. In the layer that was on top and displaying the touches, user interaction needed to be set to false. Once I set that to false, I was able to use that layer for display while catching events on the layers below. The project still isn't done but I am one step closer.
Take care,
Joe
I have a simple lunar lander game.
I compute positions and everything by integration - e.g. each turn I take vectors and combine them and then apply resulting vector to my lander.
Here comes the question, I have a button that I want to use for thrust.
How do I check if it is on during update method? I guess i will have some BOOL flag that gets set to YES when the button is pressed, but when do i set it to NO?
Some practical implementation would be great.
I use cocos2d-iphone and iOS.
Well, the pseudo code goes as follows:
We shall not use Buttons (aka CCMenuItem), since they provide callbacks only on touch up events. We want touch down, touch exit/entered, touch ended.
In your CCScene that you are displaying, either add a new child that is a subclass of CCLayer or even use one of the CCLayers already present in the CCScene.
In the init of your CClayer subclass, set isTouchEnabled to YES.
Implement the usual methods:
- (void)ccTouchesBegan:...
- (void)ccTouchesMoved:...
- (void)ccTouchesEnded:...
- (void)ccTouchesCancelled:...
Finally, do your magic in these methods.
Get the touch location
Check using CGRectContainsPoint whether the touch is within the thrust area.
and so on, and so forth...
I'm trying to handle touch events with touchesBegan in an overlay to a parent UIView but also allow the touch input to pass through to sibling UIViews underneath. I expected there would be some straight-forward way to process a touch event and then say "now send it to the next responder as if this one didn't exist", but all I can find is the nextResponder method which appears to be giving back the parent to my overlay view. That parent is then not really passing it onto the next sibling of that overlay view so I'm stuck uncertain how to do what seems like a simple task that is usually accomplished with a touch callback that gets a True or False return value to tell it whether to keep processing down the widget hierarchy.
Am I missing something obvious?
Late answer, but I think you would be better off overriding hitTest:withEvent: instead of touchesBegan. It seems to me that touchesBegan is a pretty "high-level" method that is there to just do a simple thing, so you cannot alter at that level if the event if propagated further. The right place to do that is hitTest:withEvent:.
Also have a look at this S.O. answer for more details about this point.
I understand the desired behavior you're looking for Joey - I haven't found something in the API that supports this automatic messaging-up-the-chain behavior with sibling views.
What I originally wrote below was with respect to just informing a parent UIView about a touch. This still applies, but I believe you need to take it a step further and have the parent UIView use the hit testing technique that Sergio described on each of it's subviews that are siblings to the overlay, and have the parent UIView manually invoke a "do something" method on each of it's subviews that pass the hit test. Each of those sibling views can return a BOOL value on whether to abort informing other siblings or continue the chain.
If you find yourself using this pattern a lot, consider adding a category method on UIView that encapsulates the hit testing and asking views to perform a selector.
My Original Answer
With a little bit of manual work, you can wire this together yourself. I've had to do this, and it worked for me, because I had an oft-repeated use case (an overlay view on a button), where it made sense to create some custom classes. If your situation is similar, one of these techniques will suffice.
Option 1:
If the overlay doesn't need to do anything but look pretty, have it opt out of touch handling completely with userInteractionEnabled = NO. This will make it so that the touch event goes to it's parent UIView (the one it is an overlay to).
Option 2:
Have the overlay absorb the touch event (as it would by default), and then invoke a method on the parent UIView indicating that a touch or certain gesture was recognized, and here's what it is. This way, the UIView behind the overlay still gets to act on the touch recognition, even if someone else did the interception.
With Option 2, it's more a fit for simple UIControlEvent types, like UIControlEventTouchDown and UIControlEventTouchUpInside. In my case (a custom UIButton subclass with a custom overlay view on top of it), I'll wire touch down and touch up events on the button to two separate methods. These fire if a touch down or touch up inside event occurs on the button itself. But, they are also hooks I can invoke from the overlay view if I need to simulate that a button press occurred.
Depending on your needs, you could have a known protocol between the overlay and it's parent UIView or just have the overlay test the UIView informally, with a respondsToSelector: check before invoking performSelector: on it with the custom method you want called that would have fired automatically if the UIView wasn't covered by an overlay.