I've layed out a view with some labels, a button and especially a text field in the bottom of this view. The issue is when the text field gets the focus, the iphone virtual keyboard hides the text field, so we can't see what we're typing (and I can't move the text field to another part without breaking this layout)...Any idea on how to fix this issue ?
Thx for helping,
Stephane
There is a method of textFieldDelegate calld
- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField
When this method gets called you can change frame property of you UIView and shift it upward.
Same way when textFieldShouldEndEditing gets called you can shift view down again.
Moreover, listing to notification UIKeyboardWillShowNotification and UIKeyboardWillHideNotification can also be useful to trigger view shifing.
If you do not know how to slide view see this.
http://iosdevelopertips.com/user-interface/sliding-views-on-and-off-screen-reader-contributions.html
Related
I have a problem, I have a view with 3 text fields, 2 of them are covered by the keyboard when I want to write something.
I found a code that moves the entire view up when the keyboard is shown but I only want to move the two text fields when they are pressed, while the rest of the view stays in place, is it possible?
The code I used - http://www.ioscreator.com/tutorials/move-view-behind-keyboard-ios8-swift
make use of the notification event, then you can make adjustments to your view. The Notification also includes information about the size of the keyboard.
UIKeyboardDidShowNotification
I have a UIScrollView with 2 views, side by side, each of which covers the entire screen.
They are moved to visible bounds on user's action, only one covering the screen at a time. Both of these views have multiple UITextFields. Working with the simulator, I fill in a textField in the first view and when I press the Tab key, the firstResponder is assigned to a textField in the other view. I understand that on using the device, the user will not be able to do that. But what if the user uses a bluetooth keyboard, or similar accessory? I do not want a textField, that is currently not visible to become firstResponder. Can this be done?
EDIT: I just remembered the canBecomeFirstResponder method. But how do I determine which textField is about to becomeFirstResponder?
It sounds like the problem isn't that they shouldn't be able to tab between the two text fields, but instead that they shouldn't be able to edit a text field that isn't visible, and they should be able to tab between them if they are both visible at the same time.
Instead of restricting tab, I would implement the UITextField delegate method -textFieldShouldBeginEditing:, which allows you to return a boolean whether or not that text field should become the first responder.
Something such as:
- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField
{
// Only edit if the text field is visible
return !textField.isHidden;
}
You may need to adjust this code to fit your 'is visible' status of the text field.
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.
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!