views:

360

answers:

1

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?

+3  A: 

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 IBOutlets 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.

Alex
My delegate actually is an NSWindowController subclass. I am not using Interface Builder because I am trying to create a window that may or may not be borderless at the time of its instantiation, and IB doesn't seem to allow for that -- besides, I'm trying to learn the details, and IB hides a lot, so I thought for this app it would be worth learning "the hard way."Thank you for the link to that section of the docs. I'd read it, but missed the detail about the NSWindowController being the last resort. Clearly I've made some mistake in managing the responder chain.
EricB