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: Wed, 19 Dec 2007 22:40:33 -0800
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/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
_______________________________________________
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