Cocos2D 2.0 possible regression with CCMenuItem and CCMenuAdvanced/CCMenu.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Click on CCMenuItem of a CCMenu subclass (CCMenuAdvanced).
2. Perform scene transition.
3. Click on the former menu again.

What is the expected output? What do you see instead?
I would expect the scene transition to happen, but the menu can only be 
scrolled around and the items clicking does not produce any effect.

What cocos2d version / SVN revision are you using ?
Latest Cocos2D 2.0 release.

What iPhoneSDK are you using ?
iOS 5.1 Beta 2

Debug or Release ?
Both.

Does this happens on device ? or on the simulator ? or on both ?
Both.

Please provide any additional information below.

I am seeing a strange issue with the CCMenuAdvanced Cocos2D extension which I 
cannot really explain right now. Considering the application worked well, 
CCMenuAdvanced included, with Cocos2D 2.0 just a little over a week ago, I'd 
say that OpenGL ES 2.0 is not the culprit. Also, CCMenuAdvanced is a neat and 
useful improvement, but it is still based on CCMenu.

Let me give you a bit of background:
One of the CCMenuAdvanced objects is used as a scrolling horizontal menu to 
switch between the app's "pages" like a visual index. You click on one of the 
CCMenuItems and the app transition from one scene to the next. This scenesMenu 
is added to the scene and removed from the scene, but allocated only once and 
destroyed when the app is terminated. Its CCMenuItems are not retained, but are 
added dynamically to the CCMenuAdvanced after the menu has been allocated and 
initialized. Checking down to the CCNode code it uses, it seems to retain the 
added items.

Well, what's happening with the latest Cocos2D 2.0b2 release (Github) is that 
when you click on the menu in question and the transition occurs, it won't 
occur again when you click the menu again the next time you bring it up and it 
is added to the scene. 

This is a video which shows the issue in action:

http://www.youtube.com/watch?v=BxJj4PWMTBA

This is how the menu in question is created:

`
scenesMenu = [[CCMenuAdvanced menuWithItems:nil] retain];
        scenesMenu.priority = kCCMenuTouchPriority-1;

        for (int i = 0; i < 9; i++) {
            NSString * tempString = [NSString stringWithFormat:@"CommonResources/Menu_sprite/Pag%d_menu.pvr", (i+1)];
            CCMenuItem * temp = [CCMenuItemImage itemWithNormalImage:[[SysTools sharedInstance] deviceFile:tempString]
                                                       selectedImage:nil
                                                       disabledImage:[[SysTools sharedInstance] deviceFile:@"CommonResources/button_disabled.png"]
                                                              target:self selector:@selector(indexMenuClicked:)];
            //temp.scaleY = -1.0f;
            temp.userData = [NSNumber numberWithInt:i];
            [scenesMenu addChild:temp];
        }
        [scenesMenu alignItemsHorizontally];

        scenes = [delegate scenes];
`
This is how the menu in question is added to the scene and removed from the 
scene:

`
if (state == INDEX_ON && !indexShowing) {
            CMLog(@"Adding index...");
            [self setupIndexMenu];
            [scenesMenu alignItemsHorizontallyWithPadding:0];
            [cocosLayer addChild:scenesMenu z:49];
            [scenesMenu setVisible:YES];
            indexShowing = YES;

            scenesMenu.scale = 0.1;
            id scale = [CCSequence actions: [CCScaleTo actionWithDuration:.4 scale:0.9f], nil];
            [scenesMenu runAction: scale];
        }
        else if (state == MENU_OFF && indexShowing ) {
            CMLog(@"Removing index...");
            [scenesMenu setVisible:NO];
            [scenesMenu removeFromParentAndCleanup:YES];
            indexShowing = NO;
        }
`
Again... this was working with Cocos2D 2.0 just a week or so ago :(...

Original issue reported on code.google.com by Pana...@gmail.com on 8 Jan 2012 at 10:19

[GoogleCodeExporter]

Situation fixed on my end or at least I have found a workaround. I am attaching 
the fixed MenuIndex.mm file in question so that it can be compared with the 
other one I already sent before.
The changes are minor, but have an important effect on the application. Blocks 
triggered an issue in what probably was a not too safe behavior even before. 
The CCMenuItem elements, if you look at the old code, have the target set to 
MenuIndex's singleton instance through the "self" reference. In the old code I 
initialize the CCMenuItem elements when I create the MenuIndex in the App 
delegate while in the new code I do that when I add the menu to the currently 
displayed "page" (removing the pages menu's childrens from their parent and 
that menu itself from its parent).

It seems like the old way should have kept working... what do you think?

Original comment by Pana...@gmail.com on 10 Jan 2012 at 11:27

Attachments:

• MenuIndex.mm

[GoogleCodeExporter]

Original comment by ricardoq...@gmail.com on 10 Jan 2012 at 11:44

• Added labels: Component-Menu, Milestone-Release2.0

[GoogleCodeExporter]

Resubmitted MenuIndex files. There was an issue left with the menu misbehaving 
when shown and hidden without using it to transition between pages.

I am sorry for a confusing post last night, I will try to clarify what I meant 
better soon.

Original comment by Pana...@gmail.com on 11 Jan 2012 at 11:49

Attachments:

• MenuIndex.zip

[GoogleCodeExporter]

I have done a few more test on the original version of my MenuIndex class which 
I have attached to this comment.

[scenesMenu removeFromParentAndCleanup:YES]; --> changing that flag to NO when 
I wanted to hide scenesMenu and inserting the same kind of statement in the 
-removeMenu method does fix the issue in the original class that sparked this 
code issue. In that file I used to add and remove the scenesMenu layer each 
time the menu would be shown and hidden, but not when a transition occurred 
basically.

Original comment by Pana...@gmail.com on 15 Jan 2012 at 10:18

Attachments:

• MenuIndex_old_bugged.mm

[GoogleCodeExporter]

@Panajev: So, I can close this bug as "invalid", right ?

Original comment by ricardoq...@gmail.com on 21 Jan 2012 at 12:09

[GoogleCodeExporter]

@riq: Yes, I think it is the best thing to do for now. Still, if the use of the 
cleanup flag is marked as "work as intended", I think this should be reflected 
in the documentation better. The code, the original code, stopped working when 
CCMenu items were changed... although perhaps the original code should have 
never worked well to begin with.

Original comment by Pana...@gmail.com on 25 Jan 2012 at 8:46

[GoogleCodeExporter]

Ok. Closing bug. I will update documentation.

Original comment by ricardoq...@gmail.com on 25 Jan 2012 at 10:24

• Changed state: Invalid