Hi Michael,

thanks for replying to my message.

I'm not 100% certain, but I believe this delegate method is new in iPhone OS 3.0 (couldn't find it in the 2.2.1 docs). The project you put together also specifies the iPhone 3.0 SDK. I don't believe it is kosher to speak of these things on the list at this point, but we can easily switch to using the iPhone OS 2.2.1 SDK and substitute the -tabBarController:didSelectViewController: delegate method in their place.

Oops... indeed. My apologies. I'll remove the 3.0 sample project as soon as I finish this message.

I suspect that the problem is that your view controllers (Game and Settings) are left in a "confused" state, with their parent view controller still referring to the removed and released UITabBarController. Since the parentViewController and tabBarController properties of the UIViewController are read-only, you can attack this from the other end by removing them from the UITabBarController's list of viewControllers before releasing it. Like so:

- (void)tabBarController:(UITabBarController *)tab_bar_controller
didSelectViewController:(UIViewController *)newVC
{
   if (newVC == gameViewController)
   {
       [tabBarController.view removeFromSuperview];
       [window addSubview: gameViewController.view];
                
NSMutableArray *tabViewCtlrs = [[tabBarController viewControllers] mutableCopy];
        [tabViewCtlrs removeObject:gameViewController];
        [tabViewCtlrs removeObject:settingsViewController];
        [tabBarController setViewControllers:tabViewCtlrs];
        [tabViewCtlrs release];
        tabViewCtlrs = nil;

       [tabBarController release];
        tabBarController = nil;
   }
}

In my modified copy of your sample project, this change seems to do the trick.

Yes, on further investigation, I noticed that the settings view controller had its parentViewController set to the tab-bar controller instance, which was still alive and well. Clearly, an UIViewController instance retains its parent controller. Oddly enough, there doesn't seem to be a direct way to detach a former modal view controller from its parent. I assumed that calling -presentModalViewControler would reset the properties accordingly, but obviously that's not the case. If only parentController was writable...

Anyway, there's a simpler solution than yours, though along the same lines. Since I'm going to kill the tab-bar controller anyway, I can simply set its viewControllers property to nil before releasing the tab-bar controller.

Thanks again for your help.

Wagner
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to