Should I retain/release IBOutlet?
-
In most of the code I've seen (and wrote), I don't ever retain nor release
IBOutlet ivars. I just assume they will be allocated and deallocated with
the object itself along with the nib that contains them. Is there any
situation where I would want to manually retain / release IBOutlet within my
class? For example, if some other object (outside of the NIB) retains the
object containing the IBOutlet.
thanks,
eric -
On May 13, 2006, at 2:47 PM, Eric wrote:
> In most of the code I've seen (and wrote), I don't ever retain nor
> release
> IBOutlet ivars. I just assume they will be allocated and
> deallocated with
> the object itself along with the nib that contains them. Is there any
> situation where I would want to manually retain / release IBOutlet
> within my
> class? For example, if some other object (outside of the NIB)
> retains the
> object containing the IBOutlet.
This is covered in the documentation:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
LoadingResources/Concepts/NibFileLoaded.html#//apple_ref/doc/uid/
20000884>
mmalc -
Im sure someone will argue with my answer but that's ok... Only top
level objects in the Nib need to be released by you.. those are all the
objects in the little window that contains 'File's Owner'. all other
objects in a nib will be released automatically... for example any
buttons you put in a window will be released by the window when it is
deallocated. Now I never release the main menu even though it is a top
level object, this is probably not stylistically correct but I never
have any problem with it, since the main menu normally stays in
existence throughout the application's life... Whatever object
(usually File's Owner) that created the nib should release the top
level objects in it... I strongly suggest using the document
architecture because it automates many various tasks into a really nice
way of managing nibs, window controllers and documents... It doesn't
really matter if the object is connected to an IBOutlet or not, but I
might be wrong about that I don't know everything about nibs yet...
There are funny things that happen (and not very well documented) when
you connect outlets between two different Nibs...
On May 13, 2006, at 2:47 PM, Eric wrote:
> In most of the code I've seen (and wrote), I don't ever retain nor
> release
> IBOutlet ivars. I just assume they will be allocated and deallocated
> with
> the object itself along with the nib that contains them. Is there any
> situation where I would want to manually retain / release IBOutlet
> within my
> class? For example, if some other object (outside of the NIB) retains
> the
> object containing the IBOutlet.
>
> thanks,
> eric
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<Cocoa-dev...>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/
> <lgiese...>
>
> This email sent to <lgiese...>
>
-
On May 13, 2006, at 6:06 PM, Lon Giese wrote:
> Im sure someone will argue with my answer but that's ok... Only
> top level objects in the Nib need to be released by you.. those are
> all the objects in the little window that contains 'File's Owner'.
> all other objects in a nib will be released automatically... for
> example any buttons you put in a window will be released by the
> window when it is deallocated. Now I never release the main menu
> even though it is a top level object, this is probably not
> stylistically correct but I never have any problem with it, since
> the main menu normally stays in existence throughout the
> application's life... Whatever object (usually File's Owner)
> that created the nib should release the top level objects in it...
> I strongly suggest using the document architecture because it
> automates many various tasks into a really nice way of managing
> nibs, window controllers and documents... It doesn't really
> matter if the object is connected to an IBOutlet or not, but I
> might be wrong about that I don't know everything about nibs
> yet... There are funny things that happen (and not very well
> documented) when you connect outlets between two different Nibs...
I would suggest reading the documentation (and not restating the
documentation as per list guidelines).
Specifically, start here:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/
MemoryMgmt.html
Then read this:
http://developer.apple.com/documentation/Cocoa/Conceptual/
LoadingResources/Concepts/NibFileLoaded.html#//apple_ref/doc/uid/
20000884
For Core Data:
http://devworld.apple.com/documentation/Cocoa/Conceptual/CoreData/
Articles/cdMemory.html -
thanks for all your response. However, I'm not so concerned with when or
who to release the objects in the nib as to whether one should retain them.
For example, if I have a nib with a file owner, and another placeholder
object like a custom controller class. If my custom controller class
contains IBOutlet to other objects in the nib (like UI element), should the
custom controller retain its IBOutlets? Or should the controller just
assume the objects will be retained by the file's owner?
thanks -
On May 17, 2006, at 9:46 AM, Eric wrote:
> However, I'm not so concerned with when orAgain, this is answered in the documentation...
> who to release the objects in the nib as to whether one should
> retain them.
> For example, if I have a nib with a file owner, and another
> placeholder
> object like a custom controller class. If my custom controller class
> contains IBOutlet to other objects in the nib (like UI element),
> should the
> custom controller retain its IBOutlets? Or should the controller just
> assume the objects will be retained by the file's owner?
>
mmalc -
Sorry I don't mean to bother you.. but I've read through all the documents
referred to by Bill twice and still could not find the answer to my
question. Could you point me to where in the documentation is my question
answered? There is nothing specifically stating whether I should manually
retain objects loading from a NIB.
On 5/17/06, mmalcolm crawford <mmalc_lists...> wrote:
>
>
> On May 17, 2006, at 9:46 AM, Eric wrote:
>
>> However, I'm not so concerned with when or
>> who to release the objects in the nib as to whether one should
>> retain them.
>> For example, if I have a nib with a file owner, and another
>> placeholder
>> object like a custom controller class. If my custom controller class
>> contains IBOutlet to other objects in the nib (like UI element),
>> should the
>> custom controller retain its IBOutlets? Or should the controller just
>> assume the objects will be retained by the file's owner?
>>
> Again, this is answered in the documentation...
>
> mmalc
>
>
-
On May 17, 2006, at 11:40 AM, Eric wrote:
> Sorry I don't mean to bother you.. but I've read through all the
> documents referred to by Bill twice and still could not find the
> answer to my question. Could you point me to where in the
> documentation is my question answered? There is nothing
> specifically stating whether I should manually retain objects
> loading from a NIB.
It's specified in the document I referred you to first time:
<http://developer.apple.com/documentation/Cocoa/Conceptual/
LoadingResources/Concepts/NibFileLoaded.html#//apple_ref/doc/uid/
20000884>
together with additional discussion in the other articles.
mmalc -
Thanks, this is what I needed. So I can kind of consider IBOutlet to be a
type of weak reference.
On 5/17/06, Julien Jalon <jjalon...> wrote:
>
> When loading a nib, you should consider that it's like if "file owner"
> allocated and "owns" responsibility to release top-level objects only,
> so "file owner" does not need to retain them an extra time but will
> have to release them when needed.
>
> object -> object IBOutlet link does not suppose any retain-release. If
> you have a top-level object instantiated by the nib-loading linked to
> an other object using IBOutlet, this top-level object is not
> considered having any ownership to that other object so does not need
> to release it.
>
> Nobody can answer your question "If my custom controller class
> contains IBOutlet to other objects in the nib (like UI element), should
> the
> custom controller retain its IBOutlets" as we don't know what the
> relationship between your controller and that UI element is meant to
> be. If you consider that the controller needs ownership to that
> element, you need to add an extra retain after nib-loading ensuring
> that your controller will prevent the element to be deallocated
> without its consent.
>
> When working on retain/release, always think in terms of "ownership".
> IBOutlet does not imply any ownership.
>
> --
> Julien
>
> On 5/17/06, Eric <eylin2004...> wrote:
>> Sorry I don't mean to bother you.. but I've read through all the
> documents
>> referred to by Bill twice and still could not find the answer to my
>> question. Could you point me to where in the documentation is my
> question
>> answered? There is nothing specifically stating whether I should
> manually
>> retain objects loading from a NIB.
>>
>> On 5/17/06, mmalcolm crawford <mmalc_lists...> wrote:
>>>
>>>
>>> On May 17, 2006, at 9:46 AM, Eric wrote:
>>>
>>>> However, I'm not so concerned with when or
>>>> who to release the objects in the nib as to whether one should
>>>> retain them.
>>>> For example, if I have a nib with a file owner, and another
>>>> placeholder
>>>> object like a custom controller class. If my custom controller
> class
>>>> contains IBOutlet to other objects in the nib (like UI element),
>>>> should the
>>>> custom controller retain its IBOutlets? Or should the controller
> just
>>>> assume the objects will be retained by the file's owner?
>>>>
>>> Again, this is answered in the documentation...
>>>
>>> mmalc
>>>
>>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Cocoa-dev mailing list (<Cocoa-dev...>)
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/<jjalon...>
>>
>> This email sent to <jjalon...>
>>
>
-
On May 17, 2006, at 1:02 PM, Eric wrote:
> On 5/17/06, Julien Jalon <jjalon...> wrote:
>> object -> object IBOutlet link does not suppose any retain-
>> release. If
>> you have a top-level object instantiated by the nib-loading linked to
>> an other object using IBOutlet, this top-level object is not
>> considered having any ownership to that other object so does not need
>> to release it.
>> Nobody can answer your question "If my custom controller class
>> contains IBOutlet to other objects in the nib (like UI element),
>> should
>> the custom controller retain its IBOutlets" as we don't know what the
>> relationship between your controller and that UI element is meant to
>> be. If you consider that the controller needs ownership to that
>> element, you need to add an extra retain after nib-loading ensuring
>> that your controller will prevent the element to be deallocated
>> without its consent.
>>
This is misleading/inaccurate/wrong.
> So I can kind of consider IBOutlet to be a type of weak reference.As a *general* statement, no.
>
IBOutlet is simply a flag used specifically by Interface Builder. It
has no other semantics. Look to see what it's defined as...
I don't understand why it seems so difficult to accept what's written
in the documentation? It's all covered there, and there's not much
to it...
mmalc -
On 5/18/06, mmalcolm crawford <mmalc_lists...> wrote:
>
> On May 17, 2006, at 1:02 PM, Eric wrote:
>> On 5/17/06, Julien Jalon <jjalon...> wrote:
>>> object -> object IBOutlet link does not suppose any retain-
>>> release. If
>>> you have a top-level object instantiated by the nib-loading linked to
>>> an other object using IBOutlet, this top-level object is not
>>> considered having any ownership to that other object so does not need
>>> to release it.
>>> Nobody can answer your question "If my custom controller class
>>> contains IBOutlet to other objects in the nib (like UI element),
>>> should
>>> the custom controller retain its IBOutlets" as we don't know what the
>>> relationship between your controller and that UI element is meant to
>>> be. If you consider that the controller needs ownership to that
>>> element, you need to add an extra retain after nib-loading ensuring
>>> that your controller will prevent the element to be deallocated
>>> without its consent.
>>>
>
> This is misleading/inaccurate/wrong.
>
I don't see what's misleading/inaccurate/wrong here. What I state is
that, in itself, linking two objects using IB (one as an outlet of the
other) will lead to no extra retain so outlets makes no supposition to
any object ownership. The fact that "when you load a nib file, all its
top level objects have a reference count of one" means that file owner
is considered owning the top level objects (and has to release them if
needed).
>> So I can kind of consider IBOutlet to be a type of weak reference.
>>
> As a *general* statement, no.
> IBOutlet is simply a flag used specifically by Interface Builder. It
> has no other semantics. Look to see what it's defined as...
>
It has no semantic, except it clearly supposes that the corresponding
marked ivar will likely be set using IB outlet link. So the ivar will
likely be a weak-reference.
--
Julien -
On May 17, 2006, at 4:06 PM, Julien Jalon wrote:
> I don't see what's misleading/inaccurate/wrong here.Please, read the documentation. In particular the difference in
>
behaviour between nibs loaded by NSWindowController objets and those
loaded by other objects...
mmalc -
"NSWindowController automatically releases its nib file's objects for you "
Which makes sense as the window controller is the file owner in the nib.
NSWindowController does his "file-owner" jobs: it keeps track of
top-level objects and release them when relevant. This is no special
case here.
The only special case is the "isReleasedOnClose" which is a "small"
hack to do simple nibs containing only one window. It is cleaner to
use NSWindowController stuff.
--
Julien
On 5/18/06, mmalcolm crawford <mmalc_lists...> wrote:
>
> On May 17, 2006, at 4:06 PM, Julien Jalon wrote:
>
>> I don't see what's misleading/inaccurate/wrong here.
>>
> Please, read the documentation. In particular the difference in
> behaviour between nibs loaded by NSWindowController objets and those
> loaded by other objects...
>
> mmalc
>
>
