This has to be some kind of newbie blunder that I just can’t see, and I’d be grateful for hints as to what to check or where to look.
I've followed an iPhone tutorial that has a UITextField, making sure I connected the IBOutlet for the text field, and it seems to compile properly (no errors or warnings). But when I run it under the simulator, and click in the field, I don’t get the keyboard, so I can’t enter anything into the field.
I’ve tried searching the site for similar questions, and all I’ve found is a few questions where the developer is trying to set up some complex UI with multiple controllers, and one that seemed to be the same issue, but the original poster simply said that he solved it by starting a new project and porting the code over. I’d like to find an actual solution, so I don’t have to try randomly rebuilding projects when this issue comes up again.
Thanks!
Just to cover all your bases when troubleshooting this, make sure it's not the iOS Simulator that's causing this. I wasn't seeing the keyboard appear when entering a UITextView as well and it turns out the simulator allows you to toggle between displaying the virtual keyboard and just having you use your laptop's keyboard.
You toggle between the two via:
Hardware > Keyboard > Toggle Software Keyboard
or press Cmd + K.
(my source: https://stackoverflow.com/a/24401535/1700540)
So make sure you didn't mistakenly toggle the simulator to only use your physical keyboard! ... like I had
Make sure parent containers have User Interaction Enabled checked. It is not sufficient for the individual controls to have this checked. The UIView can inadvertently get this deselected.
One thing you should check is to make sure the containing view (the UIView that contains all the controls), which is the View icon in Interface Builder nib viewer, has User Interaction Enabled checked. If the parent container doesn't have this checked, even if the individual controls do, you will see this behavior.
What is the delegate for the UITextField connected to? Have you made sure that the delegate functions, particularly - (BOOL)textFieldShouldBeginEditing:(UITextField *)textField
is returning the right thing (in this case YES)?
Not sure if this is anyone else's problem but I was using a TextField in a TabBar controller displayed modally and I added the shake gesture in my main view controller. This unfortunately meant I was setting [self becomeFirstResponder] in the viewDidLoad. In that case when my modal view displayed it was not becoming the first responder and hence the keyboard did not display.
To fix it I added [self resignFirstResponder] just prior to calling the modal display and all is well once more! Yay (only took five days to figure that out).
Basicly the only thing you need to do is declare the text field in the .h
IBOutlet UITextField *textField
then declare with same name in the property
#property (nonatomic, retain) UITextField *textField;
then make sure you synthesize in the .m
#synthesize textField;
then you have to link the field in the interface builder
Related
So currntly I have multiple UITextFields whose data is automatically inputted for the user when the app launches, mainly gets the location of the user and inputs them into the textfields.
Now, the issue is, when the textfields are filled, the textfields expand in width with respect to how much text is in the body of the UITextFields.
Heres a few pics of what really is going on, I'm also using nib files to create the layout, the left pic is of the application not getting an address inputted into the UITextfield from CLGeocoder coordinates, whereas the right view shows the UITextfield getting address string from the CLGeocoder.
I also notice that when I finish typing in a field, the fields EXPAND after I press return and the keyboard is dismissed.
I'm sure there is probably a setting in the nib file I uncheck or maybe I have to do this programatically? By instantiating the UITextfields programatically i mean.
As Rocky has already said, the problem is with auto-layout option of iOS 6.0. I also ran into this painful thing a while back. Turn off Auto-layout but now you will have to maintain two storyboards, one for iPhone 5 and there other for iPhone 4 and lower. Fun isn't it?
If you still decide to use auto-layout, make sure there are no User Constraints on the UITextFields where the Width is set to "Greater Than or Equal". This will allow the control to expand based on the content. If there are, just delete them.
Recently I've submitted an application to Apple and they told me that to show a UIPickerView in iPad I have to embed it into a Popover, so the discarding is as easy as touching outside of the Popover...
How I'm supposed to discard a UIPickerView with iPhone?
I don't want to push another view and then return to the initial view to make the selection because it would interrupt usability flow.
On my current implementation I'm showing the UIPickerView below the selection UITextField and discarding it with a UIButton... is this method correct?
Kind regards!
No, the correct method is precisely as Apple explained to you. You need to put the UIPickerView -INSIDE- a UIPopover. Below is a link to another question/answer that would be a good reference for you:
UIPopoverController too large and UIPickerView too small
I do understand how to go about making the UIKeyboard push up the UIView if the active UITextView is blocked by the UIKeyboard as per this question: How to make a UITextField move up when keyboard is present?.
What I'm wondering is, from a design perspective, how do you go about implementing the keyboardDidShow and keyboardDidHide methods so that all of the views in your app, whether they be a UIView, UITableView, or UIScrollView all have this functionality and so you need to implement these methods only once?
The only way I could think of would be to have the view property of the UIViewController always set to a UIView, and if you have a UIViewController that needs a UIScrollView or UITableView, just attach it as a subview to this. Then if the UITextView is being blocked, just move the parent UIView up so it will move all of the views that are attached to it.
Does this sound like a good plan, or is it even worth it? Anyone else have any other ideas?
This is a little old, but it's a great article about using firstResponder methods to tell views to slide up. I, personally, like to put my UITextField in a parent container and move it all up. However, I do NOT suggest putting everything in there and moving it all up, because the UITextField "feels" better just above the keyboard. But I do like the background or certain items to move up with the UITextField.
See below: http://cocoawithlove.com/2008/10/sliding-uitextfields-around-to-avoid.html
This is a nice implementation that moves the field up based on the section of the screen it's in (upper, middle, lower). Works very well. May need to be updated for newest SDK, but should be pretty easy.
In experimenting with this, I noticed that if you want to make a BaseViewController that implements this functionality to work for everything that inherits from it, you have to attach another view on top of the UIViewController's view property in order to get it to work. Reason is, if you push the UIViewController's view property up when the keyboard appears, then it resets itself if the app comes back from being active and it's messy.
The problem with this however, is now in all of your child classes you have to attach your subviews to this new view property instead of the regular view property. Also, you probably have to make a custom UITableViewController which will inherit from your BaseViewController class so it can inherit the keyboard notification methods.
Ultimately, I've found it's not the worst idea to have another view on top of the UIViewController's property for a bunch of different scenarios. Making a custom UITableViewController isn't that big of a deal either. So if you have a lot of text fields in your app, this might not be the worst way to go.
I have created a UITableView that is of type UITableViewStyleGrouped. I have then created several different sections with a few rows in each. Within each of these rows I have created a custom UITableViewCell that contains a UITextField. I also have one UITableViewCell that contains a UITextView.
I have also implemented a UIToolbar that appears on top of the UIKeyboard that allows the user to move through the UITextField's by pressing previous or next.
The issue I'm having is two-fold:
I need the UITableView to scroll so that when the next UITextField (or UITextView) becomes the first responder it is visible (even with the keyboard being displayed).
When a UITextField (or UITextView) is selected (without using the previous and next buttons) is should adjust so that the field is visible above the keyboard.
I have looked around at lots of different tutorials however none of them have resolved my issue. Any help you could offer would be hugely appreciated.
ADDITIONAL INFO:
I'm 100% certain that my app used to do all of the above automatically, however I seems to have stopped doing it now and I don't understand why. Is there a reason why this may of happened? Is there some function or something that I may have changed that would destroy this behaviour?
Probably no use to original poster now, but those having an issue like this where it once did work and then stopped...
check you don't have a:
- (void)viewWillAppear:(BOOL)animated
in your UITableViewController subclass!!!
using viewWillAppear in a UITableViewController breaks the "automagic tableView scrolling up when keyboard appears" behaviour.
I only found this by comparing laboriously an old version of a project where it did work with my latest source where it had stopped working.
Check out TaggedLocations sample code from apple. It does the same thing without any extra manipulation.
The key is that your viewcontrollers are following the standard. i.e you are NOT having container viewcontrollers such as UINavigationController within UIViewController.
You have to update tableview Frame yourself programatically...
and i am 100% sure that if you are 100% certain that your app used to do all of the above automatically ...than it is not your app.
Check the docs..here is the link
https://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/ManageTextFieldTextViews/ManageTextFieldTextViews.html#//apple_ref/doc/uid/TP40009542-CH10-SW1
You will have to register for keyboard notifications..and then update your tableview frame.
And for next and previous.. you have to programmatically check which textfield became active..and then set the frame accordingly.
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!