views:

74

answers:

2

I'm not getting the -(void)keyDown callback on my inherited NSOpenGLView (note that mouseMoved does not work either though I do setAcceptsMouseMovedEvents:YES, but that is not an issue yet). It implements

- (BOOL)acceptsFirstResponder
{
    return YES;
}

but still no luck. My knowledgeable friend implied that it might have something to do with that the application is still a console application and not a bundled .app (I'm currently porting it). If so: is there some way to circumvent? Could the cause be something else? When I terminate my console application, I frequently see all my keypresses go to stdout so it does seem reasonable...

Edit:

@implementation UiMacApplication
- (void)run
{
}
- (void)terminate:(id)sender
{
    ...
}
- (void)startDummyThread:(id)sender
{
    printf("startDummyThread!\n");
}
@end

....

mApplication = (UiMacApplication*)[UiMacApplication sharedApplication];
[NSThread detachNewThreadSelector: @selector(startDummyThread:) toTarget: mApplication withObject: nil];
[[NSNotificationCenter defaultCenter] postNotificationName:NSApplicationWillFinishLaunchingNotification object: NSApp];
[[NSNotificationCenter defaultCenter] postNotificationName:NSApplicationDidFinishLaunchingNotification object: NSApp];

Main loop:

NSEvent* event = [mApplication  nextEventMatchingMask:  NSAnyEventMask
                                  untilDate:              nil
                                  inMode:                 NSDefaultRunLoopMode
                                  dequeue:                YES];

[mApplication sendEvent: event];
[mApplication updateWindows];
+1  A: 

Do you have an NSApplication instance, and are you sending it a -run message? That's rather important to be able to receive events.

NSResponder
I have an NSApplication as so `@implementation UiMacApplication- (void)run{}`, but unsure if this is enough? Should I nextEventMatchingMask with dequeue:YES?
Jonas Byström
Please post your code from `main.m`.
Rob Keniger
Is this "UiMacApplication" of yours subclassed from NSApplication? There's a lot setup work that happens in NSApplication that you might not be doing if you're rolling your own main() and Application class.
NSResponder
+1  A: 

You're simultaneously doing way more work than you need to and not doing anywhere near the amount of work that you need to.

NSApplication already implements its run method, the event loop, etc. I don't know why you're writing this subclass; it seems to do nothing that NSApplication doesn't already do. Your replacement for NSApplication's implementation is incomplete and insufficient, so it doesn't work.

My suggestion is to axe this UiMacApplication class and just use plain NSApplication. Don't roll your own event loop, and don't call run directly; call NSApplicationMain() instead. You probably don't need that thread, either, but if you do, write an application delegate and start the thread from there.

Generally, you almost never need to subclass a Cocoa class—certainly not for basic things like making the application run. There are exceptions, but they're either very rare or clearly labeled.

Peter Hosey
No, we subclass Cocoa classes all the time, it's just that to subclass NSApplication in particular is unusual, and rarely if ever necessary. In all the time I've been writing NeXTSTEP and Mac apps, I've only done so a couple of times, and it was never strictly necessary.
NSResponder
NSResponder: Yes, we subclass Cocoa classes all the time—those that the documentation recommends subclassing in certain circumstances. I acknowledged them as “clearly labeled” in the answer.
Peter Hosey