cancelOperation: does not work for trapping the escape key

  • Hi All.

    I would like to trap the escape key for my window. I dug through the
    mail archives and found references to cancelOpeation:. This is
    exactly what I want. So I implemented cancelOperation: in my
    windowController, and get nothing. I just get the alert sound when I
    hit escape. Just to be sure, I also implemented keyDown: in my
    windowController, and those are getting through all right.

    Has anyone out there bumped into this? It is so frustrating when
    simple things won't work!

    Thanks!

    -Kenny
  • Are you calling interpretKeyEvents: in your keyDown: method? If not,
    there's your problem. See 'Overriding the keyDown: Method' in the
    Cocoa Event-Handling Guide.

    http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/Int
    roduction/


    Good luck,
    Hank

    On Dec 18, 2007, at 10:28 AM, Kenny Leung wrote:

    > Hi All.
    >
    > I would like to trap the escape key for my window. I dug through the
    > mail archives and found references to cancelOpeation:. This is
    > exactly what I want. So I implemented cancelOperation: in my
    > windowController, and get nothing. I just get the alert sound when I
    > hit escape. Just to be sure, I also implemented keyDown: in my
    > windowController, and those are getting through all right.
    >
    > Has anyone out there bumped into this? It is so frustrating when
    > simple things won't work!
    >
    > Thanks!
    >
    > -Kenny
    >

    Hank Heijink
    <hank.list...>
  • Hi Hank.

    The problem is that keyDown: is never called when you hit the escape
    key. If it was, I would just handle it there.

    From the documentation, it sounds like keyDown: is not part of the
    sequence:

    This method is bound to the Escape and Command-. (period) keys. The
    key window first searches the view hierarchy for a view whose key
    equivalent is Escape or Command-., whichever was entered. If none of
    these views handles the key equivalent, the window sends a default
    action message of cancelOperation: to the first responder and from
    there the message travels up the responder chain.

    If no responder in the responder chain implements cancelOperation:,
    the key window searches the view hierarchy for a view whose key
    equivalent is Escape (note that this may be redundant if the original
    key equivalent was Escape). If no such responder is found, then a
    cancel: action message is sent to the first responder in the
    responder chain that implements it.

    NSResponder declares but does not implement this method.

    -Kenny

    On Dec 18, 2007, at 7:51 AM, Hank Heijink wrote:

    > Are you calling interpretKeyEvents: in your keyDown: method? If
    > not, there's your problem. See 'Overriding the keyDown: Method' in
    > the Cocoa Event-Handling Guide.
    >
    > http://developer.apple.com/documentation/Cocoa/Conceptual/
    > EventOverview/Introduction/
    >
    > Good luck,
    > Hank
    >
    > On Dec 18, 2007, at 10:28 AM, Kenny Leung wrote:
    >
    >> Hi All.
    >>
    >> I would like to trap the escape key for my window. I dug through
    >> the mail archives and found references to cancelOpeation:. This is
    >> exactly what I want. So I implemented cancelOperation: in my
    >> windowController, and get nothing. I just get the alert sound when
    >> I hit escape. Just to be sure, I also implemented keyDown: in my
    >> windowController, and those are getting through all right.
    >>
    >> Has anyone out there bumped into this? It is so frustrating when
    >> simple things won't work!
    >>
    >> Thanks!
    >>
    >> -Kenny
    >>
    >
    > Hank Heijink
    > <hank.list...>
    >
    >
    >
  • Does your class return YES in acceptsFirstResponder? Remember that
    NSResponder (and any subclass that doesn't override this method)
    returns NO by default - that may be why your keyDown method isn't
    being called. Are other keys getting through? Escape should normally
    get to the keyDown method. From the documentation I referenced you to:

    Another implication of input-manager behavior is that if the key-
    bindings dictionary matches a physical keystroke with a keyboard
    action, the responder object simply needs to override the associated
    action method to handle that keystroke. For example, to handle the
    default binding of the Escape key, the responder would override the
    cancelOperation: method of NSResponder.

    Good luck,
    Hank

    On Dec 18, 2007, at 11:11 AM, Kenny Leung wrote:

    > Hi Hank.
    >
    > The problem is that keyDown: is never called when you hit the escape
    > key. If it was, I would just handle it there.
    >
    > From the documentation, it sounds like keyDown: is not part of the
    > sequence:
    >
    > This method is bound to the Escape and Command-. (period) keys. The
    > key window first searches the view hierarchy for a view whose key
    > equivalent is Escape or Command-., whichever was entered. If none of
    > these views handles the key equivalent, the window sends a default
    > action message of cancelOperation: to the first responder and from
    > there the message travels up the responder chain.
    >
    > If no responder in the responder chain implements cancelOperation:,
    > the key window searches the view hierarchy for a view whose key
    > equivalent is Escape (note that this may be redundant if the
    > original key equivalent was Escape). If no such responder is found,
    > then a cancel: action message is sent to the first responder in the
    > responder chain that implements it.
    >
    > NSResponder declares but does not implement this method.
    >
    > -Kenny
    >
    >
    >
    > On Dec 18, 2007, at 7:51 AM, Hank Heijink wrote:
    >
    >> Are you calling interpretKeyEvents: in your keyDown: method? If
    >> not, there's your problem. See 'Overriding the keyDown: Method' in
    >> the Cocoa Event-Handling Guide.
    >>
    >> http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/Int
    roduction/

    >>
    >> Good luck,
    >> Hank
    >>
    >> On Dec 18, 2007, at 10:28 AM, Kenny Leung wrote:
    >>
    >>> Hi All.
    >>>
    >>> I would like to trap the escape key for my window. I dug through
    >>> the mail archives and found references to cancelOpeation:. This is
    >>> exactly what I want. So I implemented cancelOperation: in my
    >>> windowController, and get nothing. I just get the alert sound when
    >>> I hit escape. Just to be sure, I also implemented keyDown: in my
    >>> windowController, and those are getting through all right.
    >>>
    >>> Has anyone out there bumped into this? It is so frustrating when
    >>> simple things won't work!
    >>>
    >>> Thanks!
    >>>
    >>> -Kenny
    >>>
    >>
    >> Hank Heijink
    >> <hank.list...>
    >>
    >>
    >>

    >

    Hank Heijink
    <hank.list...>
  • Sorry, I was not clear. My class is a window controller, which means
    that it is in the responder chain after the window itself. It is
    successfully getting keyDown: events for other keys, but nothing gets
    called for the escape key. Just in case, I overrode
    acceptsFirstResponder to return YES, but no dice.

    You can see a small example at http://www.hexdreams.com/temp/
    CancelOperationTest.zip that illustrates my point.

    -Kenny

    On Dec 18, 2007, at 8:43 AM, Hank Heijink wrote:

    > Does your class return YES in acceptsFirstResponder? Remember that
    > NSResponder (and any subclass that doesn't override this method)
    > returns NO by default - that may be why your keyDown method isn't
    > being called. Are other keys getting through? Escape should
    > normally get to the keyDown method. From the documentation I
    > referenced you to:
    >
    > Another implication of input-manager behavior is that if the key-
    > bindings dictionary matches a physical keystroke with a keyboard
    > action, the responder object simply needs to override the
    > associated action method to handle that keystroke. For example, to
    > handle the default binding of the Escape key, the responder would
    > override the cancelOperation: method of NSResponder.
    >
    > Good luck,
    > Hank
    >
    > On Dec 18, 2007, at 11:11 AM, Kenny Leung wrote:
    >
    >> Hi Hank.
    >>
    >> The problem is that keyDown: is never called when you hit the
    >> escape key. If it was, I would just handle it there.
    >>
    >> From the documentation, it sounds like keyDown: is not part of the
    >> sequence:
    >>
    >> This method is bound to the Escape and Command-. (period) keys.
    >> The key window first searches the view hierarchy for a view whose
    >> key equivalent is Escape or Command-., whichever was entered. If
    >> none of these views handles the key equivalent, the window sends a
    >> default action message of cancelOperation: to the first responder
    >> and from there the message travels up the responder chain.
    >>
    >> If no responder in the responder chain implements
    >> cancelOperation:, the key window searches the view hierarchy for a
    >> view whose key equivalent is Escape (note that this may be
    >> redundant if the original key equivalent was Escape). If no such
    >> responder is found, then a cancel: action message is sent to the
    >> first responder in the responder chain that implements it.
    >>
    >> NSResponder declares but does not implement this method.
    >>
    >> -Kenny
    >>
    >>
    >>
    >> On Dec 18, 2007, at 7:51 AM, Hank Heijink wrote:
    >>
    >>> Are you calling interpretKeyEvents: in your keyDown: method? If
    >>> not, there's your problem. See 'Overriding the keyDown: Method'
    >>> in the Cocoa Event-Handling Guide.
    >>>
    >>> http://developer.apple.com/documentation/Cocoa/Conceptual/
    >>> EventOverview/Introduction/
    >>>
    >>> Good luck,
    >>> Hank
    >>>
    >>> On Dec 18, 2007, at 10:28 AM, Kenny Leung wrote:
    >>>
    >>>> Hi All.
    >>>>
    >>>> I would like to trap the escape key for my window. I dug through
    >>>> the mail archives and found references to cancelOpeation:. This
    >>>> is exactly what I want. So I implemented cancelOperation: in my
    >>>> windowController, and get nothing. I just get the alert sound
    >>>> when I hit escape. Just to be sure, I also implemented keyDown:
    >>>> in my windowController, and those are getting through all right.
    >>>>
    >>>> Has anyone out there bumped into this? It is so frustrating when
    >>>> simple things won't work!
    >>>>
    >>>> Thanks!
    >>>>
    >>>> -Kenny
    >>>>
    >>>
    >>> Hank Heijink
    >>> <hank.list...>
    >>>
    >>>
    >>>

    >>
    >
    > Hank Heijink
    > <hank.list...>
    >
    >
    >
  • You can make an NSButton and set its key-equivalent to escape. If you
    don't want it to be visible you can hide it off the upper-left edge of
    the window or something like that (although it might still get tab
    focus, hmm).

    Kenny Leung wrote:
    > Hi All.
    >
    > I would like to trap the escape key for my window. I dug through the
    > mail archives and found references to cancelOpeation:. This is exactly
    > what I want. So I implemented cancelOperation: in my windowController,
    > and get nothing. I just get the alert sound when I hit escape. Just to
    > be sure, I also implemented keyDown: in my windowController, and those
    > are getting through all right.
    >
    > Has anyone out there bumped into this? It is so frustrating when
    > simple things won't work!
    >
    > Thanks!
    >
    > -Kenny
  • Le 18 déc. 07 à 18:41, Kenny Leung a écrit :

    > Sorry, I was not clear. My class is a window controller, which means
    > that it is in the responder chain after the window itself. It is
    > successfully getting keyDown: events for other keys, but nothing
    > gets called for the escape key. Just in case, I overrode
    > acceptsFirstResponder to return YES, but no dice.
    >
    > You can see a small example at http://www.hexdreams.com/temp/CancelOperationTest.zip
    > that illustrates my point.
    >
    > -Kenny

    I think the - (BOOL)performKeyEquivalent:(NSEvent *)theEvent method
    catch your escape event before it reach the keyDown: method.
    If performKeyEquivalent return YES, the keyDown: method will no be call.

    You can find a very good graph fo the event flow here:

    http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/Eve
    ntArchitecture/chapter_2_section_3.html#/

    /apple_ref/doc/uid/10000060i-CH3-SW10
  • Kenny,

    Since NSWindow implements -cancelOperation:, your window controller
    being a window delegate doesn't receive the message.

    What kind of operation are you trying to cancel ?

    If your windows is an NSPanel, -cancelOperation: is automatically
    handled (you can just handle the window close to cancel your tasks).

    Aki

    On 2007/12/18, at 9:41, Kenny Leung wrote:

    > Sorry, I was not clear. My class is a window controller, which means
    > that it is in the responder chain after the window itself. It is
    > successfully getting keyDown: events for other keys, but nothing
    > gets called for the escape key. Just in case, I overrode
    > acceptsFirstResponder to return YES, but no dice.
    >
    > You can see a small example at http://www.hexdreams.com/temp/CancelOperationTest.zip
    > that illustrates my point.
    >
    > -Kenny
    >
    >
    > On Dec 18, 2007, at 8:43 AM, Hank Heijink wrote:
    >
    >> Does your class return YES in acceptsFirstResponder? Remember that
    >> NSResponder (and any subclass that doesn't override this method)
    >> returns NO by default - that may be why your keyDown method isn't
    >> being called. Are other keys getting through? Escape should
    >> normally get to the keyDown method. From the documentation I
    >> referenced you to:
    >>
    >> Another implication of input-manager behavior is that if the key-
    >> bindings dictionary matches a physical keystroke with a keyboard
    >> action, the responder object simply needs to override the
    >> associated action method to handle that keystroke. For example, to
    >> handle the default binding of the Escape key, the responder would
    >> override the cancelOperation: method of NSResponder.
    >>
    >> Good luck,
    >> Hank
    >>
    >> On Dec 18, 2007, at 11:11 AM, Kenny Leung wrote:
    >>
    >>> Hi Hank.
    >>>
    >>> The problem is that keyDown: is never called when you hit the
    >>> escape key. If it was, I would just handle it there.
    >>>
    >>> From the documentation, it sounds like keyDown: is not part of the
    >>> sequence:
    >>>
    >>> This method is bound to the Escape and Command-. (period) keys.
    >>> The key window first searches the view hierarchy for a view whose
    >>> key equivalent is Escape or Command-., whichever was entered. If
    >>> none of these views handles the key equivalent, the window sends a
    >>> default action message of cancelOperation: to the first responder
    >>> and from there the message travels up the responder chain.
    >>>
    >>> If no responder in the responder chain implements
    >>> cancelOperation:, the key window searches the view hierarchy for a
    >>> view whose key equivalent is Escape (note that this may be
    >>> redundant if the original key equivalent was Escape). If no such
    >>> responder is found, then a cancel: action message is sent to the
    >>> first responder in the responder chain that implements it.
    >>>
    >>> NSResponder declares but does not implement this method.
    >>>
    >>> -Kenny
    >>>
    >>>
    >>>
    >>> On Dec 18, 2007, at 7:51 AM, Hank Heijink wrote:
    >>>
    >>>> Are you calling interpretKeyEvents: in your keyDown: method? If
    >>>> not, there's your problem. See 'Overriding the keyDown: Method'
    >>>> in the Cocoa Event-Handling Guide.
    >>>>
    >>>> http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/Int
    roduction/

    >>>>
    >>>> Good luck,
    >>>> Hank
    >>>>
    >>>> On Dec 18, 2007, at 10:28 AM, Kenny Leung wrote:
    >>>>
    >>>>> Hi All.
    >>>>>
    >>>>> I would like to trap the escape key for my window. I dug through
    >>>>> the mail archives and found references to cancelOpeation:. This
    >>>>> is exactly what I want. So I implemented cancelOperation: in my
    >>>>> windowController, and get nothing. I just get the alert sound
    >>>>> when I hit escape. Just to be sure, I also implemented keyDown:
    >>>>> in my windowController, and those are getting through all right.
    >>>>>
    >>>>> Has anyone out there bumped into this? It is so frustrating when
    >>>>> simple things won't work!
    >>>>>
    >>>>> Thanks!
    >>>>>
    >>>>> -Kenny
    >>>>>
    >>>>
    >>>> Hank Heijink
    >>>> <hank.list...>
    >>>>
    >>>>
    >>>>

    >>>
    >>
    >> Hank Heijink
    >> <hank.list...>
    >>
    >>
    >>

  • I just tried overriding performKeyEquivalent: in my window
    controller, and no dice. According to the documentation for
    cancelOperation: it should not affect anything:

    > This method is bound to the Escape and Command-. (period) keys. The
    > key window first searches the view hierarchy for a view whose key
    > equivalent is Escape or Command-., whichever was entered.

    There are no views in my window except for the content view, so
    nothing will catch it via the key equivalent.

    > If none of these views handles the key equivalent, the window sends
    > a default action message of cancelOperation: to the first responder

    The first responder is the window in this case (I think).

    > and from there the message travels up the responder chain.

    up to the window controller.

    The fact that keyDown: gets called for other keys makes me think that
    the first responder is the window, and that the responder chain is
    what I think it is...

    -Kenny

    On Dec 18, 2007, at 9:54 AM, Jean-Daniel Dupas wrote:

    >
    > Le 18 déc. 07 à 18:41, Kenny Leung a écrit :
    >
    >> Sorry, I was not clear. My class is a window controller, which
    >> means that it is in the responder chain after the window itself.
    >> It is successfully getting keyDown: events for other keys, but
    >> nothing gets called for the escape key. Just in case, I overrode
    >> acceptsFirstResponder to return YES, but no dice.
    >>
    >> You can see a small example at http://www.hexdreams.com/temp/
    >> CancelOperationTest.zip that illustrates my point.
    >>
    >> -Kenny
    >
    >
    > I think the - (BOOL)performKeyEquivalent:(NSEvent *)theEvent method
    > catch your escape event before it reach the keyDown: method.
    > If performKeyEquivalent return YES, the keyDown: method will no be
    > call.
    >
    > You can find a very good graph fo the event flow here:
    >
    > http://developer.apple.com/documentation/Cocoa/Conceptual/
    > EventOverview/EventArchitecture/chapter_2_section_3.html#//
    > apple_ref/doc/uid/10000060i-CH3-SW10
    >
    >
  • Hi Aki.

    I would like my window controller to handle escape to cancel a series
    of operations. I am working on an iPhoto-like application (not happy
    with either iPhoto or Aperture), so you can imagine double-clicking
    on a thumbnail and having that picture fill the window. Double-
    clicking again would make it go fullscreen. Hitting escape gets you
    back to window mode, and hitting escape again gets you back to
    thumbnails.

    I guess the key here is that NSWindow also implements
    cancelOperation: but this is not documented. It seemed a natural
    thing for my window controller to grab key events to control things
    like this. Architecture wise, is this the right way to go?

    Thanks!

    -Kenny

    On Dec 18, 2007, at 10:08 AM, Aki Inoue wrote:

    > Kenny,
    >
    > Since NSWindow implements -cancelOperation:, your window controller
    > being a window delegate doesn't receive the message.
    >
    > What kind of operation are you trying to cancel ?
    >
    > If your windows is an NSPanel, -cancelOperation: is automatically
    > handled (you can just handle the window close to cancel your tasks).
    >
    > Aki
    >
    > On 2007/12/18, at 9:41, Kenny Leung wrote:
    >
    >> Sorry, I was not clear. My class is a window controller, which
    >> means that it is in the responder chain after the window itself.
    >> It is successfully getting keyDown: events for other keys, but
    >> nothing gets called for the escape key. Just in case, I overrode
    >> acceptsFirstResponder to return YES, but no dice.
    >>
    >> You can see a small example at http://www.hexdreams.com/temp/
    >> CancelOperationTest.zip that illustrates my point.
    >>
    >> -Kenny
    >>
    >>
    >> On Dec 18, 2007, at 8:43 AM, Hank Heijink wrote:
    >>
    >>> Does your class return YES in acceptsFirstResponder? Remember
    >>> that NSResponder (and any subclass that doesn't override this
    >>> method) returns NO by default - that may be why your keyDown
    >>> method isn't being called. Are other keys getting through? Escape
    >>> should normally get to the keyDown method. From the documentation
    >>> I referenced you to:
    >>>
    >>> Another implication of input-manager behavior is that if the key-
    >>> bindings dictionary matches a physical keystroke with a keyboard
    >>> action, the responder object simply needs to override the
    >>> associated action method to handle that keystroke. For example,
    >>> to handle the default binding of the Escape key, the responder
    >>> would override the cancelOperation: method of NSResponder.
    >>>
    >>> Good luck,
    >>> Hank
    >>>
    >>> On Dec 18, 2007, at 11:11 AM, Kenny Leung wrote:
    >>>
    >>>> Hi Hank.
    >>>>
    >>>> The problem is that keyDown: is never called when you hit the
    >>>> escape key. If it was, I would just handle it there.
    >>>>
    >>>> From the documentation, it sounds like keyDown: is not part of
    >>>> the sequence:
    >>>>
    >>>> This method is bound to the Escape and Command-. (period) keys.
    >>>> The key window first searches the view hierarchy for a view
    >>>> whose key equivalent is Escape or Command-., whichever was
    >>>> entered. If none of these views handles the key equivalent, the
    >>>> window sends a default action message of cancelOperation: to the
    >>>> first responder and from there the message travels up the
    >>>> responder chain.
    >>>>
    >>>> If no responder in the responder chain implements
    >>>> cancelOperation:, the key window searches the view hierarchy for
    >>>> a view whose key equivalent is Escape (note that this may be
    >>>> redundant if the original key equivalent was Escape). If no such
    >>>> responder is found, then a cancel: action message is sent to the
    >>>> first responder in the responder chain that implements it.
    >>>>
    >>>> NSResponder declares but does not implement this method.
    >>>>
    >>>> -Kenny
    >>>>
    >>>>
    >>>>
    >>>> On Dec 18, 2007, at 7:51 AM, Hank Heijink wrote:
    >>>>
    >>>>> Are you calling interpretKeyEvents: in your keyDown: method? If
    >>>>> not, there's your problem. See 'Overriding the keyDown: Method'
    >>>>> in the Cocoa Event-Handling Guide.
    >>>>>
    >>>>> http://developer.apple.com/documentation/Cocoa/Conceptual/
    >>>>> EventOverview/Introduction/
    >>>>>
    >>>>> Good luck,
    >>>>> Hank
    >>>>>
    >>>>> On Dec 18, 2007, at 10:28 AM, Kenny Leung wrote:
    >>>>>
    >>>>>> Hi All.
    >>>>>>
    >>>>>> I would like to trap the escape key for my window. I dug
    >>>>>> through the mail archives and found references to
    >>>>>> cancelOpeation:. This is exactly what I want. So I implemented
    >>>>>> cancelOperation: in my windowController, and get nothing. I
    >>>>>> just get the alert sound when I hit escape. Just to be sure, I
    >>>>>> also implemented keyDown: in my windowController, and those
    >>>>>> are getting through all right.
    >>>>>>
    >>>>>> Has anyone out there bumped into this? It is so frustrating
    >>>>>> when simple things won't work!
    >>>>>>
    >>>>>> Thanks!
    >>>>>>
    >>>>>> -Kenny
    >>>>>>
    >>>>>
    >>>>> Hank Heijink
    >>>>> <hank.list...>
    >>>>>
    >>>>>
    >>>>>

    >>>>
    >>>
    >>> Hank Heijink
    >>> <hank.list...>
    >>>
    >>>
    >>>

    >
  • Kenny,

    The current implementation is optimized for closing panels (i.e.
    alerts or sheets) or cancelling operations performed by the first
    responder.

    I admit it is not easy for cancelling at window/document controller
    level just as you're trying to do here.

    Probably the most straightforward approaches is to have a control with
    ESC as key equivalent (as suggested by others) or have subclass of
    NSWindow and override cancelOperation:.

    Aki

    On 2007/12/18, at 10:34, Kenny Leung wrote:

    > Hi Aki.
    >
    > I would like my window controller to handle escape to cancel a
    > series of operations. I am working on an iPhoto-like application
    > (not happy with either iPhoto or Aperture), so you can imagine
    > double-clicking on a thumbnail and having that picture fill the
    > window. Double-clicking again would make it go fullscreen. Hitting
    > escape gets you back to window mode, and hitting escape again gets
    > you back to thumbnails.
    >
    > I guess the key here is that NSWindow also implements
    > cancelOperation: but this is not documented. It seemed a natural
    > thing for my window controller to grab key events to control things
    > like this. Architecture wise, is this the right way to go?
    >
    > Thanks!
    >
    > -Kenny
    >
    >
    > On Dec 18, 2007, at 10:08 AM, Aki Inoue wrote:
    >
    >> Kenny,
    >>
    >> Since NSWindow implements -cancelOperation:, your window controller
    >> being a window delegate doesn't receive the message.
    >>
    >> What kind of operation are you trying to cancel ?
    >>
    >> If your windows is an NSPanel, -cancelOperation: is automatically
    >> handled (you can just handle the window close to cancel your tasks).
    >>
    >> Aki
    >>
    >> On 2007/12/18, at 9:41, Kenny Leung wrote:
    >>
    >>> Sorry, I was not clear. My class is a window controller, which
    >>> means that it is in the responder chain after the window itself.
    >>> It is successfully getting keyDown: events for other keys, but
    >>> nothing gets called for the escape key. Just in case, I overrode
    >>> acceptsFirstResponder to return YES, but no dice.
    >>>
    >>> You can see a small example at http://www.hexdreams.com/temp/CancelOperationTest.zip
    >>> that illustrates my point.
    >>>
    >>> -Kenny
    >>>
    >>>
    >>> On Dec 18, 2007, at 8:43 AM, Hank Heijink wrote:
    >>>
    >>>> Does your class return YES in acceptsFirstResponder? Remember
    >>>> that NSResponder (and any subclass that doesn't override this
    >>>> method) returns NO by default - that may be why your keyDown
    >>>> method isn't being called. Are other keys getting through? Escape
    >>>> should normally get to the keyDown method. From the documentation
    >>>> I referenced you to:
    >>>>
    >>>> Another implication of input-manager behavior is that if the key-
    >>>> bindings dictionary matches a physical keystroke with a keyboard
    >>>> action, the responder object simply needs to override the
    >>>> associated action method to handle that keystroke. For example,
    >>>> to handle the default binding of the Escape key, the responder
    >>>> would override the cancelOperation: method of NSResponder.
    >>>>
    >>>> Good luck,
    >>>> Hank
    >>>>
    >>>> On Dec 18, 2007, at 11:11 AM, Kenny Leung wrote:
    >>>>
    >>>>> Hi Hank.
    >>>>>
    >>>>> The problem is that keyDown: is never called when you hit the
    >>>>> escape key. If it was, I would just handle it there.
    >>>>>
    >>>>> From the documentation, it sounds like keyDown: is not part of
    >>>>> the sequence:
    >>>>>
    >>>>> This method is bound to the Escape and Command-. (period) keys.
    >>>>> The key window first searches the view hierarchy for a view
    >>>>> whose key equivalent is Escape or Command-., whichever was
    >>>>> entered. If none of these views handles the key equivalent, the
    >>>>> window sends a default action message of cancelOperation: to the
    >>>>> first responder and from there the message travels up the
    >>>>> responder chain.
    >>>>>
    >>>>> If no responder in the responder chain implements
    >>>>> cancelOperation:, the key window searches the view hierarchy for
    >>>>> a view whose key equivalent is Escape (note that this may be
    >>>>> redundant if the original key equivalent was Escape). If no such
    >>>>> responder is found, then a cancel: action message is sent to the
    >>>>> first responder in the responder chain that implements it.
    >>>>>
    >>>>> NSResponder declares but does not implement this method.
    >>>>>
    >>>>> -Kenny
    >>>>>
    >>>>>
    >>>>>
    >>>>> On Dec 18, 2007, at 7:51 AM, Hank Heijink wrote:
    >>>>>
    >>>>>> Are you calling interpretKeyEvents: in your keyDown: method? If
    >>>>>> not, there's your problem. See 'Overriding the keyDown: Method'
    >>>>>> in the Cocoa Event-Handling Guide.
    >>>>>>
    >>>>>> http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/Int
    roduction/

    >>>>>>
    >>>>>> Good luck,
    >>>>>> Hank
    >>>>>>
    >>>>>> On Dec 18, 2007, at 10:28 AM, Kenny Leung wrote:
    >>>>>>
    >>>>>>> Hi All.
    >>>>>>>
    >>>>>>> I would like to trap the escape key for my window. I dug
    >>>>>>> through the mail archives and found references to
    >>>>>>> cancelOpeation:. This is exactly what I want. So I implemented
    >>>>>>> cancelOperation: in my windowController, and get nothing. I
    >>>>>>> just get the alert sound when I hit escape. Just to be sure, I
    >>>>>>> also implemented keyDown: in my windowController, and those
    >>>>>>> are getting through all right.
    >>>>>>>
    >>>>>>> Has anyone out there bumped into this? It is so frustrating
    >>>>>>> when simple things won't work!
    >>>>>>>
    >>>>>>> Thanks!
    >>>>>>>
    >>>>>>> -Kenny
    >>>>>>>
    >>>>>>
    >>>>>> Hank Heijink
    >>>>>> <hank.list...>
    >>>>>>
    >>>>>>
    >>>>>>

    >>>>>
    >>>>
    >>>> Hank Heijink
    >>>> <hank.list...>
    >>>>
    >>>>
    >>>>

    >>

previous month december 2007 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 29 30
31            
Go to today