Thanks! I will try it out.

Dimcho

-----Original Message-----
From: cocoa-dev-bounces+dbalev=adobe....@lists.apple.com 
[mailto:cocoa-dev-bounces+dbalev=adobe....@lists.apple.com] On Behalf Of Kirk 
Swenson
Sent: Friday, August 07, 2009 6:30 PM
To: cocoa-dev@lists.apple.com
Subject: Re: Cmd+key shortcuts not being sent to NSWindow on Tiger


On Aug 7, 2009, at 5:55 PM, Dimcho Balev <dba...@adobe.com> 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 (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/dbalev%40adobe.com

This email sent to dba...@adobe.com
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to