Well, I am releasing them. If I am releasing all of them or not
would depend on the code providing them to me to be working.
So, you have code in place to release the top level items, but it's
not called - probably of a "retain cycle" that prevents the nib file
owner itself from being deallocated. Sounds about right?
What do you hope to accomplish by doing this, compared with
regular nib loading?
When you're tracking retain-release events, do you see that it
makes any difference?
If I don't load the nib, everything cleans up properly. I know for
a fact this is where my overretaining problem is coming from.
That's not what I was asking about, but rather why you thought / see
that this other way of loading nib files would be better / different
than the usual way?
The problem when that is the top level items are retaining me, so
I'll never get dealloc'd. I do, however, have a mechanism in my
application to tell these nodes to "unload", where I am releasing
the top level items, similar to how a window controller probably
does when it's associated document closes.
Yes, it's being called and I can indeed see the retain count go
down as a consequence of doing so.
But not enough? If this were a simple retain cycle, I would have
expected this to solve the problem.
Bindings might have nothing to do with my problem, or everything.
I don't know. I just thought I'd point out that I'm using them in
case it's important for the solution.
Right, and I agree that it would be interesting to find out if
they're related or not - for example by removing the bindings, but
still do the nib loading.
On 10 apr 2006, at 10.02, Paul Forgey wrote:
Ughh this retain stuff can still be confusing.
Aww, it's really very simple! Reference counted memory management is
all about conceptual ownership. And the reference counter itself is
just that, a counter. The only thing that might be simpler would be
fully automatic memory management - like GC - but I don't think that
you would get away from thinking about object ownership, and the
handover of objects between owners.
The meaning of his comment finally struck me stupid:
// nibInstantiateWithOwner retains each top level object
[topLevelObjects makeObjectsPerformSelector:@selector
(release)];
Which means that we wasn't intending the objects to be left owned
by the array, but to be not doubly retained by being in the array.
Not doubly retained by the array. The array only retains objects
added to it once. The other retain comes from the nib loading machinery.
Of course that would make sense (duh) as he's getting this array by
looking it up from another container.. So it wasn't a coincidence
my retain count went down by 14 but still needed another 14 to be
finally released.
What object is it that needs 14 release events to reach 0? It sounds
a bit weird.
Although a bit simplistic for general purpose, this ended up
solving my problem:
I don't see how this can solve your problem. You're still just doing
the same thing - loading an nib file. There's something else going on
here, and I think you would do yourself a service if you spent the
time required to figure out what it is.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
This email sent to email@hidden
