Building interfaces with Interface Builder is straight forward and simple. Visual Objects like windows and views support a wide range of methods that are called when the user interacts with the interface. It's possible to easily monitor events like the mouse moving or being pressed. For most applications this is more than enough control to do most tasks. However it is sometimes necessary to do something different. The Mapwing software on the Mac can make it seem like all the windows are key. No matter what window is selected certain events are sent to the window the mouse is over. This is useful for making the mouse cursor change and allowing one click to activate a window and perform an action.

One of these behaviors is provided by the NSResponder class, which NSWindow and NSView are derived. Overloading the acceptsFirstResponder method and returning YES provides the behavior of clicking an object and making the window key at once. This allows the programer to decided when this behavior is appropriate, adding simple logic to control the return value allows you to turn this feature on and off at run time.

The other behavior, sending events to the window the mouse is over not the key window, is not supported by NSResponder or any other class. To gain this functionality it is necessary to intercept events as they enter the application and reroute them to the appropriate responder. Events enter Cocoa Applications through NSApplication. Events (mouse, keyboard, and control) are sent to the sendEvent: method. NSApplication's default implantation takes these events and depending on their type dispatches them to different receivers, normally the NSWindow object defined by the window property of the event. With a little poking around in NSEvent and the Foundation Functions we can come up with some code to figure out what window the mouse is over. It is then a simple task of changing the event to reflect this new window. You can then call the sendEvent: method of that window with the event or pass the modified event to super and let it take care of the dispatching. It is very important to take care when modifying how NSApplication's sendEvent: works. Some of the events that pass through it are important to the proper operation of your application. NSEvent defines many different types of events, it's best only to change events of the type you want to control. Messing with events that are of type NSAppKitDefined or NSSystemDefined can produce odd behaviors. While I have found it necessary to change the behavior of some of the sub types of these events extreme care must be taken. To do this modification it will be necessary to create a custom subclass of NSApplication if you haven't already. If you've never done this check out Apple's documentation about NSApplication they have some tips and warnings that may be helpful. While your looking at the documentation check out the other things that NSApplication controls it maybe helpful to you to change their behaviors also.

Hopefully this was helpful to you, if you have any questions about this or any other Cocoa programing topic feel free to ask.