resignFirstResponder 导致 EXC_BAD_ACCESS答案

【问题标题】：resignFirstResponder causing EXC_BAD_ACCESSresignFirstResponder 导致 EXC_BAD_ACCESS
【发布时间】：2010-08-31 15:54:12
【问题描述】：

我在 UITableViewCell 上有一个 UITextField，在另一个单元格上有一个按钮。

我点击 UITextField（出现键盘）。

UITextField 调用了以下方法：

- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField {
        NSLog(@"yes, it's being called");
 owner.activeTextField = textField;
 return YES;
};

其中 owner.activeTextField 是一个（保留，非原子）属性。

问题当键盘可见时，我将单元格滚动到视图之外。然后我单击另一个单元格上的按钮。按钮调用：

[owner.activeTextField resignFirstResponder]

这会导致 EXC_BAD_ACCESS。

有什么想法吗？细胞肯定在内存中。我的猜测是，一旦它消失，它就会从视图中删除，并且它的一个属性（父视图？）变为 nil 并导致上述错误..

我说的对吗？

TL;DR;从视图中删除 UITextField 时，如何删除键盘（退出第一响应者）？

【问题讨论】：

一旦用户开始拖动 UITableView，我通过发送 resignFirstResponder 解决了这个问题。有人在答案中提出了类似的建议，然后删除了答案，所以我无法接受:(无论如何 - 我仍然不知道是什么导致了错误，但解决方法可以正常工作。
哇，这么奇怪的问题，但它完全为我解决了，谢谢！
我很高兴它有帮助 - 然后投票赞成这个问题:)
我已经做过了……你只能做一次。

标签： iphone cocoa-touch uitextfield first-responder

【解决方案1】：

有时问题可能更深...检查并确保响应者链中的下一个对象（随后接收 becomeFirstResponder 消息的对象）不是垃圾。只是一个想法。

【讨论】：

好主意.. 我检查了 textField 的 nextResponder 属性（以及 3 个 next 的 nextResponders），但它们看起来不错（重定向到现有对象），所以我猜不是这样。

【解决方案2】：

您是否检查过owner.activeTextField 以查看它是否已被释放/设置为零？不确定这是否会调用EXC_BAD_ACCESS，但值得一试。

你也有任何电话给NSNotificationCenter吗？我今天遇到了类似的事情，这导致becomeFirstResponder 上出现EXC_BAD_ACCESS，这是因为我在不正确的代表上调用了[[NSNotificationCenter defaultCenter] removeObserver:keyboardObserver];。

【讨论】：

【解决方案3】：

有点老了，但由于我在使用旧的手动引用计数应用程序时遇到了同样的问题，我会试一试。注意：这个问题不应该再发生在 ARC 上（如果发生了，我的解决方案肯定不适合那里......）。

似乎发生的事情是：

文本字段被保存到单元格中并（可能超过）保留
当您使用文本字段滚动单元格时，单元格会被回收（这很好），但文本字段不会（这就是当错误发生时文本字段仍在内存中的原因）
此时，关闭键盘正确地退出了文本字段的第一响应者，但随着调用在视图层次结构中向下传播，它击中了不再存在于内存中的单元格。

解决这个问题的一个简单（和 imo 优雅）的方法是

修复 uitextfield 的过度保留（如果有）
子类 UITextField 以在被释放之前放弃第一响应者状态

一个方法，像这样：

- (void) dealloc {
  [self resignFirstResponder];
  [super dealloc];
}

将是必需的，这将具有在单元格消失后立即移除键盘的副作用。

另一种解决方案（由于各种原因，这是我选择的那个）是手动保留和回收带有文本字段的单元格，直到表被释放。

我确定您已经解决了您的问题，但我希望这对其他人有所帮助...

【讨论】：