• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Delete action from variety of key presses
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Delete action from variety of key presses


  • Subject: Re: Delete action from variety of key presses
  • From: Nathan Vander Wilt <email@hidden>
  • Date: Tue, 8 Jul 2008 11:39:27 -0700

On Jul 7, 2008, at 5:07 PM, Graham Cox wrote:
The view that is first responder needs to override -keyDown: and do this:

	[self interpretKeyEvents:[NSArray arrayWithObject:event]];

which hooks the event into the standard dispatcher for these methods.

(One thing that has long puzzled me about this though - why is the parameter an array of events when only one event is ever available?)


Okay, got this message late though it looks like another had responded to it already. Given that I need to override -keyDown: (or - performKeyEquivalent:) in applicable first responders anyway, and it doesn't really read well to have -forwardDelete:, backwardDelete:, etc. actions, I just did the following:

#pragma mark Keyboard events

- (BOOL)acceptsFirstResponder {
	return YES;
}

- (void)keyDown:(NSEvent*)keyEvent {
NSString* keyCharacters = [keyEvent charactersIgnoringModifiers];
if ([keyCharacters length] == 1) {
unichar keyPressed = [keyCharacters characterAtIndex:0];
if (keyPressed == NSDeleteCharacter || keyPressed == NSDeleteCharFunctionKey) {
[self doCommandBySelector:@selector(delete:)];
}
else [super keyDown:keyEvent];
}
else [super keyDown:keyEvent];
}


Provided the view(s) with this code is the first responder, it causes the action to fire when either delete key is pressed, with any modifiers. If I need more fine-grained behaviour (forceDelete: or something when Cmd is pressed), I'll just add it in that method.

I'm tempted to improve upon this by using the NSUserInterfaceValidations informal protocol (which my app delegate already conforms to for the sake of the Edit>Delete menu item) to check if the delete action is even performed. The way this code works, the delete key gets swallowed even when nothing is deleted. This silent dropping of the delete key is how many apps behave, but wouldn't it be better to pass the event up to super when the delete: action isn't really valid, so it can eventually result in a beep/bonk/ blip?

thanks,
-natevw
_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


References: 
 >Delete action from variety of key presses (From: Nathan Vander Wilt <email@hidden>)
 >Re: Delete action from variety of key presses (From: Ken Thomases <email@hidden>)
 >Re: Delete action from variety of key presses (From: Nathan Vander Wilt <email@hidden>)
 >Re: Delete action from variety of key presses (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Removing folder from /Applications
  • Next by Date: Re: problem with IKImageView and filters
  • Previous by thread: Re: Delete action from variety of key presses
  • Next by thread: Re: Delete action from variety of key presses
  • Index(es):
    • Date
    • Thread