Reputation: 9168
In my Mac app, I override and accept certain keystrokes via the keyUp
function in an NSView, which isn't meant to accept keystrokes.
When a key is pressed, the keyUp
function is called, and I do process the keystroke, without even calling super keyUp:
, and everything works, except that it also makes that default 'doonk' sound that happens when you press a key somewhere you shouldn't.
Is there any way to indicate that the keystroke was handled and accepted, and that I don't need a beep to tell the user it wasn't?
Upvotes: 15
Views: 3330
Reputation: 1
Every answer on this page is not quite right. The following is best practice, in my experience. If the key press is not valid the alert will sound; but if it is valid, it will not…
class YourNSViewSubclass: NSView {
// Make sure your view will accept responder chain events
override var acceptsFirstResponder: Bool { true }
override func becomeFirstResponder() -> Bool {
true
}
override func resignFirstResponder() -> Bool {
true
}
override func keyDown(with event: NSEvent) {
if !validateKeyPress(event: event) {
// If we get here, we need to send the key press up the responder chain
// So other views can have an opportunity to deal with the event
super.keyDown(with: event)
}
}
override func keyUp(with event: NSEvent) {
guard validateKeyPress(event: event) else {
super.keyUp(with: event)
return
}
// Do something as a result of the key press
}
// Check key press is valid. This example checks for the Delete key
private func validateKeyPress(event: NSEvent) -> Bool {
event.charactersIgnoringModifiers == String(UnicodeScalar(NSEvent.SpecialKey.delete.rawValue)!)
}
}
Upvotes: 0
Reputation: 9131
In my case performKeyEquivalent
did not capture the Enter key. The beep was triggered in the keyDown
event. This Swift code prevents beeping when handling the Enter key:
override func keyDown(with event: NSEvent) {
if event.keyCode != 36 {
super.keyDown(with: event)
}
}
override func keyUp(with event: NSEvent) {
if event.keyCode == 36 {
// Do your thing
}
}
Upvotes: 1
Reputation: 4280
The accepted answer might do the trick but I would like to suggest a more correct way to solve the problem :)
Using keyUp:
and keyDown:
is totally fine, but most importantly, your view must also follow the AppKit responder pattern (You can learn more about NSResponder
on the official documentation).
In your case, the view would need to signal itself as a valid first responder in the event chain. Assuming you have an NSView
subclass, you will need to implement the following method:
@implementation MyNSView
//...
- (BOOL)acceptsFirstResponder {
return YES;
}
@end
Upvotes: 2
Reputation: 17481
Instead of using keyUp:
, you may want to use the moveUp:
action, as it takes all of the hassle of determining which key to handle out of the mix. There are also similarly named routines for down and a variety for handling movement with selections, etc.
For further documentation on this, please see the Cocoa Event-Handling Guide, and in particular "Handling Keyboard Actions and Inserting Text", where it discusses the use of these commands in "Applications other that those that deal with text".
In particular, the other benefit to using these actions is that it avoids any problems with either key interpretation or special keyboards and keyboard layouts.
Upvotes: 1
Reputation: 89509
I think (but am not 100% certain, it's been a bit of time since I did this) you also need to override the NSView
and/or NSResponder
performKeyEquivalent:
method. There, you'll return a YES
to indicate to the caller that you did indeed handle the event.
And that will keep the "dooonk" sound from happening.
Upvotes: 17