• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSWindowController subclass initialization
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSWindowController subclass initialization


  • Subject: Re: NSWindowController subclass initialization
  • From: "Jeff Hellman" <email@hidden>
  • Date: Sun, 3 Dec 2006 09:38:03 -0800

Thanks for all the ideas...

I'd trashed the build folder *many* times in an effort to make this
work.  I also stepped through in the debugger with no problems.

Finally, I *again* went to the file information for
HandoutsReportController.m and deselected the option to add the target
of my application and then reselected the same option. All works
beautifully now.  I had done this many times previously.

But, it's working now and I can get busy implementing features and not
dealing with this!

Thanks again,
Jeff

On 12/3/06, James Bucanek <email@hidden> wrote:
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



--
Jeff Hellman
email@hidden
_______________________________________________

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


References: 
 >Re: NSWindowController subclass initialization (From: Jonathon Mah <email@hidden>)

  • Prev by Date: Trouble Writing to File With NSFileHandle
  • Next by Date: Re: Trouble Writing to File With NSFileHandle
  • Previous by thread: Re: NSWindowController subclass initialization
  • Next by thread: really elementary to-many inverse relationship question
  • Index(es):
    • Date
    • Thread