Prevent 'not allowed' beep after keystroke in NSView

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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
    }
}

Answer 4

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.

Answer 5

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)!)
  }
}