Search Results

Search found 5 results on 1 pages for 'bogatyr'.

Page 1/1 | 1 

  • Presenting UINavigationController modally -- problem setting up tool and nav bar items in root view controller viewDidLoad

    - by Bogatyr
    In my iOS app I'm creating and presenting a UINavigationController modally like so: MyViewController *myvc = [[[MyViewController alloc] initWithNibName:@"MyViewController" bundle:nil] autorelease]; UINavigationController *navVC = [[[UINavigationController alloc] initWithRootViewController:myvc] autorelease]; [self presentModalViewController:navVC animated:YES]; In the MyViewController viewDidLoad I'm creating and setting toolbar items for the navigation controller's toolbar, like so: self.navigationController.toolbar.items = [NSArray arrayWithObjects:(items...), nil]; the problem I'm having is that the items don't show up. If instead I call a method from MyViewController's viewDidLoad method that adds the toolbar items via performSelector:withObject:afterDelay:0, then it works perfectly. So there's obviously some race condition going on here with the initial presentation of the UINavigationController, initialization of its toolbar/navbar, and the initialization of the nav bar's specified initial root view controller. I verified in the debugger that the root view controller's viewDidLoad is called after the UINavigationController's viewDidLoad method. In fact, the root view controller's viewDidLoad method is not called until presentModalViewController: is called, and the UINavigationController's viewDidLoad is called within initWithRootViewController, so doesn't that imply that the UINavigationController object should be "all ready to go", including its nav bar and toolbars? I thought at first that the navigation controller's toolbar object may not exist yet at MyViewController's viewDidLoad time, but it clearly does. At least, NSLog shows that it is not nil during MyViewController's viewDidLoad method. In fact, the UINavigationController's toolbar object is identical at both times: in the root view controller's viewDidLoad, and in the "setupToolbar" method that I called with performSelector:withObject:afterDelay, so it's not getting "re-initialized" somehow. So, what's going on here? Why aren't my toolbar modifications "sticking" in MyViewController's viewDidLoad, and why does performing them in the next iteration of the runloop (performSelector:withObject:afterDelay:0) make it work? What is the "right" way of setting up initial navbar / toolbar items in code from the rootViewController of the UINavigationController?

    Read the article

  • Gap appears between navigation bar and view after rotating & tab switching

    - by Bogatyr
    My iphone application is showing strange behavior when rotating: a gap appears between the navigation title and content view inside a tab bar view (details on how to reproduce are below). I've created a tiny test case that exhibits the same problem: a custom root UIViewController, which creates and displays a UITabBarController programmatically, which has two tabs: 1) plain UIViewController, and 2) UINavigationController created programmatically with a single plain UIViewController content view. The complete code for the application is in the root controller's viewDidLoad (every "*VC" class is a totally vanilla UIViewController subclass with XIB for user interface from XCode, with only the view background color changed to clearly identify each view, nothing else). Here's the viewDidLoad code, and the shouldAutorotateToInterfaceOrientation code, this code is the entire application basically: - (void)viewDidLoad { [super viewDidLoad]; FirstVC *fvc = [[FirstVC alloc] initWithNibName:@"FirstVC" bundle:nil]; NavContentsVC *ncvc = [[NavContentsVC alloc] initWithNibName:@"NavContentsVC" bundle:nil]; UINavigationController *svc = [[UINavigationController alloc] initWithRootViewController:ncvc]; NSMutableArray *localControllersArray = [[NSMutableArray alloc] initWithCapacity:2]; [localControllersArray addObject:fvc]; [localControllersArray addObject:svc]; fvc.title = @"FirstVC-Title"; ncvc.title = @"NavContents-Title"; UITabBarController *tbc = [[UITabBarController alloc] init]; tbc.view.frame = CGRectMake(0, 0, 320, 460); [tbc setViewControllers:localControllersArray]; [self.view addSubview:tbc.view]; [localControllersArray release]; [ncvc release]; [svc release]; [fvc release]; } - (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation { return YES; } Here's how to reproduce the problem: 1) start application 2) rotate device (happens in simulator, too) to landscape (UITabBar properly rotates) 3) click on tab 2 4) rotate device to portrait -- notice gap of root view controller's background color of about 10 pixels high beneath the Navigation title bar and the Navigation content view. 5) click tab 1 6) click tab 2 And the gap is gone! From my real application, I see that the gap remains during all VC push and pops while the NavigationController tab is active. Switching away to a different tab and back to the Nav tab clears up the gap. What am I doing wrong? I'm running on SDK 3.1.3, this happens both on the simulator and on the device. Except for this particular sequence, everything seems to work fine. Help!

    Read the article

  • How can I get the mapi system stub dll to pass extended mapi calls to my dll?

    - by Bogatyr
    For various reasons (questioning the reasons is not helpful to me), I'd like to implement my own extended mapi dll for windows xp. I have a skeleton dll now, just a few entrypoints exist for testing, but the system mapi stub (c:\windows\system32\mapi32.dll, I've checked that it's identical to mapistub.dll) will not pass through calls to my dll, while it happily passes the same calls through to MS Outlook's msmapi32.dll, (MAPIInitialize, MAPILoginEx are two such calls). There's some secret handshake between the stub and the extended mapi dll wherein the stub checks that "yup, it's an extended mapi dll": maybe it's the presence of some additional entrypoints I haven't implemented yet, maybe it's the return value from some function, I don't know. I've tried tracing a sample app I wrote that calls MAPIInitialize with STraceNT and ProcessMonitor but that didn't show anything obvious. Tracing has shown that indeed the stub loads my dll, but then finds the secret sauce is missing apparently, and returns an error code instead of calling my dll's function. What more could be needed for calling MAPIInitialize than the presence of MAPIInitialize in my dll's exports table? GetProcAddress says it's there. What I'd like to know is how to minimally extend my skeleton extended mapi dll so that the stub mapi dll will pass through extended mapi calls to my dll. What's the secret sauce? I'd rather not spend a painful week in msvc reverse engineering the stub behavior.

    Read the article

  • Increase the length of Xcode's "recent project" list?

    - by Bogatyr
    I switch in Xcode between working on a lot of different projects frequently (some I'm actively working on, some are old projects where I'm looking up code I want to re-use or quote in SO answers :)), so that part of my "working set" of projects invariably ends up falling off the recent project list. I do use finder tabs for the full working set of current project folders, but I really like the fast switching available using the recent projects list. Is there a way to increase the length of this list so that I can see more recently opened projects?

    Read the article

1