• 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: My Several posts on dealloc/cleanup by framework - Summary & Thanks (was: Collection of Cocoa & objc etc.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: My Several posts on dealloc/cleanup by framework - Summary & Thanks (was: Collection of Cocoa & objc etc.


  • Subject: Re: My Several posts on dealloc/cleanup by framework - Summary & Thanks (was: Collection of Cocoa & objc etc.
  • From: tyler <email@hidden>
  • Date: Wed, 18 Jul 2001 09:43:17 -0700

I'd like to thank everyone who responded. One response suggested that my posts may have reflected a "bad attitude". I apologize if it seemed that way. That was not my intention at all, not one bit.

As I tried to say in at least one post, I just want OS X & Cocoa to succeed and not become another OpenDoc, or well any of a long list of cool technologies born at apple that never made it. Cocoa seems like it's just too cool to let fail so I'm motivated to make an effort to communicate where I see bumps in the road for others learning Cocoa.


Art (from apple) made some excellent comments that clarified matters a great deal, and corrected some mistatements/misconceptions held by myself and a few others. If you didn't catch his posts, you might want to go back and take a look. Good info.


If I may summarize where I think we have arrived on these questions:

1) Framework design choices are not objective. The issue with the dealloc method being called for objects instantiated out of a nib file which is auto-loaded by the framework is not completely agreed upon.

In general the response is: this is the way it works; here's how to deal with it. Art from apple provided some excellent direction on how to define and set variables so as to be able to release the objects that were instantiated out of the main nib file by code in NSApplicationMain(). Be nice if this issue and Art's clarifications/suggestions in this area were to be incorporated in a future edition of Learning Cocoa.


2) the issue with the dealloc method not being called in the DotView sample (ch. 8, Learning Cocoa) is that the window must have the "Release on close" check box checked in the attributes section in IB and this solves this "issue". This should be documented as well (since the sample code implements a dealloc method which by implication is called, but since the sample directions do not mention the off by default "Release on close" checkbox the implication is not actualized).


3) the issue with having awakeFromNib and initWithFrame called multiple times in my building of the DotView sample was MY error. I instantiated the DotView custom view class via the classes menu. However, this is not necessary in the case of custom views (only controllers I guess) because putting a custom view onto the window and setting it's custom class to be the DotView custom class instantiates it. So I DID have two DotView objects (which is what it appeared like) and that was due to my error of going a bit too fast through that sample.


That's it. I really appreciate all your efforts to clarify this stuff. And again, I apologize if my frustration with not being able to figure elements of this leaked into my posts.

peace,
tyler


References: 
 >Re: NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug. (From: "David P. Henderson" <email@hidden>)

  • Prev by Date: saving NSColors to NSUserDefaults
  • Next by Date: Re: Drawing an NSImage
  • Previous by thread: Re: NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
  • Next by thread: When rabid threads have to be put to sleep...
  • Index(es):
    • Date
    • Thread