响应者动作和响应者链
尽管我已经达到了开发真正（希望）可销售的应用程序的程度，但我对 iPhone 编码还比较陌生。
但仍然神秘的一件事是响应者链。所有的书都简要地提到了它，但我还没有找到一本描述如何修改该链的书。另一个令人好奇的是，当在 IB 中单击“第一响应者”图标时，会出现一个小连接框，其中包含各种连接某物的选择，但我从未找到对此的任何解释。
有谁知道这个响应程序的深入解释？
I am relatively new to IPhone coding, although I have reached the point of working on a genuine (hopefully) saleable app.
But one thing that is still mysterious is the responder chain. All the books give passing reference to it, but I have not found one yet that describes how to modify that chain. Another curiosity is that, when the First Responder icon is clicked in the IB, a little hookup box comes up with all sorts of choices to hook up to something, but I've never found any explanation of that.
Does anyone know of an in-depth explanation of this responder process?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是 Jeff Lamarches 对响应者链的解释。虽然并不详尽，但它应该能让您思考正确的方向。
Here's Jeff Lamarches explanation of the responder chain. While not at all exhaustive, it should get you thinking on the right track.
响应者链是各种对象有机会处理事件的顺序。在一个简单的例子中，假设我们在 NSApp 的 NSWindow 中的 NSView 中有一个按钮。当按钮被点击时；按钮将首先有机会处理事件，然后是它的控制器，然后是 NSView，然后是它的控制器，然后是 NSWindow，然后是它的委托，然后是 NSApp 和它的委托。通过这种方式，对象首先有机会处理事件，然后是它的控制器/委托，然后是对象的容器等等。还有其他情况更复杂。
对象通过实现 -(void)respondToFictionalEvent:(UIEvent *)event 来处理事件。如果发生这种情况，则该事件将被“消耗”（防止自动进一步传递到链上）。
The responder chain is the order in which various objects are given the chance to handle an event. In a simple case, suppose we have a button in a NSView in a NSWindow in a NSApp. When the button is clicked; the button will have the first opportunity to handle the event, then its controller, then the NSView, then its controller, then the NSWindow, then its delegate, then the NSApp and its delegate. In this way, an object is first given a chance to handle the event, then its controller/delegate, then the container of the object and so on. There are other cases that are much more complicated.
An object handles an event by implementing -(void)respondToFictionalEvent:(UIEvent *)event. If this happens, then the event is "consumed" (prevented from being automatically passed further up the chain).