I have a UISearchBar and on the delegate method I hide the keyboard when the text field is cleared:
- (void)searchBar:(UISearchBar *)filterBar textDidChange:(NSString *)filterText {
NSLog(#"filter: %#", filterText);
if ([filterText length] == 0) {
NSLog(#"hiding keyboard");
[filterBar resignFirstResponder ];
Now when I use the backspace button to clear out the search term all is good. The keyboard hides when the search turns to empty. Not so when I am pressing the "cross" button to clear out the search field altogether.
Well, not entirely true. I does call resignFirstResponder and hides the keyboard - you just can't see it because it comes right back up. I found this out by observing the keyboard show/hide events.
So how come the keyboard is shown again? How can I prevent this?
I've already tried to walk all subviews of the UISearchBar and also call resignFirstResponder on those ...but unless I did something wrong - that doesn't solve this either.
Update:
In fact I just got the keyboard to not disable the "Done" button :-D ...so I will "stop" going down that road as Kevin suggested. Still I would like to know why the keyboard came back up like this.
I would suggest you stop trying to do this. Hiding the keyboard when the field empties out is completely non-standard behavior and the user won't expect it. In situations like this it's far better to keep your behavior consistent with all the rest of the apps across the system.
I see you've accepted an answer and don't plan to continue in this vein, but I am curious whether you could achieve something like you wanted by implementing this:
- (BOOL)canBecomeFirstResponder
{
return !preventingKeyboardAppearance; // so to speak
}
- (void)searchBar:(UISearchBar *)filterBar textDidChange:(NSString *)filterText
{
// handle text
preventingKeyboardAppearance = YES;
[filterBar resignFirstResponder];
}
I'm not clear under what circumstances you would set preventingKeyboardAppearance back to NO, but I do wonder if this would work.
I basically agree with Kevin, but that doesn't help you so here goes:
Try looping through the subviews of the searchbar and find the sibling which is of the class UITextField. Then either set the delegate property of this text field to your ViewController's class and handle the callback there (e.g. textViewShouldReturn), or simply call resignFirstResponder directly on the text field. The former obviously needs to be done at init/load time while the latter can be done in your existing textDidChange callback.
Here are some more pointers:
http://discussions.apple.com/thread.jspa?threadID=1479468&tstart=0
http://discussions.apple.com/thread.jspa?messageID=8176608
-(BOOL)textFieldShouldReturn:(UITextField *)textField {
[textField resignFirstResponder];
return YES;
}
[textField resignFirstResponder] is not working some time so use this
[YorTextFieldName resignFirstResponder] it's working correctly not any other
function for hiding key bord
Related
For some reason, resignFirstResponder is not working. I am not sure why? I have tried to call it from textFieldDidEndEditing and nothing happens. A NIB is being used and each's delegate is pointing to files owner.
What needs to be done to get the keyboard to dismiss?
Thanks.
Don't use -textFieldDidEndEditing. That's called after the text field resigns firstResponder status, which is what you're trying to use it as a hook to make happen. Cart before horse, chicken-and-egg kind of problem.
Instead use -textFieldShouldReturn to get triggered when the return key is pressed (and remember to return YES; from that.) Also float a clear custom button behind the elements of the view and handle a "background tap" that goes through all the text fields on your view and resigns first responder on the lot of them.
actually you should return NO so that the text field does not begin editing at all. If it does, the firstresponder gets set and the keyboard pops up again.
Make sure your setting your delegates for the textfield.
myTextField.delegTe = self;
And you are using in your header:
<UITextFieldDelegate>
EDIT:
Try:
if(textField == myTextField){
[textField resignFirstResponder];
}
Is there any way to hide the keyboard when a clear button of UITextField is pressed?
Yes, there is, although I suspect that doing so would violate the Apple Human Interface Guidelines.
To do so, add the following method to your view controller's implementation file. Then make the view controller into your textfield's delegate.
- (BOOL) textFieldShouldClear:(UITextField *)textField{
[textField resignFirstResponder];
return YES;
}
The downside to this approach is if you ever want to prevent the textfield from clearing, your code becomes messy. Instead you might try to define a custom method and then connect it to the valueDidChange method and check for an empty value.
-(IBAction)hideKeyboardFromTextField:(id)sender{
//TODO: Check if the previous value was longer than one character to differentiate
//between backspace and clear.
//check if the editing caused the box to be empty
if([[sender value] isEqualToString:#""] || [sender value] == nil)
[sender resignFirstResponder];
}
}
The problem here is that you can't easily differentiate between a tap on the clear button and a tap on the delete button when there is one character in the UITextField.
As I said in the beginning of my answer, this is not advisable in the first place and as the answers here have shown, it is not so easy to implement. I don't think it's worth the hassle, considering the difficulty involved and the fact that it doesn't result in optimal user experience.
This code is definitely working for me to hide the key board while clearing out the content of the textfield
- (BOOL)textFieldShouldClear:(UITextField *)textField
{
textField.text = #"";
return NO;
}
Yep. Call resignFirstResponder on the text field in the delegate's textFieldShouldClear: method.
In UITextFieldDelegate
- (BOOL)textFieldShouldClear:(UITextField *)textField {
[textField resignFirstResponder];
return YES;
}
But there is a problem with this. From the manual, "The text field calls this method in response to the user pressing the built-in clear button. (This button is not shown by default but can be enabled by changing the value in the clearButtonMode property of the text field.) This method is also called when editing begins and the clearsOnBeginEditing property of the text field is set to YES."
Note that, this method is called when editing begins if clearsOnBeginEditing is set to YES. So if you call resignFirstResponder in this method then editing will not begin actually. So you need to set clearsOnBeginEditing to NO. Obviously then the text field won't be cleared when editing begins.
Another IMPORTANT matter not directly related to the question. Hiding the keypad after tapping clear button is not a familiar behavior and Apple does NOT like changing the behavior of standard items. You may get a rejection for this.
Try this code:
[TextField performSelector:#selector(resignFirstResponder) withObject:nil afterDelay:0.1];
For Swift
In your UITextFieldDelegate
func textFieldShouldClear(_ textField: UITextField) -> Bool {
textField.resignFirstResponse()
return true
}
Is there an iPhone equivalent for the NSResponder methods -selectNextKeyView or -nextValidKeyView from Mac OS X? I know about the -becomeFirstResponder method, but finding out which view to call that on is not very pretty when view hierarchies get more complicated.
There must be some kind of way to find this out as when I press tab when in the iPhone Simulator, focus does properly go to the next UITextField. This made me wonder what exactly happens when I press tab. Any ideas?
Update: This does exactly what I want, but _nextKeyResponder is private API, so a no-no. Is there any way to do a 'fake' tab key press without using private API?
- (BOOL)textFieldShouldReturn:(UITextField *)textField {
// Try to find next responder
UIView *nextResponder = (UIView *)[self.view _nextKeyResponder];
if (nextResponder) {
// Found next responder, so set it.
[nextResponder becomeFirstResponder];
[self.tableView scrollRectToVisible:[self.tableView convertRect:[nextResponder frame] fromView:nextResponder] animated:YES];
} else {
// Not found, so remove keyboard.
[textField resignFirstResponder];
}
return NO; // We do not want UITextField to insert line-breaks.
}
There is not a public iOS equivalent for NSResponder's -selectKeyView or -nextValidKeyView.
When the first responder is an instance of UITextField, pressing tab instantiates a private subclass of UIEvent which is passed to -[UIApplication sendEvent:], which in turn calls -[UIView _nextKeyResponder].
-[UIView _nextKeyResponder] doesn't work quite the way you think it does. It treats the key view chain as a loop, so your else block will never be reached. For the same reason, even if there was a public API for synthesizing keyboard events, you probably wouldn't want to use it.
Instead, you probably want something more like UIWebView's UIToolbar-based form input accessory. Its buttons can be enabled and disabled when appropriate, and its delegate handles the actual button press actions.
To implement such a delegate in a general way, however, it might be helpful to look at how -[UIView _nextKeyResponder] is implemented.
In the UITextField delegate -textFieldDidEndEditing:, switch between the various text fields (for example, by testing the text field's tag property).
When you match one text field, set another text field or other control to become the next responder.
I'm surprised nobody else appears to have solved this on iOS.
I devised a solution that handles both Tab and Shift+Tab to go forward and backward to any field you want on iOS, and doesn't use any private APIs.
Here is the write-up: http://weaklyreferenced.wordpress.com/2012/11/13/responding-to-the-tab-and-shift-tab-keys-on-ios-5-ios-6-with-an-external-keyboard/
I have two text fields email and password. The following code works fine when the fields are presented on a regular view but when they are on a popover, the resignFirstResponder does not work (becomeFirstResponder works). textFieldsShouldReturn was called for both fields.
Any idea if I am missing something?
Thanks!
- (BOOL)textFieldShouldReturn:(UITextField *)theTextField {
if (theTextField == email) {
[password becomeFirstResponder];
return NO;
}
[theTextField resignFirstResponder];
return NO;
}
Check this question:
Overriding disablesAutomaticKeyboardDismissal to return NO as below fixed the same problem of mine. You should put this code to your view controller, from which you initiate the keyboard:
- (BOOL)disablesAutomaticKeyboardDismissal {
return NO;
}
As described in this answer, the keyboard will sometimes remain on-screen when the view is presented with the UIModalPresentationFormSheet style.
I'm not too sure about this, but, as I understand the responder hierarchy, resign would work only if you have some other responder to answer.
In a regular view, the view itself is willing. In a popup, maybe you need to do something to your popup class (like reimplement some Responder methods) in order for this to work.
I was also having this problem. But I solved this by making a another control, which is not in the popover as firstResponder and later a resigned it from there. But I don't what is the problem with popover.
The answer is provided as a possible solution to others with a similar problem, but where the conventional remedies don't work.
In summary -
I had a similar problem (under a certain condition) and tried everything - to no avail - Included in my list of possible solutions was [obj's resignFirstResponder], the overriding of 'disablesAutomaticKeyboardDismissal' for my view controller, [self.view endEditing:YES]; and a bunch of other things.
Went about determining the [id] of the current first responder, only to discover it was nil. Tapping 'Done' on the keyboard or using any of the methods above did nothing - the keyboard remained - even after tapping on another input field.
The screen was essentially a ViewController with a UITableView with a text input field in each cell - 7 or 8 in total. Tapping on any cell would bring up keyboard as expected and tapping a separate 'Next' button (to hide the keyboard plus other processing) worked as expected.
However, in landscape mode, the last field was covered by the keyboard requiring the table to be scrolled to reveal such.
After scrolling and tapping that last input field, the keyboard could not be dismissed - no matter what. The only work around was to scroll the table back under the keyboard, then tap the 'next' button. It doesn't make sense.
Almost at the point of giving up (and implementing a workaround), the solution that worked was to make that last input field the firstResponder (even though it already had a blinking cursor) and then to resignFirstResponder after that.
So;
`-(void) actionNext {
[[m_arrInputFields objectAtIndex:7] becomeFirstResponder];
[[m_arrInputFields objectAtIndex:7] resignFirstResponder];
}`
fixed the problem - whereas [m_arrInputFields objectAtIndex:#any other index#] did not!
Would be great if anyone can provide clarity or an explanation for this - else - I hope it saves someone else a few hours of work!
I have a table and in one of the cells I keep a UITextView. When the user taps it the keyboard appears. I was trying various ways to get rid of it. My first approach was to detect a tap on the table cell of the UITextView, but since the text view takes most of it, it's not suitable. Then I tried to add a button to the toolbar and whenever the user presses it, the keybord disappears with resignFirstResponder, but it won't work. It seems that only when I'm in the same view as the UITextView resignFirstResponder works. So how can I get rid of the keyboard from a different view?
Thanks.
The method below uses the Return Key to dismiss the UITextView Keyboard.
In your Controller, set the UITextView's Delegate to self
like this:
myTextView.delegate=self;
Then add this method:
- (BOOL)textView:(UITextView *)textView shouldChangeTextInRange:(NSRange)range
replacementText:(NSString *)text
{
// Any new character added is passed in as the "text" parameter
if ([text isEqualToString:#"\n"]) {
// Be sure to test for equality using the "isEqualToString" message
[textView resignFirstResponder];
// Return FALSE so that the final '\n' character doesn't get added
return FALSE;
}
// For any other character return TRUE so that the text gets added to the view
return TRUE;
}
This should work if you're not using the Return key as a true Return key (e.g. adding new line).
What do you mean "it won't work". If txtView is your UITe4xtView, do you mean that associating the button with an action that has [txtView resignFirstResponder] wont work? I've used this code before and it works for me
Without knowing the size of the controls, nor the intent, it's a bit hard to make a solid recommendation. However, if you're looking for a read-only text view, why not consider a UILabel? If it's going to contain a great deal of read-only text and you need rich formatting, consider a UIWebView with your formatting.
Of course, this answer could be completely inappropriate. Can you clarify your intentions, maybe show a screen shot of the app-in-progress (untapped, of course)?
try unchecking the 'Editable' option in the Text View Attributes window in Interface Builder.
this stops the keyboard from showing up if the user clicks on your TextView
i've use for that kind of problem, the folowing method
- (BOOL)textFieldShouldReturn: tf_some_text_field {
[tf_some_text_field resignFirstResponder];
[tf_another_text_field_in_the_same_view resignFirstResponder];
return YES;
}
hope it helps...