UIMenuController 和响应者链：发生了啥？

Posted 2023-03-12

【中文标题】UIMenuController 和响应者链：发生了啥？

【英文标题】：UIMenuController and the responder chain: what's going on?UIMenuController 和响应者链：发生了什么？

【发布时间】：2011-10-04 00:36:19

【问题描述】：

我在自定义 UIView 子类上使用 UIMenuController。这意味着它可以成为第一响应者，并在“删除”操作中声明它canPerformAction。

我还希望该视图的超级视图（也是自定义 UIView）能够使用菜单控制器，因此在该超级视图上，我已将其标记为能够成为第一响应者，并为不同的操作实现 canPerformAction （在这种情况下是“复制”和“剪切”）。

事情是这样的——当我使菜单从（第一个）子视图中可见时，它会将所有三个操作都放在菜单中：删除、复制和剪切。在调试器中，我看到canBecomeFirstResponder 和canPerformAction 在菜单出现之前在两个视图上都被调用了。

这里发生了什么？为什么菜单控制器不限于成为第一响应者的视图？还是我没有正确诊断？

谢谢。

【参考方案1】：

你用的是什么代码？

在canPerformAction:withSender: 的文档中，

如果响应者类实现了请求的操作，则此方法的默认实现返回 YES，如果没有，则调用下一个响应者。 ...请注意，如果您的类对命令返回 NO，则响应者链上的另一个响应者可能仍会返回 YES，从而启用该命令。

这似乎是矛盾的，说默认实现递归响应者链，但如果你返回 NO，UIMenuController 也会递归响应者链。

最简单的方法可能是覆盖 -nextResponder 以返回 nil，但这可能会产生其他副作用（例如，默认情况下，目标为“nil”的操作会沿响应者链向上！）。

【讨论】：

嗯，这就解释了。谢谢。我没有意识到响应者链是以这种方式使用的。看起来很容易将canPerformAction:withSender 逻辑包装在基于该子视图是否处于活动状态的条件中。很奇怪，但不会太痛苦。感谢您的指点！