views:

580

answers:

4

UPDATE: This is apparently "works as intended" classed by Apple. See accepted answer below for details.

Update: this question is about a behavior discovered in the iPad keyboard, where it refuses to be dismissed if shown in a modal dialog with a navigation controller.

Basically, if I present the navigation controller with the following line:

navigationController.modalPresentationStyle = UIModalPresentationFormSheet;

The keyboard refuses to be dismissed. If I comment out this line, the keyboard goes away fine.

...

I've got two textFields, username and password; username has a Next button and password has a Done button. The keyboard won't go away if I present this in a modal navigation controller.

WORKS

broken *b = [[broken alloc] initWithNibName:@"broken" bundle:nil];
[self.view addSubview:b.view];

DOES NOT WORK

broken *b = [[broken alloc] initWithNibName:@"broken" bundle:nil];
UINavigationController *navigationController = 
[[UINavigationController alloc]
 initWithRootViewController:b];
navigationController.modalPresentationStyle = UIModalPresentationFormSheet;
navigationController.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
[self presentModalViewController:navigationController animated:YES];
[navigationController release];
[b release];

If I remove the navigation controller part and present 'b' as a modal view controller by itself, it works. Is the navigation controller the problem?

WORKS

broken *b = [[broken alloc] initWithNibName:@"broken" bundle:nil];
b.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
[self presentModalViewController:b animated:YES];
[b release];

WORKS

broken *b = [[broken alloc] initWithNibName:@"broken" bundle:nil];
UINavigationController *navigationController = 
    [[UINavigationController alloc]
         initWithRootViewController:b];
[self presentModalViewController:navigationController animated:YES];
[navigationController release];
[b release];
+1  A: 

maybe don't return NO, but YES. So it can go away.

And you have a textFieldShouldEndEditing returning YES as well?

And why are you firing [nextResponder becomeFirstResponder]?! sorry i see now

I also have a number of UITextViews which all have their "editable" property set to FALSE.

May we assume none of them, by any chance, has a tag value of secondField.tag+1? If so, you're telling them to become first responder, instead of resigning the first responder. Maybe put some NSLog() in that if structure.

mvds
NO = don't insert newline, from what I can tell. And setting it to YES didn't fix it.
Kalle
A UITextField, being one line by definition, doesn't do much with newlines, I think. So it's more about processing pressing of the Return/Done button, as stated in the docs.
mvds
Are you very sure you hooked everything up the right way? Have you put an `NSLog("tf %x / method ...",textField);` in all delegate functions?
mvds
Well, the delegate functions are called appropriately, and they wouldn't be if the delegate wasn't set up appropriately. And the NSLog gives an EXC_BAD_ACCESS. Also warns me about it being incompatible type in XCode.
Kalle
Sorry should of course be nslog(@"...") ...
mvds
D'oh. Sorry, should've seen that myself. I've updated the answer above with the results of these NSLogs since formatting will gook itself in comm..
Kalle
put some NSLog's within the if as well to see what's going on exactly. see my updated answer btw.
mvds
Done that and updated answer. I can't spot anything odd in this at all...
Kalle
Can't you just zip the entire thing and post it somewhere? I want to believe "all is right but it doesn't work" but I'd like to see it happening with my own eyes...
mvds
Can't, because it's a work project and all that, but what I'll do is (and I should do this, anyway) make a new project and merge this part of it over. Presumably it will WORK, but in the off chance that it doesn't, I can post that project. Give me a day or so to do it though. Will update answer and such when it's done.
Kalle
Huh! While working on getting this into its own project by itself, I realized the following: the keyboard DOES GO AWAY if the view IS NOT A MODAL VIEW. If the view is, the keyboard stays; if the view is not, the keyboard goes away. Still no idea how to solve it but will post the two versions above in my answer in a sec...
Kalle
I've updated the answer above and cleaned it up a bit. In summary, the following line is causing the problem: navigationController.modalPresentationStyle = UIModalPresentationFormSheet; -- if I remove it, the keyboard will dismiss fine. I can only presume this is a bug.
Kalle
Aaand apparently this is a "works as intended" bug.
Kalle
A: 

I'm sure you have looked at this, but you are sure that your controller class is properly hooked up as the UITextField delegate, right?

Neal L
I set it manually myself, and the delegate methods are called, so yeah.
Kalle
+6  A: 

This has been classified as "works as intended" by Apple engineers. I filed a bug for this a while back. Their reasoning is that the user is often going to be entering data in a modal form so they are trying to be "helpful" and keep the keyboard visible where ordinarily various transitions within the modal view can cause the keyboard to show/hide repeatedly.

edit: here is the response of an Apple engineer on the developer forums:

Was your view by any chance presented with the UIModalPresentationFormSheet style? To avoid frequent in-and-out animations, the keyboard will sometimes remain on-screen even when there is no first responder. This is not a bug.

This is giving a lot of people problems (myself included) but at the moment there doesn't seem to be a way to work around it.

Mike Weller
*pause* Wow, okay. Thanks a lot for the heads up. Damn Apple.. :(
Kalle
Did you submit a bug report to Apple? I have done so under ID# 8384423. I have also submitted a sample application to reproduce the behaviour.
Shaggy Frog
Actually, I just got a response from Apple on this issue: "This is a follow up to Bug ID# 8400721. After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 7751141. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#." It IS a bug!
MishieMoo
MishieMoo: nice! Glad Apple are acknowledging that, at least.
Kalle
A: 

i hope that's a bug and not apple "ASSuming" that's we we want. my modal displays a single textfield with several button-popovers so it's not in my or the users best interest to keep the keyboard visible forcing the user to scroll down my modal to get at those other elements.

John

John Bond