Re: NSWindowController subclass initialization
Re: NSWindowController subclass initialization
- Subject: Re: NSWindowController subclass initialization
- From: James Bucanek <email@hidden>
- Date: Sun, 3 Dec 2006 08:51:23 -0700
Jonathon Mah wrote on Sunday, December 3, 2006:
>On 2006-12-03, at 09:33, Jeff Hellman wrote:
>
>> In HandoutsReportController.m I have the following method:
>>
>> -(id) init {
>
>I don't think this is the problem here, but subclasses should
>generally override the designated initializer (which, for
>NSWindowController, is -initWithWindow:).
That shouldn't be the problem here. The need for a subclass to override the designated initializer is only a requirement if that subclass will be constructed by some other agent, like the framework, that expects the call to [subClass iniWithWindow:] to initialize the subclass. If Jeff were creating a class that was going to be created by, say, a NIB (like a subclass of NSWindow) then it would be important to implement the designated initializer.
But in this instance the intializer is his own and implies the window resource to be constructed, which is all correct. In this instance, the only requirement is that the desginated initializer be called to initialize the superclass, which he is doing.
In these situations I will often override the designated initializer and have it throw an exception. This catches any unwanted calls to the designated initializer on my subclass.
Jeff Hellman wrote on Saturday, December 2, 2006:
>Notice that the init method in HandoutsReportController is never
>> called. If I change my Active Build from Release to Debug, this works
>> perfectly:
This is the red flag. I would suggest that Jeff *very carefully* review the differences in build settings between the two build configurations and perform a clean build. Another useful exercise is to duplicate your release build configuration and then turn on full debug information and simply debug the release build. The debugger is much more illuminating than NSLog statements for these kinds of problems.
--
James Bucanek
_______________________________________________
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