Re: Retained Outlet
Re: Retained Outlet
- Subject: Re: Retained Outlet
- From: Richard Somers <email@hidden>
- Date: Fri, 18 Nov 2011 12:22:55 -0700
On Nov 18, 2011, at 9:31 AM, Kyle Sluder wrote:
> On Fri, Nov 18, 2011 at 8:23 AM, Richard Somers wrote:
>> The normal pattern for Interface Builder Outlets is assign but I have an outlet that must be retained to work corectly. The outlet is not in File's Owner but is in a custom view in a window.
>
> It is very important that you specify whether you're working on iOS or Mac OS X, and whether your outlet points to a top-level object.
I am working on Mac OS X. The outlet points to a top-level object.
> Maybe you can answer your own question by re-reading the Resource Programming Guide:
In general, you are responsible for releasing top-level objects in a nib file. But my File's Owner is an instance of NSWindowController so it will release top-level objects for me.
The outlet in question is in a custom class and requires a setter with retain semantics. NSWindowController will use this setter for the outlet when loading the nib.
Object ownership policy seems a little blurry here. Normally a class will initialize its ivars and then cleanup in dealloc. But the custom class never initializes the outlet. The nib loading machinery initialize the outlet.
So that may mean NSWindowController knows that the outlet has retain semantics and will set the outlet to nil when releasing top-level objects. If not then the class should release the outlet in its dealloc method. I am confused, which one is it?
Maybe I am looking at this wrong. If a class, any class, has an ivar with retained property semantics, it will be initialized to nil even if the class does not explicitly initialize the ivar. In the class dealloc method it should directly release the ivar regardless. If the ivar points to an object, for what ever reason, it will receive a release message. If the ivar is nil, for what ever reason, a release message will go to nil. Either way it works. It this the correct way to look at this?
--Richard
_______________________________________________
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