NSWindow delegate handling keyboard events
-
Apple's event handling says that a windows delegate is part of the
responder chain, and that the delegate doesn't need to inherit from
NSResponder.
I'm making a simple application, and subclassing NSWindow seems like
overkill for interpreting a few keyDown and keyUp events. How would my
window's delegate respond to those events? Implementing
keyDown:(NSEvent *)event in the delegate doesn't do the trick though
the documentation seems to imply that it would. -
On Fri, 18 Feb 2005 23:18:00 -0500, "Andrew O'Laughlin" <generac...>
said:
> Apple's event handling says that a windows delegate is part of the
> responder chain, and that the delegate doesn't need to inherit from
> NSResponder.
If it says that, then "Apple's event handling" lies.
> I'm making a simple application, and subclassing NSWindow seems like
> overkill for interpreting a few keyDown and keyUp events. How would my
> window's delegate respond to those events? Implementing
> keyDown:(NSEvent *)event in the delegate doesn't do the trick though
> the documentation seems to imply that it would.
It wouldn't. A window's delegate is not part of the chain. But the window's
controller is (this is why NSWindowController inherits from NSResponder). It
is also very easy to insert a special NSResponder object into the chain
(above the window, for example). m.
--
matt neuburg, phd = <matt...>, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide
<http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt> -
On Feb 19, 2005, at 9:46 AM, Matt Neuburg wrote:
> On Fri, 18 Feb 2005 23:18:00 -0500, "Andrew O'Laughlin"
> <generac...>
> said:
>> Apple's event handling says that a windows delegate is part of the
>> responder chain, and that the delegate doesn't need to inherit from
>> NSResponder.
>
> If it says that, then "Apple's event handling" lies.
>
>> I'm making a simple application, and subclassing NSWindow seems like
>> overkill for interpreting a few keyDown and keyUp events. How would
>> my
>> window's delegate respond to those events? Implementing
>> keyDown:(NSEvent *)event in the delegate doesn't do the trick though
>> the documentation seems to imply that it would.
>
> It wouldn't. A window's delegate is not part of the chain.
Actually, it is, but it's after the window itself. In this case, the
event is probably getting consumed by the window. IIRC, NSWindow's
-keyDown: method just plays a beep sound.
According to the docs:
the full responder chain comprises these objects:
The key window’s first responder and successors, including objects
added with setNextResponder:
The key window itself
The key window’s delegate (which need not inherit from NSResponder)
The main window’s first responder and successors, including objects
added with setNextResponder:
The main window itself
The main window’s delegate (which need not inherit from NSResponder)
The application object, NSApp
The application object’s delegate (which need not inherit from
NSResponder)
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html -
On or about 2/19/05 6:06 PM, thus spake "John C. Randolph" <jcr...>:
>
> On Feb 19, 2005, at 9:46 AM, Matt Neuburg wrote:
>
>> On Fri, 18 Feb 2005 23:18:00 -0500, "Andrew O'Laughlin"
>> <generac...>
>> said:
>>> Apple's event handling says that a windows delegate is part of the
>>> responder chain, and that the delegate doesn't need to inherit from
>>> NSResponder.
>>
>> If it says that, then "Apple's event handling" lies.
>>
>>> I'm making a simple application, and subclassing NSWindow seems like
>>> overkill for interpreting a few keyDown and keyUp events. How would
>>> my
>>> window's delegate respond to those events? Implementing
>>> keyDown:(NSEvent *)event in the delegate doesn't do the trick though
>>> the documentation seems to imply that it would.
>>
>> It wouldn't. A window's delegate is not part of the chain.
>
> Actually, it is, but it's after the window itself. In this case, the
> event is probably getting consumed by the window. IIRC, NSWindow's
> -keyDown: method just plays a beep sound.
>
> According to the docs:
> the full responder chain comprises these objects:
>
> The key window¹s first responder and successors, including objects
> added with setNextResponder:
>
> The key window itself
>
> The key window¹s delegate (which need not inherit from NSResponder)
>
> The main window¹s first responder and successors, including objects
> added with setNextResponder:
>
> The main window itself
>
> The main window¹s delegate (which need not inherit from NSResponder)
>
> The application object, NSApp
>
> The application object¹s delegate (which need not inherit from
> NSResponder)
That list may describe correctly some responder chain (I do not think it
does, but it may); but it most certainly does not describe correctly the
responder chain the OP is asking about, namely, the chain of responders to a
keyDown event. m.
--
matt neuburg, phd = <matt...>, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide! NOW SHIPPING...! (Finally.)
http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/ -
On Feb 19, 2005, at 6:53 PM, Matt Neuburg wrote:
> On or about 2/19/05 6:06 PM, thus spake "John C. Randolph"
> <jcr...>:
>
>>
>> On Feb 19, 2005, at 9:46 AM, Matt Neuburg wrote:
>>
>>> On Fri, 18 Feb 2005 23:18:00 -0500, "Andrew O'Laughlin"
>>> <generac...>
>>> said:
>>>> Apple's event handling says that a windows delegate is part of the
>>>> responder chain, and that the delegate doesn't need to inherit from
>>>> NSResponder.
>>>
>>> If it says that, then "Apple's event handling" lies.
>>>
>>>> I'm making a simple application, and subclassing NSWindow seems
>>>> like
>>>> overkill for interpreting a few keyDown and keyUp events. How would
>>>> my
>>>> window's delegate respond to those events? Implementing
>>>> keyDown:(NSEvent *)event in the delegate doesn't do the trick
>>>> though
>>>> the documentation seems to imply that it would.
>>>
>>> It wouldn't. A window's delegate is not part of the chain.
>>
>> Actually, it is, but it's after the window itself. In this case, the
>> event is probably getting consumed by the window. IIRC, NSWindow's
>> -keyDown: method just plays a beep sound.
>>
>> According to the docs:
>> the full responder chain comprises these objects:
>>
>> The key window’s first responder and successors, including objects
>> added with setNextResponder:
>>
>> The key window itself
>>
>> The key window’s delegate (which need not inherit from NSResponder)
>>
>> The main window’s first responder and successors, including objects
>> added with setNextResponder:
>>
>> The main window itself
>>
>> The main window’s delegate (which need not inherit from NSResponder)
>>
>> The application object, NSApp
>>
>> The application object’s delegate (which need not inherit from
>> NSResponder)
>
> That list may describe correctly some responder chain (I do not think
> it
> does, but it may); but it most certainly does not describe correctly
> the
> responder chain the OP is asking about, namely, the chain of
> responders to a
> keyDown event. m.
There is a responder chain per window, which is the same for any
message. The first object in that chain that responds to the message
in question will be the one that gets it. (Of course, it can also send
the message along to the next responder if it cares to.)
-jcr
John C. Randolph <jcr...> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html -
On or about 2/20/05 2:41 AM, thus spake "John C. Randolph" <jcr...>:
>
> On Feb 19, 2005, at 6:53 PM, Matt Neuburg wrote:
>
>> On or about 2/19/05 6:06 PM, thus spake "John C. Randolph"
>> <jcr...>:
>>
>>>
>>> On Feb 19, 2005, at 9:46 AM, Matt Neuburg wrote:
>>>
>>>> On Fri, 18 Feb 2005 23:18:00 -0500, "Andrew O'Laughlin"
>>>> <generac...>
>>>> said:
>>>>> Apple's event handling says that a windows delegate is part of the
>>>>> responder chain, and that the delegate doesn't need to inherit from
>>>>> NSResponder.
>>>>
>>>> If it says that, then "Apple's event handling" lies.
>>>>
>>>>> I'm making a simple application, and subclassing NSWindow seems
>>>>> like
>>>>> overkill for interpreting a few keyDown and keyUp events. How would
>>>>> my
>>>>> window's delegate respond to those events? Implementing
>>>>> keyDown:(NSEvent *)event in the delegate doesn't do the trick
>>>>> though
>>>>> the documentation seems to imply that it would.
>>>>
>>>> It wouldn't. A window's delegate is not part of the chain.
>>>
>>> Actually, it is, but it's after the window itself. In this case, the
>>> event is probably getting consumed by the window. IIRC, NSWindow's
>>> -keyDown: method just plays a beep sound.
>>>
>>> According to the docs:
>>> the full responder chain comprises these objects:
>>>
>>> The key window¹s first responder and successors, including objects
>>> added with setNextResponder:
>>>
>>> The key window itself
>>>
>>> The key window¹s delegate (which need not inherit from NSResponder)
>>>
>>> The main window¹s first responder and successors, including objects
>>> added with setNextResponder:
>>>
>>> The main window itself
>>>
>>> The main window¹s delegate (which need not inherit from NSResponder)
>>>
>>> The application object, NSApp
>>>
>>> The application object¹s delegate (which need not inherit from
>>> NSResponder)
>>
>> That list may describe correctly some responder chain (I do not think
>> it
>> does, but it may); but it most certainly does not describe correctly
>> the
>> responder chain the OP is asking about, namely, the chain of
>> responders to a
>> keyDown event. m.
>
> There is a responder chain per window, which is the same for any
> message. The first object in that chain that responds to the message
> in question will be the one that gets it. (Of course, it can also send
> the message along to the next responder if it cares to.)
There are two responder chains - one for nil-targeted actions, one for user
events such as keyDown:. They are different. One difference is: the
nil-targeted actions responder chain includes the window's delegate; the
user event responder chain does not. Try it; you'll see. m.
--
matt neuburg, phd = <matt...>, http://www.tidbits.com/matt/
pantes anthropoi tou eidenai oregontai phusei
AppleScript: the Definitive Guide! NOW SHIPPING...! (Finally.)
http://www.amazon.com/exec/obidos/ASIN/0596005571/somethingsbymatt
Subscribe to TidBITS! It's free and smart. http://www.tidbits.com/
