Hello,
Some key events are not being processed exactly as they should be.
We have been experiencing a problem in this scenario: We have a window with a table view,
a "delete" button, and a text field. The delete button deletes the selected
item in the table view, and has its keyEquivalent set to the delete key. So pressing
delete with something selected in the table view will delete it.
The problem is this: When we are editing a value in the text field, pressing
delete will still delete the selected item in the table view, rather than
deleting a character in the field. We don't have this problem on OS X.
After considerable time looking at the code and reading all of the relevant
parts of the Cocoa documentation, I think I've figured out what the difference
is and (more or less) how to fix it.
The Cocoa documentation talks about dispatching "events it recognizes as potential
key equivalents (based on the presence of modifier flags)" as key equivalents.
GNUstep has been sending ALL key events in this way, which caused the problem, since the
delete button would handle the event in its performKeyEquivalent: method and it would
never be sent to the text field.
So I've changed NSApplication's sendEvent: method to only call
performKeyEquivalent: when the event has modifier keys (other than the shift
key, which I think is not considered a modifier in this context).
With this change in place, the delete key event goes to the text field as it
should, but now the opposite problem exists, namely that the delete button
NEVER gets the event, even when the field is not being edited.
To handle this part of the problem, I modified NSWindow's keyDown: method to
send performKeyEquivalent: to itself. In this way, performKeyEquivalent: will
be sent to every view in the window for ALL keyDown events (that aren't
otherwise handled), those with modifiers first, from NSApplication, and those
without modifiers later, from NSWindow's keyDown after the event has been up
the responder chain.
I believe this is approximately how Cocoa handles it, based on backtraces I
captured (see below) although the documentation doesn't seem to be explicit
about this point.
My code in NSApplication looks like this:
NSApplication.m:2059
unsigned int modifiers = [theEvent modifierFlags];
BOOL usesModifiers = ((modifiers& ~NSShiftKeyMask) != 0);
BOOL handledKeyEquivalent = NO;
if (usesModifiers)
handledKeyEquivalent = [[self keyWindow] performKeyEquivalent:
theEvent];
if (handledKeyEquivalent == NO
&& [[self mainMenu] performKeyEquivalent: theEvent] == NO)
{
[[theEvent window] sendEvent: theEvent];
}
break;
And the code in NSWindow:
NSWindow.m: 3272
unsigned int modifiers = [theEvent modifierFlags];
BOOL usesModifiers = ((modifiers& ~NSShiftKeyMask) != 0);
if (!usesModifiers&& [self performKeyEquivalent:theEvent])
return;
Let me know if you'd like me to go ahead and check this in -- I hesitate to
just throw it in without any warning in this case because this is tinkering
with fairly basic behavior that may have subtle impacts. The code in NSWindow
in particular could be moved earlier in the keyDown: method (and I'm inclined
to think that it should be) to allow performKeyEquivalent: to take precedence
over the standard tab and shift-tab behavior, etc. -- what do you think?
Regards,
Doug
P.S. Here are some Cocoa backtraces from our application running on OS X that
give some clues about how Cocoa handles these events:
Delete key pressed on view with the scenario presented above, with an item
selected in the table view and NO active field editor. Note that
performKeyEquivalent: is invoked from NSWindow's keyDown: method:
#0 0x00099a0b in -[EGGSuite deleteScripts:] at EGGSuite.m:3287
#1 0x9360ac46 in -[NSApplication sendAction:to:from:]
#2 0x93a06a8c in -[NSMatrix sendAction:to:]
#3 0x939f8fe5 in -[NSMatrix sendAction]
#4 0x93a066a1 in -[NSMatrix performKeyEquivalent:]
#5 0x93704858 in -[NSControl _performKeyEquivalent:conditionally:]
#6 0x939fff1f in -[NSMatrix _performKeyEquivalent:conditionally:]
#7 0x93704724 in -[NSView performKeyEquivalent:]
#8 0x93704724 in -[NSView performKeyEquivalent:]
#9 0x93704724 in -[NSView performKeyEquivalent:]
#10 0x93704724 in -[NSView performKeyEquivalent:]
#11 0x93704496 in -[NSWindow performKeyEquivalent:]
#12 0x937a97a7 in -[NSWindow keyDown:]
#13 0x935f7ac1 in forwardMethod
#14 0x935f7ac1 in forwardMethod
#15 0x935f7ac1 in forwardMethod
#16 0x935f7ac1 in forwardMethod
#17 0x935f7ac1 in forwardMethod
#18 0x935f7ac1 in forwardMethod
#19 0x938f6565 in -[NSControl keyDown:]
#20 0x937ddf61 in -[NSTableView keyDown:]
#21 0x936e1d38 in -[NSWindow sendEvent:]
#22 0x935fa817 in -[NSApplication sendEvent:]
#23 0x9358e2a7 in -[NSApplication run]
#24 0x935862d9 in NSApplicationMain
#25 0x000029ac in main at main.m:13
Right arrow pressed in a slightly different scenario, with buttons that use
arrow keys as their key equivalents, with a table view item selected WITH OR
WITHOUT an active field editor (no difference, presumably because arrow keys
are treated as having a modifier key down, so performKeyEquivalent: is called
directly from [NSApplication sendEvent:]) (note: GNUstep and Cocoa behave the
same way in this scenario):
#0 0x000a4530 in -[EGGSuite moveScheduledScriptIn:] at EGGSuite.m:4967
#1 0x9360ac46 in -[NSApplication sendAction:to:from:]
#2 0x93a06a8c in -[NSMatrix sendAction:to:]
#3 0x939f8fe5 in -[NSMatrix sendAction]
#4 0x93a066a1 in -[NSMatrix performKeyEquivalent:]
#5 0x93704858 in -[NSControl _performKeyEquivalent:conditionally:]
#6 0x939fff1f in -[NSMatrix _performKeyEquivalent:conditionally:]
#7 0x93704724 in -[NSView performKeyEquivalent:]
#8 0x93704724 in -[NSView performKeyEquivalent:]
#9 0x93704724 in -[NSView performKeyEquivalent:]
#10 0x93704724 in -[NSView performKeyEquivalent:]
#11 0x93704496 in -[NSWindow performKeyEquivalent:]
#12 0x937041e1 in -[NSApplication _handleKeyEquivalent:]
#13 0x935fa1f2 in -[NSApplication sendEvent:]
#14 0x9358e2a7 in -[NSApplication run]
#15 0x935862d9 in NSApplicationMain
#16 0x000029ac in main at main.m:13