I'm currently studying the isHidden method of UIView class.
In the Apple documentation, it mentioned
Hiding the view that is the window’s current first responder causes
the view’s next valid key view to become the new first responder.
I was just wondering, what does the view's next valid key view means?
That documentation is apparently left over from the older NSView documentation and it is incorrect.
NSView is the macOS equivalent of iOS's UIView. NSView has a nextKeyView property which indicates what view should get keyboard focus when the user tabs out of the current view. NSView also has a computed property, nextValidKeyView, which is the next view in the key view loop that accepts first responder and is not hidden.
UIView has no nextKeyView or nextValidKeyView property.
Furthermore, on iOS, hiding the current first responder does not cause “the view’s next valid key view to become the new first responder”, for any reasonable definition of “next valid key view”, because the hidden view remains first responder.
Here's a demo, recorded on a real iPhone 6 (not the simulator) running iOS 10.3.2. The “Button” toggles the isHidden property of the top text field.
After I type “hello” in the top text field, I tap the button to hide that text field. The keyboard is still active but the second text field has no blinking insertion point. I then type “world” and tap the button again. The top text field reappears, and now it says “hello world”. It continued to be first responder while it was hidden. The second text field (which is the only possible candidate for “next valid key view”) did not become first responder.
Causes that the next valid key (the next view of the stack) will be the responder, which if there is nothing "behind" that view that you are hiding will be the super view.
Related
In my app I have lots of UITextFields and UITextViews into which the user enters data. When the user taps on a field it becomes the first responder and the keyboard shows up nicely. When the user then taps on a different field (after having modified the current field) then the keyboard goes away and the current field stops being the first responder. However the field that was tapped does not immediately becoming the new first responder and the keyboard closes.
In my app, after a field is modified, it recalculates all the data and resets the values in all the other fields. I'm thinking that this is what is causing the newly tapped field to loose it's first responder request. There are some fields that are not affected by a recalculation and these behave correctly (that is they immediately get focus and keyboard remains open). So I'm pretty sure that changing the value or some property of the field is resetting the pending first responder request.
How can I detect if the field is pending in the first responder queue (if there is such a thing)?
And how can I make changes without removing it from this queue?
Ok, I found the problem. My code was setting .isEnabled to false and then resetting it back to true. This is what was causing the field to be dropped from the first responder chain. My code shared the same path for viewing and editing and it initially set a field as disabled and if we were in edit mode it then set it to enabled. Fixing this to just setting it to enabled, without the initial blanket disable, fixed the issue.
So the bottom line is that flicking the .isEnabled switch will remove the the field from the responder chain.
I have a UITextField in a complex view hierarchy. The text field is in a UIView with label and textfield, say, labelfield.
I can type text there.
There is info button on top right corner. When tap on Info, a modal view controller is loaded. When coming back from the modal view controller, the UITextField becomes unresponsive. I cannt type anything there. The labelfiedl is drawn and shown in the screen.
Interesting thing is that, if I press the ok button, and alert is shown and then the textfield becomes active. Also, on top of the view, there is some text with user interaction enable, if I tap and try to select the text and after that the textfield becomes active. Seems I have to do some other activity/touch on the super view, then the text field becomes active.
Why not on the first case it receive any touch event? I tried with textField.enabled, becomesFirstResponder, setNeedsDisplay in the viewDidApper method, nothing works.
Try the following...
Make sure that the super view to which the text field is added as subview large enough to contain text field(ie make sure that no part of text field is out side the superview. check this for all views).
Make sure that there is no view above textfield.use bringSubViewToFront: method.
Try to enable use interaction after a delay
Hope any of the above fix will solve your problem
UIKit text input components, such as UITextView and UITextField have a property inputView to add a custom keyboard. There are two questions I have relating to this.
If the keyboard is currently visible and the property is set to a new input view, nothing happens. Resigning and regaining first responder status refreshes the input and displays the new view. Is this the best way to do it? If so it might answer my bigger question:
Is it possible to animate the transition between two input views?
From the UIResponder docs:
Responder objects that require a custom view to gather input from the user should redeclare this property as readwrite and use it to manage their custom input view. When the receiver subsequently becomes the first responder, the responder infrastructure presents the specified input view automatically. Similarly, when the view resigns its first responder status, the responder infrastructure automatically dismisses the specified view.
So unfortunately the answer to 1 is Yes and 2 is No.
Actually there is a method to do it cleanly: UIResponder's reloadInputViews, available from iOS 3.2!
I think you can animated it with some extra work:
Create a clear background window of a higher UIWindowLevel than the keyboard window.
Add your custom keyboard there and animate its frame into place.
Then set it as your text input's inputView and refresh the first responder as you do.
Your custom keyboard will change its parent view from your custom window to the keyboard one, but hopefully the user won't notice ;)
I have a registration form and I want to have the keyboard always on top.
The way I'm doing it now, is that when the user moves between view controllers, in viewDidLoad, the first UITextField becomes the first responder.
The problem is that the keyboard flickers (disappears and then appears again) when the user moves between view controllers.
Also, related to this: I have a form with a few uitextfields. When the user presses next it goes to the next uitextfield using becomefirstresponder. When the user is in the last textfield, the keyboard button becomes "Done". Then, when the user presses it, if there's an error with the last field, it should get the focus (calls becomeFirstResponder) but that doesn't happen (nothing get's the focus and the keyboard goes down). All the other fields get the focus fine, just this last field doesn't. I've tried about everything: switching to other textfields and back. The problem is that done automatically removes the keyboard.
You should have made two separate questions for this.
First, your flickering:
I'm guessing you're using a UINavigationController. You can add an invisible UITextField somewhere in the UINavigationController, which you give focus before you switch to a new ViewController. Then, when the new ViewController has appeared (viewDidAppear), set the focus to the first textField as you want.
However, the entire approach is kind of hackey and I don't recommend you use it. Instead, try using several views in a scrollView, of which you change the offset when you move to the new view. This will also solve the flickering.
Second, losing firstResponder status on Done:
The done button is specifically there to indicate exactly that which it says; Done. Pressing this assumes the user is finished and that no text is left to type, thus dismissing the keyboard.
If you really want to keep the Done button, then try the following;
Allow the user to dismiss the keyboard.
Upon dismissal, check for the error in the last field.
If there is an error, instead of calling [lastField becomeFirstResponder], try [self performSelector:#selector(thisSelectorWillCallFirstResponder) withObject:nil afterDelay:1.0].
In the method thisSelectorWillCallFirstResponder call [lastField becomeFirstResponder].
This will give time for the keyboard to disappear, before making it pop up again, so it doesn't interfere with the becomeFirstResponder call.
Another method would be to not use a Done button, but instead use the return key. You can intercept return anytime with the delegate method textFieldShouldReturn:. There you can handle any error checking, without causing the textField to lose its focus.
This is one of those "it was working a while ago" troubleshooting efforts.
I'm working on the document preview view controller, in which is a scroll view, which itself contains subclasses of UIView that represent each document. I'm modeling this pretty closely to how Keynote handles its document preview, except I build my scroll view horizontally and with paging. But the standard user experience is present: Long press on a document icon causes all document icons to start jiggling, nab bar has + button and Edit button, etc.
The issue at hand is that when you tap on the name of a document, I hide all the others, move the one being edited front and center, build a new text edit field, add it as a subview atop the real name label, and set it as first responder; but the
[editNameTextField setClearButtonMode:UITextFieldViewModeWhileEditing];
while correctly showing in the edit field is not taking any action when the user taps on the clear button.
I can't figure out what I may have done to cause this to not work -- it had been!
My first thought was that somehow my instance of this subclass is no longer the delegate for this text edit field. To try and confirm/deny that, I usurped a tap on the image view of the document preview to compare the delegate property to self, and it passes.
if (editNameTextField) {
NSLog(#"editNameTextField is still active");
if ([editNameTextField.delegate isEqual:self]) {
NSLog(#"we're still the delegate for the editNameTextField");
}
}
Editing the text within the edit field works fine. Pressing the Return/Done key correctly sends the delegate message textFieldShouldReturn:
While investigating this I implemented the delegate method textFieldShouldClear: just to write a log message if the method gets called (and return YES of course). It never gets called.
My next thought was that perhaps a subview had covered up the area where the clear button sits. So I implemented textFieldShouldBeginEditing: and used the opportunity to bring my the text field to the front. That didn't change anything either. I set a debugger breakpoint there to play a sound when it was called, and it got called, so I know my text edit field is frontmost.
I have only one troubleshooting strategy remaining: Go backwards through snap shots until it starts working again. Before doing that I thought I'd see if any of the more experienced folks out here have any suggestions of what to try next.
Where are you adding the textfield? As a subview of the scrollView? If you added the textfield and it is out of bounds of its parent view it won't receive any touches.
You can try and not call becomeFirstResponder and see if clicking it will show keyboard. Another possible error might be that the parent view of the UITextField has userInteractionEnabled = NO.
Without seeing more code I'm afraid I can not offer more solutions.