RE: Cmd+key shortcuts not being sent to NSWindow on Tiger
RE: Cmd+key shortcuts not being sent to NSWindow on Tiger
- Subject: RE: Cmd+key shortcuts not being sent to NSWindow on Tiger
- From: Dimcho Balev <email@hidden>
- Date: Mon, 10 Aug 2009 11:19:38 -0700
- Acceptlanguage: en-US
- Thread-topic: Cmd+key shortcuts not being sent to NSWindow on Tiger
Thanks! I will try it out.
Dimcho
-----Original Message-----
From: cocoa-dev-bounces+dbalev=email@hidden [mailto:cocoa-dev-bounces+dbalev=email@hidden] On Behalf Of Kirk Swenson
Sent: Friday, August 07, 2009 6:30 PM
To: email@hidden
Subject: Re: Cmd+key shortcuts not being sent to NSWindow on Tiger
On Aug 7, 2009, at 5:55 PM, Dimcho Balev <email@hidden> wrote:
> I have a trouble with a piece of code which behaves differently on
> Tiger (Mactel) in comparison to Leopard.
>
> It is pretty simple case: our cocoa app is interested in cmd+key
> shortcuts and we have overriden the keyDown and keyUp methods in our
> NSWindow inherited class. On Leopard we receive all of the key events
> without a problem but on Tiger the standard cmd+key events (cmd+c, cmd
> +v, cmd+x, cmd+a) are filtered out. I tried out few other approaches -
> for instance using flagsChanged to detect the cmd key status but I
> never receive an event for the 2nd key (m,c,v,x, or a) of the
> shortcut.
>
> I am wondering if this is known issue with Tiger and if there is any
> workaround.
We encountered the same problem. My solution was to implement a
derived class of NSTextView which overrides the performKeyEquivalent:
method as follows:
- (BOOL) performKeyEquivalent: (NSEvent*) anEvent
/*
On Leopard, these command-key equivalents are intercepted before we
get here,
with the associated behaviors provided automatically. On Tiger, the
prior
intercepts don't occur, and so we implement them here. This
shouldn't affect
the behavior on Leopard, since execution never reaches here on
Leopard.
*/
{
BOOL handled = NO;
if( ([anEvent modifierFlags] & NSDeviceIndependentModifierFlagsMask)
== NSCommandKeyMask) {
NSString* keyChars = [anEvent charactersIgnoringModifiers];
BOOL hasSelection = [self selectedRange].length > 0;
handled = YES;
if( [keyChars isEqual: @"a"])
[self selectAll: self];
else if( hasSelection && [keyChars isEqual: @"x"])
[self cut: self];
else if( hasSelection && [keyChars isEqual: @"c"])
[self copy: self];
else if( [keyChars isEqual: @"v"])
[self paste: self];
else
handled = NO;
}
return handled || [super performKeyEquivalent: anEvent];
}
and then in the controller/delegate's
windowWillReturnFieldEditor:toObject: method, do something like the
following:
- (id) windowWillReturnFieldEditor: (NSWindow*) aWindow toObject: (id)
anObject
/*
Returns the NSTextView to use as the field editor for the specified
object.
We override to return our MyTextView when appropriate.
*/
{
// myTextFieldEditor is a member variable, so there will only be one
of them.
if( myTextFieldEditor == nil) {
myTextFieldEditor = [[MyTextView alloc] init];
// Apple's docs fail to mention the requirement to call this method,
// but it apparently isn't called by the client. See the discussion at
// http://www.cocoadev.com/index.pl?CreatingCustomFieldEditor for
instance.
// Note, however, that the sample code given there calls setDelegate
in
// addition to setFieldEditor at this point. Doing so is a bad idea,
as it
// interferes with the framework's management of the delegate
relationship and
// results in improper tabbing behavior in dialogs with multiple
edit fields.
[myTextFieldEditor setFieldEditor: YES];
}
return myTextFieldEditor;
}
There may be a better solution out there, but this seems to work.
Kirk Swenson
Senior Software Engineer
KCP Technologies
_______________________________________________
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