initialFirstResponder weirdness
initialFirstResponder weirdness
- Subject: initialFirstResponder weirdness
- From: email@hidden
- Date: Fri, 5 Jul 2002 11:38:21 -0400
[NOTE: I posted this message without being a subscriber on Tuesday, but
the message didn't make the forum. As I wanted to get this solved this
weekend, I'm reposting, and I apologize if everyone receives this
message more than once!]
Hello All:
I've been toying around with Cocoa, and I have encountered a bug
that's vexing me.
Although I can find nothing in the documentation to suggest otherwise, I
have decided against all other practices I have seen to set an
'initialFirstResponder' outlet of a window in my NIB file to be an
instantiation of a class that doesn't inherit from NSView, just
NSResponder. Overloading the responder methods in my class:
- (BOOL) acceptsFirstResponder
{
NSLog(@"accepting");
return YES;
}
- (BOOL) becomeFirstResponder
{
NSLog(@"becoming");
return YES;
}
- (BOOL) resignFirstResponder
{
NSLog(@"resign");
return NO;
}
- (void)keyDown:(NSEvent*)event
{
unichar c;
NSLog(@"keyDown");
c = [[event characters] characterAtIndex:0];
}
And I see the following in the log from running my application:
------------
2002-07-02 22:22:35.152 Calculator[1128] accepting
Calculator.app has exited with status 0.
-----------
It never seems to 'become' the first responder, nor does my class accept
keyboard inputs (it just beeps). Looking at the Cocoa documentation for
NSWindow, I can't see anything that prevents window responders from
being 'just' NSResponders, and not NSViews.
Does anyone have any information about what's going on, and where this
is documented?!?
Thanks in advance.
-- Jeremy Faller
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.