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/
previous month february 2005 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28            
Go to today