On Jun 24, 2008, at 7:43 AM, Johan Kool wrote:
You create your controller with this:
spriteController = [[SpriteController alloc]
initWithWindowNibName:@"YourNib"];
and to show the window you use:
[[spriteController window] makeKeyAndOrderFront:self];
or
[[spriteController spriteWindow] makeKeyAndOrderFront:self];
Care should be taken with the second form. -[NSWindowController
window] does some important stuff besides just returning the window --
it loads the nib if necessary! So, calling your own -spriteWindow
accessor will not be sufficient unless it in turn calls -window.
Also, consider using -[NSWindowController showWindow:] instead of
calling both -window and -makeKeyAndOrderFront:.
On Jun 24, 2008, at 7:49 AM, Chris wrote:
You should not be allocating either SpriteView or SpriteController
if they are referred to in the NIB. (which is the normal case).
Instead you go to the File's Owner object in interface builder, and
go to the Identity tab, and set the Class to be whatever class
contains your loadNib statement. ONLY load the NIB, don't attempt to
create windows, views or controllers. (Let's call this class that
loads the NIB as class "A".). Now you add some outlets to class "A"
called spriteView, spriteWIndow, spriteController or whatever else
you need. Then in interface builder you connect these outlets of
"File's Owner" to those objects. Now when you load the NIB, you'll
have pointers to all the objects you care about in the same object
that loaded the NIB.
This is potentially confusing advice, in my opinion. The OP was doing
a very typical thing, which is that he had a custom subclass of
NSWindowController "outside" of his nib, which would serve to load and
own the nib. Therefore, he _should_ be allocating it himself, and the
nib should not have an instance of his class. Instead the nib's
File's Owner should be configured to know that its class will be
SpriteController.
In other words, you're introducing an unnecessary class "A" to fulfill
the role that SpriteController is already filling.
On Jun 24, 2008, at 7:56 AM, Andy Lee wrote:
On Jun 24, 2008, at 8:17 AM, Joseph Ayers wrote:
SpriteController and SpriteView are defined and connected in the NIB
Your nib shouldn't contain a SpriteController instance. Instead, it
should set the class of File's Owner to SpriteController and make
the outlet connection from File's Owner to your SpriteView. Your
code below will then do the right thing -- it creates a
SpriteController instance and tells the nib file to use that as the
File's Owner when it is loaded.
When I open the NIB with
-(void)loadSpriteController{
if (spriteController == NULL) {
spriteController = [[SpriteController alloc] init];
if (![NSBundle loadNibNamed:@"spriteWindow"
owner:spriteController]) {
NSLog(@"Error loading SpriteController");}
else{
NSLog(@"SpriteController NIB Loaded"); }
}
}
Actually, you should use the code suggested by Johan Kool to allocate
and initialize your SpriteController and load the nib. In other
words, use NSWindowController's -initWithWindowNibName: method to
initialize the object, and _don't_ use NSBundle or NSNib to load the
nib. Let NSWindowController do that for you, which it will do
automatically when you (or somebody) call its -window getter method.
It's not called out very strongly in the documentation, but
NSWindowController has some smarts in it about nib loading and memory
management of the top-level objects. In particular, it avoids the
retain cycles which typically result when something in the nib binds
to or through File's Owner.
It's possible that -[SpriteController init] is built in terms of -
[NSWindowController initWithWindowNibName:], which is fine. My point
is that NSWindowController should be managing the nib and its loading.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
