The latest version of Apple's UICatalog example application includes zero code in the TextFieldController for handling keyboard show/hide events, and yet the table view still slides up and down beautifully with the keyboard.
Does anyone know what the new trick is? Are there settings in the XIB that allowed them to forgo registering for the notifications or using TextField delegate methods?
The TextViewController still uses keyboard notifications to deal with view sliding, so I'm really confused as to why this isn't included for TextFields anymore.
Thoughts?
You can close the keyboard, if it's open by calling:
[sender resignFirstResponder];
Not sure about opening the keyboard however.
The trick is hidden within calling becomeFirstResponder on a UITextField that is in a scrollable view. Apparently, whenever calling [textField becomeFirstResponder], iOS automatically scrolls the parent view until said textField is visible.
This behavior can actually be undesirable in some cases, as it will not usually scroll to the same location that the UIScrollView method scrollRectToVisible:animated: would if you were to try to do things that way.
Thanks for your thoughts everyone!
Related
I've subclassed a UITextField to display a UIDatePicker instead of a keyboard. Entering dates is something that happens often I our app. The problem occurs when another of our custom classes that accommodates the keyboard needs to know what the first responder.
Is there a way to remain first responder, whilst hiding keyboard?
No, you have to resign as responder (give up focus) to dismiss the keyboard.
Edit: It seems I lied. Try [self.view endEditing:YES];
FYI: It only works on iOS 3.2+
Actually, instead of subclassing, you should just make a custom inputView for your text field which uses a date picker as the custom "keyboard". Then, it will remain the first responder and never even call the system keyboard in the first place.
I have a modal window that's used for searching data from a remote server- it has a UITextField as the titleControl of the navbar for the window, and a tableview filling the window (that displays the results obviously). Now what I want to do is when the user scrolls the tableview, immediately have the textfield lose focus (resign first responder) so that the keyboard dismisses and the user has more room to scroll through the tableview (it stretches down to fill the gap left by the keyboard). Basically the same functionality as when using a UISearchDisplayController (or whatever it's called).
So I have this code for detecting the scroll event of the tableview:
- (void)scrollViewWillBeginDragging:(UIScrollView *)scrollView {
[searchField resignFirstResponder];
}
Which works fine. However, the issue is that once the user scrolls the table and the textfield loses focus, you can't give focus back to it by tapping on it again. So basically once I call that [resignFirstResponser] I can never again bring the keyboard back up and edit the textfield value. Anyone have any idea why? Do I need to explicitly call [becomeFirstResponder] on the field somewhere? Because I thought that was handled automatically when the field is tapped?
Also of note- I am calling [becomeFirstResponder] on the text field right when the modal window is first called up, so the field is pre-focused. Could that have anything to do with it?
I can post more code if anyone would like, but I don't think I'm doing anything out of the ordinary with the textfield.
Thanks for any help!
You are calling the resignFirstResponder from a function which will be called everytime you scroll the UIScrollview. Hence it does not appear. You need to call resign when the uitextview goes out of focus.
You can do the following. Its a hack:
Whenever you focus on the UITextField create a invisible button to overlay your scroll view.
Capture the button press event and resign first responder
Whenever the uitextfield becomes first responder create the button
This way you will remove the bug, viz calling the method in scrollViewWillBeginDragging.
Other option would be to overrite viewDidAppear method for the uiTextField.
Or you could put your textfield into a different container and handle scrollViewWillBeginDragging by checking which scrollview sent the message.
Did u set a delegate for you searchField? I had the same issue. I popup a model view, and set the text field to be the first responder inside viewDidLoad. Everything works well for the first time. But once I dismiss the modal view controller, and reopen it. my text field cannot be focused anymore.
I found it has something to do with methods of UITextFieldDelegate. Once I remove implementation for methods
– textFieldShouldEndEditing:
– textFieldDidEndEditing:
everything works well. but don't know why
Are you doing anything with "textFieldShouldEndEditing", like #fengd?
A problem that I had was that I was viewing a modal view, and my "textFieldShouldEndEditing" routine was incorrectly returning "NO" on a specific text field. When my modal got dismissed, I would be unable to tap on any other text-field, presumably because the old text field was still "first responder". Since it can never end editing, it fouls up all other text fields that come after it.
I realize this is 2 yrs after the fact, but maybe someone else might find this useful.
I have a "new message" view controller in my app (just like the system sms app) where there are two textfields, one for receivers and one for the message content. The problem is when I switch between the two textfields, the keyboard may resize (depending on the input method), and I don't get any keyboard notifications. This is rather embarrassing since the keyboard may cover the textfield, which is not what i want. How can I fix this?
thanks in advance.
You can set your controller as the delegate of your text fields and when textFieldShouldBeginEditing: or textFieldDidBeginEditing: is called, perform any necessary manipulations to your view to make sure the textField is visible.
I coded an UIWebView inside an UIAlertView, and would like the user to type something inside that webView. Unfortunately, my keyboard got covered by the AlertView.
Is there anyway to make the keyboard cover the view, not otherwise?
You can try to add observer for UIKeyboardWillShowNotification notification. And when it is displayed - simply find the keyboard inside the view hierarchy. Look here for an example. When you find it - bring it to front (maybe, do the same for keyboard parent view/views).
As far as I remember, this works only with iOS 4.0+.
And once again - listen to Jonathan Grynspan & Legolas - better think about another way of accomplishing your task.
I am continuously appending text to the content of my UITextView and would like to auto-scroll to the latest update, only if if the UITextView has already been scrolled to the bottom. Any ideas on how this could be implemented?
UITextView inherits from UIScrollView, so you can therefore access all of the same properties as with a UIScrollView. Personally, I would use a combination of
myScrollView.contentOffset.y
to detect whether or not the text is scrolled all the way down, and
[myScrollView zoomToRect:CGRectMake(x,y,height,width) animated:YES]
to shift the current view to the newly added text.
See the docs for UITextView and UIScrollView. If you didn't know already, those can be accessed from XCode by clicking Help>>Developer Documentation
Good Luck!
James
To all those who want to automatically scroll a uitextview when a keyboard appears/disappears, search and download keyboardaccessory.xcodeproj by apple.
Although the program tests in an ipad simulator, you can copy the parts of the code and paste them in yours.
Specifically:
Copy the code on listening for the 2 notifications for keyboardWillShow and keyboardWillHide in the viewDidLoad.
Copy the code releasing the notification in dealloc.
Remove notification listening status in viewDidDisappear.
Copy the codes in keyboardWillShow, keyboardWillHide to programmatically compute for the height of the keyboard and scroll the text automatically.
Remove the keyboard in textViewShouldEndEditing by calling [textView resignFirstResponder];
If you want this implemented in both portrait and landscape, the code above will already do the necessary computations. all you have to do is allow rotation in shouldRotateToInterfaceOrientation