Re: cancelOperation: does not work for trapping the escape key
Re: cancelOperation: does not work for trapping the escape key
- Subject: Re: cancelOperation: does not work for trapping the escape key
- From: Aki Inoue <email@hidden>
- Date: Tue, 18 Dec 2007 10:08:28 -0800
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
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the
list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Hank Heijink
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Hank Heijink
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden