因此，我试图模拟在管理电话号码时标准Apple代码在联系人应用中工作的方式。具体来说，我正在从tableview删除一行，如果它的空和用户导航到任何其他行从textFieldDidEndEditing调用reloadData后对UITableView不正确indexPath
我的问题是，随着tableview重新载入导致UITextField退出其响应者，我需要设置响应者再次由用户导航到文本字段
我给出UITextField委托和正在处理的通常textFieldShouldBeginEditing , textFieldDidBeginEditing , textFieldShouldEndEditing , textFieldDidEndEditing
为了处理的功能，我的代码中textFieldDidEndEditing，因此我从删除数据tableview数组，并且由于tableview有两个部分，我打电话给：
[MyTableView reloadSections:[NSIndexSet indexSetWithIndex:1] withRowAnimation:UITableViewRowAnimationNone];
在textFieldDidBeginEditing我保存文本字段的indexPath正在编辑使用：
EditableCustomCell *textFieldCell = (EditableCustomCell *)[[textField superview] superview];
NSIndexPath *indexPath = [MyTableView indexPathForCell:(EditableCustomCell *)textFieldCell];
responderIndexPath = [NSIndexPath indexPathForRow:indexPath.row inSection:indexPath.section];
我然后使用以下代码来设置正确的行文本字段为第一响应者：
EditableCustomCell *customCell = (EditableCustomCell *)[MyTableView cellForRowAtIndexPath:responderIndexPath];
[customCell.editableTextField becomeFirstResponder];
一切似乎都很好，直到处理结束时，突然textFieldDidBeginEditing开始为indexPath返回第0行0（即使在检查标记值或包含的文本时返回正确的值S为文本框）
下面是从过程的开始日志上面解释：
- textFieldDidEndEditing started <-- start of delete processing
- textFieldDidEndEditing - tableviewData - replacing object at index 1
CustomTableViewController.deleteRow - delete called for indexPath section 1 ... row 1
- reloading MyTableView
- CustomTableViewController-cellForRowAtIndexPath started
CustomTableViewController-cellForRowAtIndexPath section=1 row=0
CustomTableViewController-cellForRowAtIndexPath ending
CustomTableViewController-cellForRowAtIndexPath section=1 row=1
CustomTableViewController-cellForRowAtIndexPath ending
CustomTableViewController-cellForRowAtIndexPath section=1 row=2
CustomTableViewController-cellForRowAtIndexPath ending
- textFieldShouldBeginEditing started
indexPath for textFieldShouldBeginEditing is : section 1 row 1
- textFieldShouldBeginEditing ending
- textFieldDidBeginEditing started
indexPath for textFieldDidBeginEditing is : section 1 row 1 text 3 tag 1
- textFieldDidBeginEditing ending
- textFieldDidEndEditing ending <-- end of delete processing
- textFieldDidBeginEditing started
- textFieldDidBeginEditing ... setting responderIndexPath section 0 row 0
indexPath for textFieldDidBeginEditing is : section 0 row 0 text 123 tag 0
- textFieldDidBeginEditing ending
由于可以从日志的最后一部分中可以看出，后textFieldDidEndEditing完成，textFieldDidBeginEditing的调用，但回报第0行和第0行（行保持显示并始终可见）
我不明白为什么会调用它，或者它为什么没有返回正确的indexPath。可以看出，文本是返回值（在这种情况下输入值123），我已经验证了这与其他数据和其他行（对于文本和标签的文本域）
也许我的设置内textFieldDidEndEditingbecomeFirstReponsder是不正确，但如果这是真的，我在一个亏损在何处处理此
希望有人在那里有一个更好的了解这可以帮助我，因为你可以告诉我”已经经过了几个小时没有任何分辨率
谢谢 Izzy
编辑1：在代码中，所有在textFieldDidEndEditing完成之前调用的是becomeFirstReponder。当您在cellForRowAtIndexPath完成后查看日志时，它将进入并存在文本字段TWICE，一次是刚刚删除的行下方的行，然后是对indexPath的节/行返回0时再次存在的文本字段？我不理解什么事件序列导致的方法
EDIT 2这一职位表重载射击：难道只是我，或者它看起来真的很奇怪，有前textFieldDidBeginEditing在NO textfieldSHOULDbeginEditing日志的结尾？难道我在textFieldDidEndEditing期间通过重新加载表来解决内部过程？有没有更好的地方做这件事（即删除一行并重新加载tableview以显示UI更新）？
'indexPathForCell：'返回* nil *如果单元格当前不可见。这有帮助吗？ – 2012-07-31 20:17:01
感谢马丁，是的，我意识到这一点，但感谢提醒，我没有提及它是可见的（在正文中） – 2012-07-31 21:30:10