This is a bit of a strange error.
I have a log-in screen which accepts a username and password inside two UITableViewCells. When the app first loads, this screen works fine.
It loads another screen which allows a user to log-out - this reloads the original screen and the user is capable of logging in again (or with a different username and password).
If the user logs out again, the original screen presents itself but the UITextFields associated with the username and password will not work. textFieldDidBeginEditing is not called - even though it was successfully called on the previous two attempts.
The "loading screen" .XIB file is loaded fresh each time - so I simply don't understand why the third time would cause problems?
Any suggestions would be greatly appreciated!
Thanks
It is look like timing issue to me. It may happen while changing(transition) the views. Some how your textfield can not be the first responder.
I would check who is the first responder?
Can you try call resignFirstResponder for the view which is responsible for logging out, just before logging out.
Another problem may be you finger does not touch exactly on text field but table view cell.
Did you implement the tableView:didSelectRowAtIndexPath: ?
Related
Okay i have two urtext fields, when i click on one of them, the keyboard shows.
now i have another button so when the user clicks it, i want to hide the keyboard (okay it is a stupid design, but i am just learning).
when the user clicks that button, what i do in code is calling the resignfirstresponder method on both of the ui text fields like this:
self.firstuitextfield.resignFirstResponder()
self.seconduitextfield.resignFirstResponder()
and by some maject the keyboard disappear, my question is why is that?
I just removed the first responder from them, and that means, according to this question, they will not receive the messages first anymore. How can this make the keyboard disappear? and bty who now becomes the first responder?
Nobody is the first responder! That's what's happening! And if they're no responders, then the keyboard hides! Pretty nifty, right? But if you want one line of code to do this, try self.view.endediting(true), instead.
I've had a crash report, it's a real edge case. I launch a pin security view from applicationWillEnterForeground (the feature is optional). However, I have some form sheets which I use in some situations in my app.
So the pin view is added as a subview on window and a keypad is presented.
When the form sheet is showing, it appears on top of the pin view (which is wrong) and an action on the form sheet causes a crash, when showing another keypad.
So I believe I need to dismiss any form sheets if the application resigns / becomes active.
I've looked into sending a notification to the form sheet in applicationWillEnterForeground, however I'll have to firstly determine if a form sheet is visible then add method to dismiss it every form sheet.
This seems a lot of work for an edge case, can anyone suggest an alternative approach?
For completeness here's the error...
The layout constraints still need update after sending -updateConstraints to <_UIKeyboardLayoutAlignmentView: 0x14e59b790; frame = (0 0; 0 0); userInteractionEnabled = NO; layer = >. _UIKeyboardLayoutAlignmentView or one of its superclasses may have overridden -updateConstraints without calling super. Or, something may have dirtied layout constraints in the middle of updating them. Both are programming errors.
I've seen this...
NSInteralInconsistencyException - UIKeyboardLayoutAlignmentView
However, I'd still need to end editing in various form sheets, which I can't access from applicationWillEnterForeground.
OK, after researching the issue I discovered that I needed to observe the application state. On notification then check if various objects are load and if so, resignFirstResponder when the keyboard is shown (aka is editing) (I had a text field in an UIAlertView), dismiss an UIAlertView and then dismiss in the view controller used in dialog.
Shesh... so not as simple as I was hoping.
Although this is an edge case for me, I figured I should fix it.
I also found this which will dissmiss alertviews https://github.com/sdarlington/WSLViewAutoDismiss
Which will save me a lot of hassle in simpler scenarios.
Apparently since iOS4, Apple recommends cancelling UIAlertViews and UIActionSheets when an application becomes active.
I have a registration form and I want to have the keyboard always on top.
The way I'm doing it now, is that when the user moves between view controllers, in viewDidLoad, the first UITextField becomes the first responder.
The problem is that the keyboard flickers (disappears and then appears again) when the user moves between view controllers.
Also, related to this: I have a form with a few uitextfields. When the user presses next it goes to the next uitextfield using becomefirstresponder. When the user is in the last textfield, the keyboard button becomes "Done". Then, when the user presses it, if there's an error with the last field, it should get the focus (calls becomeFirstResponder) but that doesn't happen (nothing get's the focus and the keyboard goes down). All the other fields get the focus fine, just this last field doesn't. I've tried about everything: switching to other textfields and back. The problem is that done automatically removes the keyboard.
You should have made two separate questions for this.
First, your flickering:
I'm guessing you're using a UINavigationController. You can add an invisible UITextField somewhere in the UINavigationController, which you give focus before you switch to a new ViewController. Then, when the new ViewController has appeared (viewDidAppear), set the focus to the first textField as you want.
However, the entire approach is kind of hackey and I don't recommend you use it. Instead, try using several views in a scrollView, of which you change the offset when you move to the new view. This will also solve the flickering.
Second, losing firstResponder status on Done:
The done button is specifically there to indicate exactly that which it says; Done. Pressing this assumes the user is finished and that no text is left to type, thus dismissing the keyboard.
If you really want to keep the Done button, then try the following;
Allow the user to dismiss the keyboard.
Upon dismissal, check for the error in the last field.
If there is an error, instead of calling [lastField becomeFirstResponder], try [self performSelector:#selector(thisSelectorWillCallFirstResponder) withObject:nil afterDelay:1.0].
In the method thisSelectorWillCallFirstResponder call [lastField becomeFirstResponder].
This will give time for the keyboard to disappear, before making it pop up again, so it doesn't interfere with the becomeFirstResponder call.
Another method would be to not use a Done button, but instead use the return key. You can intercept return anytime with the delegate method textFieldShouldReturn:. There you can handle any error checking, without causing the textField to lose its focus.
This is one of those "it was working a while ago" troubleshooting efforts.
I'm working on the document preview view controller, in which is a scroll view, which itself contains subclasses of UIView that represent each document. I'm modeling this pretty closely to how Keynote handles its document preview, except I build my scroll view horizontally and with paging. But the standard user experience is present: Long press on a document icon causes all document icons to start jiggling, nab bar has + button and Edit button, etc.
The issue at hand is that when you tap on the name of a document, I hide all the others, move the one being edited front and center, build a new text edit field, add it as a subview atop the real name label, and set it as first responder; but the
[editNameTextField setClearButtonMode:UITextFieldViewModeWhileEditing];
while correctly showing in the edit field is not taking any action when the user taps on the clear button.
I can't figure out what I may have done to cause this to not work -- it had been!
My first thought was that somehow my instance of this subclass is no longer the delegate for this text edit field. To try and confirm/deny that, I usurped a tap on the image view of the document preview to compare the delegate property to self, and it passes.
if (editNameTextField) {
NSLog(#"editNameTextField is still active");
if ([editNameTextField.delegate isEqual:self]) {
NSLog(#"we're still the delegate for the editNameTextField");
}
}
Editing the text within the edit field works fine. Pressing the Return/Done key correctly sends the delegate message textFieldShouldReturn:
While investigating this I implemented the delegate method textFieldShouldClear: just to write a log message if the method gets called (and return YES of course). It never gets called.
My next thought was that perhaps a subview had covered up the area where the clear button sits. So I implemented textFieldShouldBeginEditing: and used the opportunity to bring my the text field to the front. That didn't change anything either. I set a debugger breakpoint there to play a sound when it was called, and it got called, so I know my text edit field is frontmost.
I have only one troubleshooting strategy remaining: Go backwards through snap shots until it starts working again. Before doing that I thought I'd see if any of the more experienced folks out here have any suggestions of what to try next.
Where are you adding the textfield? As a subview of the scrollView? If you added the textfield and it is out of bounds of its parent view it won't receive any touches.
You can try and not call becomeFirstResponder and see if clicking it will show keyboard. Another possible error might be that the parent view of the UITextField has userInteractionEnabled = NO.
Without seeing more code I'm afraid I can not offer more solutions.
I'm trying to use the MFMailComposeViewController in an iPhone app I'm building, but I can't get it to work correctly. I was following the Apple's sample code MailComposer. As you can see in the sample, the MFMailComposeViewController lets you type in whatever message you want, and in the case of recipients you can either type the email addresses or pick them from your contacts. My implementation is exactly as in the sample, and the MFMailComposeViewController appears and disappears as expected. However, the controller seems to be in read-only mode; i.e., the user can't change any of the fields. I can change the values of the different fields programmatically before showing the controller, but once it's visible no modifications can be done to any of the fields. I have checked everything a bunch of times, but I can't find anything different between my implementation and Apple's. I'm stumped! Has anyone encountered this issue before? Any suggestions?
Thanks a lot for any help you all can provide!
Found the problem! A parent view controller in my application listens to shake gestures, which requires that view controller listening for shakes becomes the first responder. The parent view controller needs to call
[self resignFirstResponder];
before showing the MFMailComposeViewController. After adding that line, the MFMailComposeViewController worked like a charm.
In general, any view controllers listening for shake gestures should resign first responder before showing any other view controllers. Otherwise, the app will continue to respond to shake gestures even when the corresponding view controller is not visible, which can definitely lead to even worse problems than the MFMailComposeViewController showing up in weird read-only mode.