• 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: Nib ownership and retain count
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Nib ownership and retain count


  • Subject: Re: Nib ownership and retain count
  • From: Keary Suska <email@hidden>
  • Date: Sun, 27 Jan 2008 09:53:51 -0700
  • Thread-topic: Nib ownership and retain count

on 1/25/08 9:56 AM, email@hidden purportedly said:

>> A simple search of the archives, and reviewing some very recent  threads,
>> never, ever, ever rely on retain count for *anything*. Ultimately,  it's none
>> of your code's business. That being said, your release method would  simply:
>> 1) [topLevelObjects release] and 2) [super release] . That should  be enough
>> to release everything as soon as the current autorelease pool is  drained,
>> and as long as you aren't needlessly retaining.
>
> This is very wrong.  Your release method may be called many times
> over the object's lifetime, but should only release topLevelObjects
> once -- on the last release.  Or preferably, on dealloc, if you can
> resolve the retain cycle that's preventing the object from being
> fully released.

Oop! You are very right about that. That must be why I have never done it
that way. What I was really focusing on was that waiting for the retain
count to drop to 1 will not work at all (as the OP found out).

The only solution I have found, that works reliably, is to have an object
that "owns" the nib loading object, and is responsible for ultimately
disposing of it. In this case, the owning object calls a specific method of
the nib loading object that releases its top level objects, and then calls
-release on the nib loading object.

Of course, the above can be problematic if you have any objects outside of
the nib that have references to objects inside the nib. This should be
avoided at any rate, IMHO.

If you can manage to avoid having any nib objects retaining the nib owner,
which means no bindings to or through file's owner, and possibly no outlets
to it either (depends on the outlet, of course--most don't retain, but some
do), then you will avoid the retain cycles and can dispose of everything
"naturally".

Or, as this poster recommends, use NSWindowController (most likely your own
custom subclass). I wish Apple would release how NSWindowController breaks
retain cycles...

Best,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

References: 
 >Re: Nib ownership and retain count (From: Ken Thomases <email@hidden>)

  • Prev by Date: Help about the Interface builder core animation function
  • Next by Date: Capture window content
  • Previous by thread: Re: Nib ownership and retain count
  • Next by thread: Changing CALayer's contents too rapidly causes CoreAnimation to implode?
  • Index(es):
    • Date
    • Thread