RE: Minimal cocoa application
RE: Minimal cocoa application
- Subject: RE: Minimal cocoa application
- From: "Godwin, Mark R" <email@hidden>
- Date: Fri, 9 Mar 2007 17:23:03 -0000
- Thread-topic: Minimal cocoa application
I was under the impression that placing your executable in a bundle dir
structure with some suitable plist files sorts this out?
However, it seems you know much more about this than me...
Thanks,
Mark
________________________________
From: Dave Jewell [mailto:email@hidden]
Sent: 09 March 2007 17:13
To: email@hidden
Cc: Godwin, Mark R
Subject: Re: Minimal cocoa application
Hi Godwin - interesting thread. There are a couple of bugs in the
Tiny.m application (Chapter 4, "Building Cocoa Applications) which you
should be aware of.
Firstly, it's not necessary to assign to NSApp. This is automatically
done when you call [NSApplication sharedApplication] which also
initializes AppKit.
Perhaps more importantly, the authors call [NSApp terminate: self] which
means that control never returns to the main() function. You can
correct this by calling [NSApp stop: self] instead. This will terminate
the run loop, returning control from the call to [NSApp run] and
allowing the NSApplication instance to be released before deallocating
the auto-release pool. With the call to terminate, this stuff never
gets executed.
For your amusement, source to my own do-nothing nibless application is
provided below. You can build it by starting with a Foundation
command-line template, and then adding AppKit.framework before entering
the source below.
There is one outstanding issue: as the book authors point out, a nibless
application which programmatically creates an NSWindow doesn't get
properly brought to the front and made the key window when it starts
running. They suggest (see note on page 136) that this is because the
event loop isn't running at the time the window is created. However,
this hypothesis is incorrect: even with an ordinary "NIB'ed" app, the
run loop isn't active when the inital window gets loaded. You can
verify this for yourself by using performSelector:withObject:afterDelay:
to send a makeKeyAndOrderFront: message to the window after the run loop
starts. It will still be ignored.
The real problem is that the NIB-loading routines establish connections
between NSApp and the window. These connections don't get made for a
programmatically created application which means that the window never
gets made key, and doesn't even appear in the Dock. It's an interesting
conundrum which I'm trying to figure out... but don't hold your breath.
;-)
Dave
#import <Foundation/Foundation.h>
#import <Cocoa/Cocoa.h>
@interface NXNiblessWindow : NSWindow
{
}
@end
@implementation NXNiblessWindow
- (void) windowWillClose: (NSNotification *) notification
{
[NSApp stop: self];
}
@end
int main (int argc, const char * argv[])
{
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
// Need this to init AppKit and NSApp
[NSApplication sharedApplication];
// Create a window
NXNiblessWindow * myWindow = [[NXNiblessWindow alloc]
initWithContentRect: NSMakeRect (50, 50, 300, 300) styleMask: 15
backing: NSBackingStoreBuffered defer: NO];
[myWindow setTitle: @"Look Ma, No NIB!"];
[myWindow center];
[myWindow setDelegate: myWindow];
[myWindow makeKeyAndOrderFront: nil];
[NSApp run];
[NSApp release];
[pool release];
return 0;
}
From: "Godwin, Mark R" <email@hidden>
Subject: RE: Minimal cocoa application
To: "Robert Clair" <email@hidden>
That's exactly what I was looking for. Thankyou.
Don't despair. I have taken on board all comments about this being the
wrong way to do this kind of thing.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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