Re: NSWindow delegate handling keyboard events
Re: NSWindow delegate handling keyboard events
- Subject: Re: NSWindow delegate handling keyboard events
- From: Matt Neuburg <email@hidden>
- Date: Sun, 20 Feb 2005 07:59:19 -0800
On or about 2/20/05 2:41 AM, thus spake "John C. Randolph" <email@hidden>:
>
> 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"
>> <email@hidden>:
>>
>>>
>>> On Feb 19, 2005, at 9:46 AM, Matt Neuburg wrote:
>>>
>>>> On Fri, 18 Feb 2005 23:18:00 -0500, "Andrew O'Laughlin"
>>>> <email@hidden>
>>>> 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 = email@hidden, 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/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden