I want to have to focus of my textfield always at the beginning of the textfield even if the user is writing, I want that the user always see the first word he typed.
Is it possible?
For this kind of thing I usually use two textfields, the "real one" which is behind the one the user sees and the one the user sees which is in front, has user interaction turned off, and is covered by another view with a tap gesture recognizer (or just a clear button).
When the user taps on the empty view or button, you tell the real textfield to become first responder. As the user types in the textfield you implement the delegate methods and forward whatever filtered or formatted input you want to the visible textfield in front.
Related
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.
In my iPhone APP I have a view with a textfield and a button (to remove the view).
My main goal is to have the keyboard always visible.
I made a "Send" button visible on the keyboard and am able to capture when the send button is pressed.
Hoever, when you press the send button the keyboard is removed. What I would like is for the keyboard to remain visible and the text from the textfield to be cleared and be textfield to have focus ready for some more typing.
Adding:
[textChat becomeFirstResponder];
in the Did End On Exit event does not work. I am not sure if I should be using one of the other events.
There are a ton of samples and tutorials on how to remove the keyboard, not one on how to keep it.
The keyboard is removed when it stops being the first responder. There is a delegate method you can implement, textFieldShouldEndEditing:, which is called when the text field is asked to resign from being first responder. You could implement this and have it return NO after you do whatever you want to do with the data in the text field (send it somewhere), clear the field, etc.
In my UITableView, each row has a text field or switch as its accessory view (a bit like the Settings app). The textFields are set with Auto-capitalisation ON. But the auto-correct prompt (the one you tap to dismiss the suggestion) seems to react to finger presses up to 65 px below the actual textField!
This means, for example, if a user types something in a textField, and then tries to press a UISwitch in the row below (without pressing return), instead of pressing the switch, their first press dismisses the autocorrect. For the user this is both confusing (they have to tap the switch twice) and annoying (they dismiss the text field's correction without meaning to).
Is there any way around this without having gigantic table rows or disabling autocomplete?
Maybe you could have a timer of 1 or 2 seconds that check and resign the textfield automatically.
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
I am currently using a UIPIckerView in my app to allow a user to select from a list of options. The problem is that there isn't enough of a delay when the user stops spinning the wheel and it is selecting a value before the user has a chance to scroll further down the list.
Is there a way to override the default behavior that selects the row as soon as the wheel stops spinning and the user removes their finger? I see Mobile Safari includes a "Done" button which would be great.
I can provide code if necessary (not sure how it would help).
Thanks!
You can add this manually; just add a done button to the view that holds the UIPicker, and have IT do whatever action you're currently performing in – pickerView:didSelectRow:inComponent:.
The UIPickerView automatically selects which ever row stops in the center. It does not work like a table but more like a popup menu. As such, you can't use a picker view like a button to call an action because it will trigger the moment the user stops moving it whether that represents their final choice or not.
Instead, as noted previously, you need a second control element (usually a button) to call the action that makes use of the pickerview's selection.