問題描述
為什麼 NSWindow 或 NSView 實例處理它自己的鍵事件,而不是它的委託? (Why does an NSWindow or NSView instance handle its own key events, and not its delegate?)
As a newcomer to Cocoa, I am struggling to understand why the generic NSResponder subclasses implement key events the way they seem to do.
In my program, I have an NSWindow subclass which takes up the whole screen, and must necessarily handle key events. There are several major commands which can change the whole state of the program (e.g. pause a timer when the user hits the spacebar) which it does not make sense to have subviews like an NSTextField handle.
It seems to me that the delegate (controller) should get these events. Instead, I find I have to either write a bunch of messy glue code to have the window (via its keyDown:
and interpretKeyEvents:
selectors) notify the controller, or I have to just move a bunch of controller code to the NSWindow subclass itself.
This is messy and my gut tells me I'm missing something. Is there a cleaner solution?
‑‑‑‑‑
參考解法
方法 1:
If you've set it up correctly, the NSWindow
's delegate will receive the messages. Cocoa uses the responder chain to forward messages from the first responder ‑‑ the key view for key messages, and the view that was clicked/hovered/etc. for mouse messages ‑‑ back through the superviews, up through the window, and eventually to the window's delegate. There's a pretty good diagram of the typical responder chain on Apple's site.
You really should never have to subclass NSWindow
unless you're implementing some fancy window drawing or something else along those lines. Cocoa provides the NSWindowController
class to behave as a controller for a window and its contents.
The usual pattern is to subclass NSWindowController
and add your IBOutlet
s to it, and then use a NIB to lay out your window contents. You make your NSWindowController
subclass the class of the File's Owner proxy in Interface Builder. And you also assign the window's delegate
to the window controller so that it can become part of the responder chain. Finally, to create windows, you use NSWindowController
's initWithWindowNibName:
method, which automates loading the NIB with a new window controller as the file's owner.
I'd recommend reading up on window controllers in the Cocoa documentation, because they provide the missing link you're looking for.