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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
