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.
Related
I am implementing something like Eula in my iPhone app. I need to enable the confirm button only when user reads whole Eula (scrolls along whole long text).
I am using UIAlertView, with long inside text. Thanks to this, the text field inside alert view have a scroll bar on its right side.
I need to access the delegate of this scroll, because I need to enable OK button only if user scrolls down with scrollable text.
If you are planning to release this app on the AppStore, you can't do it using the builtin UIAlertView.
UIAlertView doesn't have any method, and it's delegate protocol doesn't give you this kind of information.
Probably you can achieve this iterating through the subviews of the UIAlertView instance, but doing this will guarantee your app the rejection :-)
the only thing you can do is to create your own "MYAlertView" component
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.
How in the world does one get the iPhone view to zoom in on a focused UITextField? I need to tap on a text field that I want to edit, and my view should zoom in to the tapped text field and pull up the keyboard (which it already does), similar to how many Internet text fields gain focus on the iPhone. Is this some type of overlay?
I've been looking everywhere for this solution but maybe I've just got the wrong terminology. Thank you in advance.
Could be a duplicate of this StackOverflow question.
In essence, there are a number of ways, but you have to program this effect manually. A textfield is already an overlay. You can either move it, or scroll the containing view.
Please follow the following steps.
Implement the delegate method for all textfield.connect the outlet of textfield in interface builder basically it's setting the delegate property.then in delegate property you can defined the method whatever you want to implement or wanted to do functionality.
Thanks
I have a somewhat complex iOS view hierarchy. One piece of text is an editable UITextField. When the user touches it, it becomes first responder, and is editable.
Here's the rub, though: Best practice should be that a touch anywhere outside the edit control causes it to resign first responder and end editing. What's the best way of accomplishing this?
Techniques I've tried:
Use the exclusiveTouch property, which stops the user from interacting with other controls, but doesn't cause editing to end. Also disallows user from interacting with my toolbar "Done" button.
Put a see-through UIView under the text field control and on top of everything else (except the toolbar), and use touches there to end editing. This works, but I end up reparenting the text field onto this other random view which sits above my whole hierarchy, which means I have to take care of the text field's layout in multiple places, since it no longer lives in the place where it lived originally, and I have to delegate all its behavior back and forth from its "shield" view to its native home container, which has all the related logic.
Is there an elegant solution to this problem that I'm missing? I figure it must be a common design issue.
Thanks.
Tile 4 "see-thru" views around the textview to capture/ignore touches. Doesn't require modifying or "lifting" the textview, and can be added to the parent view in a fairly modular way.
You can't mask a region without knowing what that mask will cover and what the mask will not cover. So any solution will require enough reach to gather both of those bounds. Either pass the text rect up, or the view rect/region to be disabled down, or both to something in-between. The controller for the stuff to be covered seems as good a place as any to consolidate both rects or regions, if not the controller for the text view.
The nub of the issue is what constitutes "best practice". The fact that the keyboard remains unless the user dismisses it is deliberate. For example, many apps need the user to be able to tap a button while still working in a text field.
The keyboard has a Return button. "Best practice" is to respond to the user tapping that button by resigning first responder. Otherwise, you should leave the keyboard there, since that's what the user expects.
However, if you insist on doing it your way, there's a simple solution: put a UITapGestureRecognizer on the background view. Its handler will be triggered if the user taps on the background or on any button or similar in the interface. So, presuming you have kept a record of what the first responder is, you can send resignFirstResponder to the first responder in the tap gesture recognizer's handler.
If you change your base view to a UIControl you can add an IBAction to that layer that resigns your text field as first responder.
Also, if you have multiple touch events, make sure they each becomeFirstResponder when touched.
I'd love to have some more details to qualify my explanations xD
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!