• 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: Collection of Cocoa & objc questions from a "newbie"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Collection of Cocoa & objc questions from a "newbie"


  • Subject: Re: Collection of Cocoa & objc questions from a "newbie"
  • From: tyler <email@hidden>
  • Date: Tue, 17 Jul 2001 13:15:54 -0700

Hi Erik,
I lost the end of your message it appears. The NOTE:....

This does NOT seem at all intuitive. In fact, the Notification Sample in Ch. 8 of Learning Cocoa implies something quit different; In that sample the controller object is specifically given a dealloc method so that it can remove itself from the Notification Center and there is a special note indicating that this is important.

And yet that sample makes no explicit release on the controller.

In fact, I'm not 100% HOW or where you'd make this release call since you don't really have an reference (variable) for the controller instantiated from the main nib file; and what piece of code (what method) would get called to actually do this release if you DID have such a reference? Perhaps the -applicationShouldTerminate method that "j o a r" indicated in a recent email that he (she?) implemented.


I find this not at all clear from the documentation I have read and the Learning Cocoa book samples which strongly seem to imply that the dalloc method will be called when an app quits because the app will delete objects that were automatically created by it. In my opinion someone instantiated the objects in the main nib and that someone should be releasing them on application quit.


The window setting in IB is a good reminder and I'll check that out. May not handle the application Quit case since the delegate calls for windowShouldClose don't even get called then (see my other NSApplication bug post).


tyler



On Tuesday, July 17, 2001, at 12:45 PM, Erik M. Buck wrote:

Actually, I'm not explicitly creating it so I figured that the loadNib
or whatever that did the creation would take care of disposing of the
view when the window (?) was disposed of. Am I incorrect in this?
The only instance of the DotView object is the one created by whatever
code loads a nib object and then disposes of it when the window is
disposed of.


When a nib is loaded, all top level objects have a retain count of 1 meaning
that you "own" them and must release them at some time. Objects that are
not at the top level are retained by their containers such as windows and
boxes. Top level objects include any objects in the "objects" window except
the "files owner" and "first responder" because they are not actual objects:
they are place holders. So, windows, objects that you instantiated via the
instantiate object menu, etc will all have a retain count of 1 after the nib
is loaded. You need to release such objects.

One way to release your DotView is to check the box in IB that is labeled
something like "release on close". That will send a release message to the
window and the window will release its content view and the content view
will release the DotView ...

NOTE: Memory that is not explicitly deallocated is implicitly


  • Prev by Date: Re: NSApplication Bug. Quit doesn't notify windows (& delegates), just kills them.
  • Next by Date: NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
  • Previous by thread: Re: Removing Developer Tools - WebObjects demo
  • Next by thread: Re: Collection of Cocoa & objc questions from a "newbie"
  • Index(es):
    • Date
    • Thread