Keydown isn't firing.

[Dreamspinner]

OS X 10.8.2, XCode 4.5.2.

I have a textbox that I need to limit input to numeric, 3 digits (3 must be 003) between 0 and 360 inclusive. I also need to trap the Enter key.

My thought was to do the validation in a keyDown method. After a lot of searching and reading, it seems I need to have

- (BOOL)acceptsFirstResponder
{
  NSLog(@"Accepting...");
  return YES;
}

- (BOOL)becomeFirstResponder
{
  NSLog(@"becoming...");	
  return YES;
}
- (void)KeyDown:(NSEvent *)event
{
  NSLog(@"a key wuz prest");
  NSString *characters = [event charactersIgnoringModifiers];
  if([characters isEqualToString:@"v"])
  {
  }
}

This code is in my app delegate, as is all the other code that interacts with the UI.
None of those three methods fire. I think something's not wired correctly, but no idea what.

I'd also welcome any comments if catching the keys in keyDown isn't the best way to go.

[Sydde]

Your app delegate is near the bottom of the responder chain, so it is just not getting the keydown event: the field is simply swallowing it. You could use a custom text field subclass that overrides -keyDown: or you could subclass NSNumberFormatter and attach that to the field. Otherwise, I think you can attach a delegate to the field itself or get notifications from it.

[Dreamspinner]

I see the app delegate at the bottom of the chain. What I don't get is how buttons on the same view as my text box can respond and the text box doesn't.

Even if I call the acceptsFirstResponder and becomeFirstResponder, they have no effect I can see. Isn't there a way to move the app delegate up the chain?

[rant]I can't believe that this is such an uncommon a task and so esoteric.[/rant]

Of your suggestions I think a custom field/override -keydown appeals the most, second would be attaching a delegate.

Any tips there?

[mfram]

Doesn't your method have the wrong name? You have "KeyDown". It should be "keyDown". But either way, if you are trying to limit the keystrokes that get accepted by the control, I'd bet you are going to have to make a custom control. I'm not sure how the delegate protocol works, but it would have to be earlier in the responder chain than the control or the control will consume the event before you get a change to filter it out.

[gnasher729]

Originally Posted by Dreamspinner

Of your suggestions I think a custom field/override -keydown appeals the most, second would be attaching a delegate.

Any tips there?

Well spotted by mfram that you didn't actually have a keyDown method at all, but a completely unrelated method named KeyDown which the OS is never going to call.

Now since your text field is only supposed to accept numbers, what should happen if I paste in some text? Overriding keyDown won't help there at all (and you have to implement cut/copy/paste and so on). It isn't actually of any interest what keys the user is pressing. What interests you is what text is in the field. So find a delegate method that is called when the user changes the text.

[Dreamspinner]

Good eye on the name. Changing it to keyDown didn't help. So it's getting eaten somewhere somehow. I just can't dope out how/where.

----------

Originally Posted by gnasher729

Now since your text field is only supposed to accept numbers, what should happen if I paste in some text? Overriding keyDown won't help there at all (and you have to implement cut/copy/paste and so on). It isn't actually of any interest what keys the user is pressing. What interests you is what text is in the field. So find a delegate method that is called when the user changes the text.

Yes you're right about catching a keyDown being the wrong strategy. Off to look for text changing. I'd still like to know how to do the keyDown, but it can wait.