When using an external keyboard, my UITextView fires a shouldChangeTextInRange message just fine when I press the Backspace key ("backward delete"), but if I press Delete ("forward delete") then the method is never called at all, despite the view's text changing as expected. In case it matters, I'm using Swift and the latest iOS simulator.
If this is expected behavior, can someone point me to the documentation that explains it?
More importantly, is there a workaround?
Edit: submitted rdar://18909378. I've also discovered the same behavior when using cmd+backspace and opt+backspace. Very annoying!
I'm still seeing this issue on iOS 10. The best workaround I've come up with is to listen to the field's UIControlEventEditingChanged event and grab textField.text from there. This gives you the updated contents, but doesn't allow you to prevent the delete action like shouldChangeCharactersInRange does.
Related
I've taken over the work on an iOS app, I've managed to work quite well with it thus far adding new functionality despite not being a trained iOS developer. However I've hit a patch where I simply cannot get the keyboard to show on screen when I tap on a UITextfield, there are areas of the app where it works but any new areas I add this simply will not work. Is there a standard bit of code that controls showing the keyboard when you tap a text field?
Need help
Keyboard opens up automatically unless you forced to not open.
You can check following, See screenshots.
Enable is checked
User Interaction Enable is checked
If you are checking on simulator try “command + k” from keypad
textFieldShouldBeginEditing delegate returns TRUE
-(BOOL)textFieldShouldBeginEditing:(UITextField *)textField{
return TRUE;
}
Are you running on a simulator or a real device?
So, Apple has a bug right now where if you type an Emoji into a UITextField, it will shift the text down. In fact, if you type enough emojis and then backspace, it'll shift the text even further down from where it was supposed to be. I confirmed this by trying UITextFields in Twitter, Snapchat and other apps.
Here is a video of my app displaying the bug.
Use this: textField.clipsToBounds = false
It prevents the textField to move when editing. Even when you try to edit it again.
(Tested on iPhone 6, iOS 10.0)
I don't think their would be a way around this, as it just seems that the emoji is changing the margin of the text inside of the UITextField.
In iOS, I have a UITextField in a UITableViewController scene that is governed by a Navigation Controller. All static cells. The text field has the "Clear on editing" flag switched on. I want to get and save the value entered in the field, so I have the -editingDidEnd: action call my saveData: method in the custom UITableViewController subclass. If I click out of the text field, all is well. However, if I back out of the scene using the Back navigation button, then saveData: gets called twice. Once with the entered value, and a second time with an empty value. This appears to be incorrect behavior.
I've made a demo project and posted it to GitHub here: https://github.com/davehirsch/BugDemo
Am I doing something wrong? Is this an iOS bug? It seems unlikely that it's a bug nobody else has found (and I've looked around for others reporting similar things). I'm running the latest non-beta versions of Xcode and OS X, and the bug is happening in the iOS Simulator (but I'm not sure if it would happen on a real device, I guess).
Yes you are right. It looks like a bug in UINavigationController.
Before and after animation the method [UITextField resignFirstResponder] is called before and after animation. The first call is done by [UINavigationController popViewControllerAnimated:], and the second one in [UINavigationConteoller navigationTransitionView:didEndTransition:fromView:toView:] that call [UIView(Hierarchy) _removeFirstResponderFromSubtree].
Looks like your text field hasn't resigned yet as a first responder before animation ends.
[EDIT]
I recommend to look at rdelmar comment.
I'm porting a Mac app to the iPhone and I've run into an unexpected problem.
On the Mac there's a text field that is automatically pre-selected (= first responder) when a dialog shows up. The text field shows the text you entered in the field the last time and the text is pre-selected so that if you just start typing it gets cleared away. If you want to edit the existing text instead you just hit the forwards or backwards arrow.
On the iPhone this behavior seems very hard to implement. The text view shows up with the old text and I can even get it to pre-select but whatever I do the result is not quite right.
When I use
[aTextView setMarkedText: myText
selectedRange: newRange];
the text does show up as marked and if I just start typing the old text goes away. However there's no equivalent to the cursor keys on iOS, so I cannot NOT erase the text.. which is hardly the point.
What kind of iOS idiom would be appropriate for giving the option to either edit or overwrite existing text?
Best regards,
Frank
Try this code in your UITextViewDelegate
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
dispatch_async(dispatch_get_main_queue(), ^{
[textView selectAll:self];
});
return YES;
}
Playing around with my web application in the iOS 5 simulator, I noticed that iOS 5 doesn't clear placeholders immediately, only after the first input. On all other version of iOS as well as on all desktop browsers, the placeholder is immediately cleared when the user focuses on the input. I don't have access to an iOS 5 device right now but I highly doubt this is a simulator error.
Is this a bug or intended? Oddly I only found one reference to this behavior on the net, right here on SO: clearing input placeholder in iOS5
Is there a workaround for this problem? It's quite frustrating for the user when the placeholder doesn't clear immediately.
I think you are mistaken - iOS text fields always behave this way.
I don't see why this would be frustrating for the user. If anything it is helpful that the helper text stays visible until they begin typing, in case they missed it before selecting the field.
What may be confusing you is that iOS fields have a separate optional behaviour where the text is cleared when the field is selected, but note that this is the actual text that clears, not the placeholder text.
Placeholder text is the light grey text, and this always appears until the user types something.
Content text (usually black) sometimes clears when the field is focussed and sometimes doesn't, depending on how the UITextField was configured.
The jQuery solution in the SO question you linked to should let you replicate any variant of this functionality that you desire, but personally I'd advise sticking with the iOS convention of not clearing helper text until the user types something.
It is not a bug, it is a feature. You can use delegate methods to clear placeholder. (UITextFieldDelegate http://developer.apple.com/library/ios/#documentation/uikit/reference/UITextFieldDelegate_Protocol/UITextFieldDelegate/UITextFieldDelegate.html)
- (void)textFieldDidBeginEditing:(UITextField *)textField
{
[textField setPlaceholder:#""];
}
adn you should control its emptiness after finish editing.
- (void)textFieldDidEndEditing:(UITextField *)textField
{
if ([textField.text isEqualToString:#""])
[textField setPlaceholder:#"Placeholder Text"];
}