I have a UITableViewController with custom UITableViewCells that contain a UITextField. When switching the table view into edit mode, I add a new cell to the bottom of the table and would like to make this cell becomeFirstResponder. My tableView:cellForRowAtIndexPath: method checks for this bottom cell, so I just added the line:
[cell.theTextField becomeFirstResponder];
Which I believed should work. However, when the table view is first displayed, it does not seem to be working. BUT if I select the cell (making it the first responder), then go out of edit mode (causing a resignFirstResponder within my code), I can then go back into edit mode and magically it becomes the first responder as I would expect!
Note that even if I end editing mode with a different cell selected (they all have text fields) and go out of edit mode, then back in, it still works, as long as at some point I had made the last cell becomeFirstResponder (by selecting it).
So, my guess is that when it first becomes the first responder, there is something getting set either in the table view or some place else that wasn't originally set, and from then on it makes this work.
Anyone have any ideas as to what may be going on here?
The first becomeFirstResponder call fails because the cell doesn't have a superview yet. The table view adds the cell as its subview after you return it from tableView:cellForRowAtIndexPath:. I suggest you make this call somewhere else. If you already have a custom UITableViewCell subclass, you could implement didMoveToWindow: and call [self becomeFirstResponder] there.
Related
In my UITableView I have rows which contain 4 textfields each. After user ends editing couple of things in UITableView datasource are being recalculated, so I need to reload UITableView after edition of textfield. But because tableview is being reloaded, when user touches another textfield to edit while editing the first one, second textfield doesn't get selected. He has to touch it again before it can be edited.
Is there a way to avoid this behaviour? Unfortunately I do need to use reloadData instead of reloadSections or reloadRows methods. Any help will be appreciated, thanks!
Reloading a table view will resign the first responder of the text field or even text view. You could try this trick if you have multiple changes that need to be made.
[[self tableView] beginUpdates]
[[self tableView] endUpdates]
Try assigning a gestureRecognizer to each field or same one to all fields. Once you capture the touch in required field, capture the tag and make that field the firstResponder.
Summing up all the help I received and my own ideas I've gone with the following:
-Delay reload for 0.01 sec so textFieldDidBeginEditing gets called
-Then save textfield's tag and cell's index path to variables in textFieldDidBeginEditing
-Call reloadData on tableview
-Call becomeFirstResponder on textfield saved with variables
This however caused keyboard hiding for a brief moment as it didn't have any responder during reloading. To resolve that I created a fake textfield in tableview's superview and assigned him as a responder up to a moment when tableview was reloaded to assign back to the textfield that was selected by a user.
Certainly not the cleanest solution, but it works.
I have a UITableViewController with custom cells for static and editable text. Standard stuff, nothing fancy.
The cell data is stored so that when cells are reused, the data is placed back inside them.
The problem is this: when the user has the cursor in a UITextField cell and the keyboard's up, the keyboard is covering three rows in the table view. There's a cancel button at the top of the view controller which is supposed to dismiss the view controller. When I call dismissModalViewController, the keyboard hides, but the UITableViewController wants to refresh the rows that were under the keyboard while the view's going away. However, the view's already in its death throes and I get a crash because the table view's trying to call cellForRowAtIndexPath to update rows that are in the process of being removed.
I tried waiting for the keyboard to hide. No good.
I tried resigning the first responder so the keyboard goes away and updates the rows first before dismissing the view controller, but there's nothing I can find that tells me the data's finished updating.
What I need is some event that tells me that the table is finished updating, or tell the table view to not ask for data from the delegate, or tell the table view to not update when the keyboard is going away.
Or there's something simple I'm missing.
Any help?
If you have not more cells, i advice you to make a different Reusable Identifier for each cell.That very better to save the state of cells after being dequeued
I solved my own problem. Inside cellForRowAtIndexPath, I was setting text inside a UITextField for pointers that may no longer exist. What I did to fix the problem was still create the cell, but before setting the text inside it, I checked if the Cancel button was pressed and if it was, return the empty cell.
I was hoping there'd be a better solution such as waiting for the cells to finish updating, but that doesn't seem to be happening.
I have a group table view with 10 sections, each section has one cell, and each cell has a text field inside.
When user tap on a text field I scroll its parent cell to bottom, so that it will be exactly above the keyboard.
Every text field has a "Next" return key, so when user tap it the next text field (in the cell below) should be first responder.
The problem is:
Suppose user tap on a text field of cell at index 5, this will make the keyboard pop up and the tableview will scroll so this cell will be right above the keyboard.
Now user press the next button..
What I want to happen is to make the text field of cell at index 6 become the first responder.
But how do I get this text field??
If I try to get the cell with cellForRowAtIndexPath I'll get nil, because the cell is invisible..
Two solutions come to mind:
1) you don't have many cells, so don't recycle them, create them when you startup and put them in an array where you can easily get them, Then, when the tablview asks for cells, you pull them out of your array.
When you want to go to next, you simultaneously tell the tableview to scroll to such and such a location or cell, and you pull the cell out of the array, add it to your view with some offscreen frame so it cannot be seen, and make the textField the first responder (to keep the keyboard up). when the tableView asks for the cell, you MAY need to reset the frame, or both reset the frame and remove it from the view. If you find you need to do this you MAY need to make it the first responder again soon (dispatch a block to the main queue so that the text field never resigns first responder.
2) Similarly, when you want to make a cell's textField the first responder, and its contained in the visible cells, then you can just scroll and make it the first responder. If its not in the visibleCells, create a cell, add it to the view as above, do the first responder stuff as above, and when you are asked for THAT cell's index, supply that cell, possibly resetting the frame.
I've used offscreen textFields to play tricks with the keyboard (to keep it up, to get it up, etc - so I know that works). What's less certain to me are the tricks with the textField being in the view or not.
This makes me think of a 3rd way. You put a UITextField offscreen in the view. When you want to switch, and the cell is not yet visible (that is, created), you tell the offscreen textField to be firstReponder, then track the tableView scrolling, and when it ends the textField you WANT s first responder is now visible, so you can transfer (ie set) firstResponder on it, keeping the keyboard up.
I do not know how you create your rows but you need to consider, that UITableView recycles the cells. That means that the text field could be theoretically the same as before, just the content changes.
So all you need to do is make sure you know the textfield that is positioned right above the keyboard. I would not be surprised if this will be created when the view enters and never actually changes.
Again, the table recycles the cells and their content holders only filling in the corresponding data for the row as you provide it.
If you post your code that creates and recycles the cells I could be more specific.
I have a custom UITableViewCell completely written in code (no IB), it has an accessory button that simply calls didSelectRowAtIndexPath on the table view, and it works correctly and the method is called without problems.
However, when I tap on the cell itself (not on the accessory view) nothing being called, why ?
EDIT: the code is huge to put here ... however, the custom cell contains a ton of labels, couple images and scroll view ...
This is a shot in the dark, but if each cell has many different objects on it (i.e. images, labels, etc) then it may not be working because those objects are what the user is hitting when they try to click a cell. Does the cell turn blue (indicate selection) at all? If not, try hiding/removing those objects for now and see if it works.
If that is the case, then what you may want to do is create an invisible cell or button that sits on top of the other objects and calls didSelectRowAtIndexPath from behind the scenes.
This should solve your problem:
Raise selection event (didSelectRowAtIndexPath) when subview of UITableViewCell is tapped
Try setting your view's userInteractionEnabled property to NO.
This will make it ignore all touch events, and then the views under it will be able to catch these events. - Felipe Sabino
I'd partially answer my question: the wide scroll view is preventing the cell from calling didSelectRowAtIndexPath, removing the scrollView will solve the problem, however, I want to call this method with the existence of the scrollView ... anyone got ideas would be highly appreciated ...
You must post your code to understand what have you done...You have to check out this example to understand whether your code is correct or not...
http://www.edumobile.org/iphone/iphone-programming-tutorials/impliment-a-custom-accessory-view-for-your-uitableview-in-iphone/
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.