I have a ViewController with a TextField for user input and a Quit button in a NavigationBar.
Normally, the user inputs text into the textField and the input is processed in textFieldDidEndEditing. If the Quit button is tapped before editing starts, then it segues correctly to the parent ViewController.
However, if editing has started on the textField and then the Quit button is tapped, textFieldDidEndEditing is still called, which I don't want to happen.
I have tried using textFieldDidEndEditing:reason: but the returned reason in both cases is UITextFieldDidEndEditingReasonCommitted. It seems that UITextFieldDidEndEditingReasonCancelled is only valid in tvOS not iOS.
How else can I detect that the user has Quit and prevent textFieldDidEndEditing from running to completion?
You can't prevent textFieldDidEndEditing from being called. Dismissing the view controller dismisses the text field. Since the text field is no longer being edited, the delegate method will be called.
One option you have is to set a flag when the user taps the Quit button. Then in your implementation of textFieldDidEndEditing you can check if that flag it set or not and act accordingly.
Related
In my iOS project, I have a form which contains various text fields. Some text fields are edited by keyboard and some by picker view which is placed on the popover.
When I go on filling text fields, without dismissing it and then if I click on popover text field keyboard remains open.
It appears as both keyboard and popover present on screen at the same time, which I don't want.
I am able to get whether the keyboard is opened or not by setting a flag in keyboard notification methods and also the last text field that was edited through text filed delegates. And have tried
[self endEditing: YES]; (as it is in a table cell)
[lastEditedTextField resignFirstResponder];
Even try to pass keyboard dismiss the notification by my self (without knowing whether it is possible or not)
[[NSNotificationCenter defaultCenter] postNotificationName:UIKeyboardWillHideNotification object:nil];
but nothing is working.
How can I dismiss keyboard (if already open) whenever popover appears?
You can call:
[self.view endEditing:YES];
But, a better solution is likely to present the picker using the UIResponder
inputView so it automatically replaces the keyboard and you don't need to mediate between 2 different things (and the user doesn't switch between different parts of the screen potentially).
Try to implement textFieldShouldBeginEditing: and inside it check which text field is this. If it is one of the fields that should display a popover, first call [self.view endEditing:YES] to hide the keyboard, then present the popover and return NO. This way the text field won't take first responder status and the keyboard will not appear again. And if it is one of the "normal" text fields, just return YES.
I am troubleshooting a strange behaviour of a UITextField in my app.
During editing the above textField, if the app goes to the background and comes back to the foreground, the keyboard disappears. I have kept breakpoints at all places where the resignFirstResponder is getting called. But, I am unable to find the cause of the disappearing keyboard.
Is there any instance when the keyboard will be dismissed without specifying resignFirstResponder explicitly in code?
What is the expected standard behaviour in the above case?
I'm new to iOS development and have recently learned that to make the on screen keyboard disappear we must always call resignFirstResponder on the text view. This causes the text view to relinquish it's first responder status, and hence the keyboard disappears, since there is no need for the text view to respond.
However I also noticed that there's the becomeFirstResponder method to make a view a first responder. However, this method is never called on the text view. So when/how does a textview become first responder when that method is never called?(at least, by me. I'm unsure if it is called elsewhere in the system)
My theory is that is has to already be a first responder before it can resign the first responder status.
firstResponder status is automatically handled for you when a user taps on the text field. So long as user interaction is enabled for the UITextField/UITextView, the keyboard should appear when tapped.
You can monitor for it using the delegate method textViewDidBeginEditiing or, more broadly, by listening for keyboard appearance notifications (UIKeyboardWillShowNotification and UIKeyboardDidShowNotification).
Further, there are ways to dismiss the keyboard without the need of calling the corresponding method resignFirstResponder (such as calling endEditing: on a container view, or setting a scroll view's UIScrollViewKeyboardDismissMode).
Note: In the simulator, it is possible that the keyboard still doesn't appear even if all is correctly working. In that case you just want to make sure keyboard hardware is toggled (CMD+K) for the simulator.
You call becomeFirstResponder yourself if you want to give a UITextField focus and show the keyboard.
This is useful for view controllers that are basically forms. For example, if a user presses a "Sign Up" button, you might push a view controller with a couple of text fields and call becomeFirstResponder on the first one to automatically give it focus and open the keyboard.
I have implemented a scrolling feature, where the textfield is not hidden from the keyboard. Therefore I'm working with UIKeyboardDidShowNotification and UIKeyboardWillHideNotification, where the scrolling takes place. For the scrolling I need to know the current active textfield. This is done with EditingDidBegin and EditingDidEnd.
The code is in C# but there is no much difference:
usernameText.EditingDidBegin += delegate {
activeTextField = usernameText;
};
usernameText.EditingDidEnd += delegate {
activeTextField = null;
};
The flow of my application looks like the following:
User starts application and one textfield is becoming the first responder. The keyboard pops up and UIKeyboardDidShowNotification is correctly called.
User presses another button and another view is presented modally.
UIKeyboardWillHideNotification is called correctly as well as my active textfield is cleared out in EditingDidEnd.
When coming back from my modal view UIKeyboardDidShowNotification and UIKeyboardWillHideNotification are called again despite there is no keyboard active.
In UIKeyboardDidShowNotification I need the active text field which is null at that time and my app crashes. Now I used a null check for that so that the app doesn't crash.
But why are the two notifications are sent again when there is no need to?
in step 2: "User presses another button and another view is presented modally." before presenting a viewController hide Your keyboard
Hi I have a textfield to which I have assigned a UIPickerView as inputView. The UIPickerView has a method called using addTarget:action:forControlEvent: which I want to bring up an alertView to ask the user if this change is what they want.
Currently, I have the main view of the view controller as a UIControl, so when the background is tapped during editing I call [self.view endEditing:YES];
I want to bring up a UIAlertView when I end editing my textfield, I am playing with the control event. UIControlEventValueChanged doesn't work well because it brings up an alert view every time the wheel is spun and released, not only on exit. The other control events like UIControlEventDidEndEditing/OnExit don't do anything. What am I doing wrong?
I figured it out.
Even though the UIControlEventValueChanged worked on its own, I needed to hook up my textfield to my action method through interface builder. For some reason it did not work through code with the UIPickerView.