因此，我試圖模擬在管理電話號碼時標準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