Toplevel Objects in NIB files
-
I asked this before, but under a different subject line, so maybe
it didn't get any attention :)
What I would _really_ like to know is how NSWindowController learns
to know all top level objects in its associate NIBs. This is a
trick I would like to do myself sometimes.
Cheers
Nat!
------------------------------------------------------
Some people drink deep from the fountains of life, and
some just gargle. -- DLR
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, April 2, 2002, at 07:32 PM, Nat! wrote:
> I asked this before, but under a different subject line, so maybe it
> didn't get any attention :)
>
> What I would _really_ like to know is how NSWindowController learns to
> know all top level objects in its associate NIBs. This is a trick I
> would like to do myself sometimes.
After the NIB is loaded and the objects in it deserialized, for each
outlet, a corresponding set*: method is looked for in the NIB's owner,
and if it's found, called.
For example, if you've created and connected an outlet named "myButton"
in IB, the method "setMyButton:" will be called when the NIB is loaded,
with a pointer to the object loaded from the NIB.
The Objective-C runtime will generate accessor methods automagically.
So, if no "setMyButton:" method is defined, but a "myButton" instance
variable exists, the value passed to the method call is assigned to the
instance variable. Similarly, if a "myButton" is called, the value of
the instance variable is returned.
FWIW, I don't recall seeing any really good documentation about this -
and I looked hard, because it's very important for supporting
dynamically-loaded NIBs within a language bridge. I figured it out for
CamelBones by coding my proxy class to report the name of each method
asked for with "respondsToSelector:", and then noticed that a call to
"setWhatever:" got generated for each outlet I wired up in my NIBs.
I *think* that this happens in the establishConnection: method of the
NSNibOutletConnector class - but the documentation only says that this
method establishes connections, without saying anything about how
they're established.
Hope this helps!
sherm--
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tue, Apr 02, 2002 at 08:26:52PM -0500, Sherm Pendley wrote:
> FWIW, I don't recall seeing any really good documentation about this -
> and I looked hard, because it's very important for supporting
> dynamically-loaded NIBs within a language bridge. I figured it out for
> CamelBones by coding my proxy class to report the name of each method
> asked for with "respondsToSelector:", and then noticed that a call to
> "setWhatever:" got generated for each outlet I wired up in my NIBs.
The behavior you're seeing - where a method is used, then if it
doesn't respond, an instance variable is used - is the result of
key-value coding.
<http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_
classic/Protocols/NSKeyValueCoding.html>
Even if NSNibOutletConnector isn't using take[StoredValue:forKey:, the
resulting behavior is similar.
I've been caught by this a number of times when I happened to have
implemented a setXXX method and was confused why an outlet wasn't
being hooked up! Key-value coding is very flexible, and I use it a
lot especially when reading/writing data.
--
=Nicholas Riley <njriley...> | <http://www.uiuc.edu/ph/www/njriley>
Pablo Research Group, Department of Computer Science and
Medical Scholars Program, University of Illinois at Urbana-Champaign
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, April 2, 2002, at 09:08 PM, Nicholas Riley wrote:
> On Tue, Apr 02, 2002 at 08:26:52PM -0500, Sherm Pendley wrote:
>> FWIW, I don't recall seeing any really good documentation about this -
> The behavior you're seeing - where a method is used, then if it
> doesn't respond, an instance variable is used - is the result of
> key-value coding.
My statement about the documentation was imprecise. You're right, the
key-value coding pattern is pretty well documented.
The use of the key-value coding pattern by NSNibOutletConnector, on the
other hand, is not very well documented that I've been able to find. I
was only able to figure it out by logging calls to
"respondsToSelector:", and noting that calls to "setFoo:" were being
made for each outlet when a NIB is loaded.
Not that I'm in a position to criticize Apple's documentation - the
documentation for my own project is even more sparse... :-(
sherm--
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, April 2, 2002, at 05:26 PM, Sherm Pendley wrote:
> On Tuesday, April 2, 2002, at 07:32 PM, Nat! wrote:
>
>> I asked this before, but under a different subject line, so maybe it
>> didn't get any attention :)
>>
>> What I would _really_ like to know is how NSWindowController learns to
>> know all top level objects in its associate NIBs. This is a trick I
>> would like to do myself sometimes.
>
> After the NIB is loaded and the objects in it deserialized, for each
> outlet, a corresponding set*: method is looked for in the NIB's owner,
> and if it's found, called.
>
> For example, if you've created and connected an outlet named "myButton"
> in IB, the method "setMyButton:" will be called when the NIB is loaded,
> with a pointer to the object loaded from the NIB.
That's all well and good, but what about the top-level objects that
aren't connected to any outlet?
-g
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, April 2, 2002, at 05:26 PM, Sherm Pendley wrote:
> On Tuesday, April 2, 2002, at 07:32 PM, Nat! wrote:
>
>> I asked this before, but under a different subject line, so maybe it
>> didn't get any attention :)
>>
>> What I would _really_ like to know is how NSWindowController learns to
>> know all top level objects in its associate NIBs. This is a trick I
>> would like to do myself sometimes.
>
If you really want to do this, basically you do this here.
use the NSBundle method loadNibFile: externalNameTable:withZone:
[NSBundle loadNibFile:windowPath externalNameTable:[NSDictionary
dictionaryWithObjectsAndKeys:[self owner], @"NSOwner", topLevelObjects, @"
NSTopLevelObjects", nil] withZone:[self zone]]
the NSMutableArray (topLevelObjects) will then get filled with all of them.
vince
> After the NIB is loaded and the objects in it deserialized, for each_______________________________________________
> outlet, a corresponding set*: method is looked for in the NIB's owner,
> and if it's found, called.
>
> For example, if you've created and connected an outlet named "myButton"
> in IB, the method "setMyButton:" will be called when the NIB is loaded,
> with a pointer to the object loaded from the NIB.
>
> The Objective-C runtime will generate accessor methods automagically. So,
> if no "setMyButton:" method is defined, but a "myButton" instance
> variable exists, the value passed to the method call is assigned to the
> instance variable. Similarly, if a "myButton" is called, the value of the
> instance variable is returned.
>
> FWIW, I don't recall seeing any really good documentation about this -
> and I looked hard, because it's very important for supporting
> dynamically-loaded NIBs within a language bridge. I figured it out for
> CamelBones by coding my proxy class to report the name of each method
> asked for with "respondsToSelector:", and then noticed that a call to
> "setWhatever:" got generated for each outlet I wired up in my NIBs.
>
> I *think* that this happens in the establishConnection: method of the
> NSNibOutletConnector class - but the documentation only says that this
> method establishes connections, without saying anything about how they're
> established.
>
> Hope this helps!
>
> sherm--
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Am Mittwoch den, 3. April 2002, um 19:42, schrieb Vince DeMarco:
>
> If you really want to do this, basically you do this here.
> use the NSBundle method loadNibFile: externalNameTable:withZone:
>
> [NSBundle loadNibFile:windowPath externalNameTable:[NSDictionary
> dictionaryWithObjectsAndKeys:[self owner], @"NSOwner",
> topLevelObjects, @"
> NSTopLevelObjects", nil] withZone:[self zone]]
>
>
> the NSMutableArray (topLevelObjects) will then get filled with all
> of them.
>
> vince
>
Works nicely. Testing this I found that no "NSNibConnector" (and
subclasses) objects show up. As nibtool hints "Connectors" appear
to be stored outside the object hierarchy, so they probably are
used in the NIB loading process to wire things up [and then they
are "forgotten" (?)]
Is there another key like "NSConnectors" to get the connectors
too ? Looking with strings through AppKit I didn't find a likely
candidate.
What I am also wondering is, who owns and releases the connectors?
If there is no "NSConnectors" key, the NSWindowController probably
can't do that. And the views can't either, because at best they
know about the connector as a delegate (and they don't
retain/release the delegate). The connectors themselves can't know
when the views "disappear". Is this a built in memory leak ?
Cheers
Nat!
------------------------------------------------------
Some people drink deep from the fountains of life, and
some just gargle. -- DLR
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Thursday, April 4, 2002, at 01:51 PM, Nat! wrote:
>
> Am Mittwoch den, 3. April 2002, um 19:42, schrieb Vince DeMarco:
>>
>> If you really want to do this, basically you do this here.
>> use the NSBundle method loadNibFile: externalNameTable:withZone:
>>
>> [NSBundle loadNibFile:windowPath externalNameTable:[NSDictionary
>> dictionaryWithObjectsAndKeys:[self owner], @"NSOwner", topLevelObjects, @
>> "
>> NSTopLevelObjects", nil] withZone:[self zone]]
>>
>>
>> the NSMutableArray (topLevelObjects) will then get filled with all of
>> them.
>>
>> vince
>>
>
> Works nicely. Testing this I found that no "NSNibConnector" (and
> subclasses) objects show up. As nibtool hints "Connectors" appear to be
> stored outside the object hierarchy, so they probably are used in the NIB
> loading process to wire things up [and then they are "forgotten" (?)]
>
> Is there another key like "NSConnectors" to get the connectors too ?
> Looking with strings through AppKit I didn't find a likely candidate.
>
> What I am also wondering is, who owns and releases the connectors? If
> there is no "NSConnectors" key, the NSWindowController probably can't do
> that. And the views can't either, because at best they know about the
> connector as a delegate (and they don't retain/release the delegate). The
> connectors themselves can't know when the views "disappear". Is this a
> built in memory leak ?
>
After the connections are made the connectors are all released. They don't
leak (or at least they should not leak)
NSNibConnectors are not considered top level objects they are just managed
by IB and the runtime on its own.
There is no key to get all of the connectors.
If you write a palette in IB you can ask the IBDocuments object for
connectors and look there.
look at all of the IB frameworks in
/System/Library/Frameworks/InterfaceBuilder.framework
vince
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
The NSNibConnectors are objects that represent outlet and action
connections between the objects in the nib. When the nib is loaded, all
of the connectors get invoked to actually set the outlets and actions on
the real unarchived objects, then the connectors are discarded.
So the connectors are already gone (or at least autoreleased) by the
time the -loadNibFile: method returns to you.
Hope this helps,
--Greg
On Thursday, April 4, 2002, at 01:51 PM, Nat! wrote:
> Works nicely. Testing this I found that no "NSNibConnector" (and_______________________________________________
> subclasses) objects show up. As nibtool hints "Connectors" appear to be
> stored outside the object hierarchy, so they probably are used in the
> NIB loading process to wire things up [and then they are
> "forgotten" (?)]
>
> Is there another key like "NSConnectors" to get the connectors too ?
> Looking with strings through AppKit I didn't find a likely candidate.
>
> What I am also wondering is, who owns and releases the connectors? If
> there is no "NSConnectors" key, the NSWindowController probably can't
> do that. And the views can't either, because at best they know about
> the connector as a delegate (and they don't retain/release the
> delegate). The connectors themselves can't know when the views
> "disappear". Is this a built in memory leak ?
>
> Cheers
> Nat!
> ------------------------------------------------------
> Some people drink deep from the fountains of life, and
> some just gargle. -- DLR
> _______________________________________________
> cocoa-dev mailing list | <cocoa-dev...>
> Help/Unsubscribe/Archives:
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
> Do not post admin requests to the list. They will be ignored.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
Am Freitag den, 5. April 2002, um 01:52, schrieb Vince DeMarco:
>Thanks to Greg and Vince for the info. I didn't fully comprehend
> On Thursday, April 4, 2002, at 01:51 PM, Nat! wrote:
>
>>
>> Am Mittwoch den, 3. April 2002, um 19:42, schrieb Vince DeMarco:
>>
>> What I am also wondering is, who owns and releases the
>> connectors? If there is no "NSConnectors" key, the
>> NSWindowController probably can't do that. And the views can't
>> either, because at best they know about the connector as a
>> delegate (and they don't retain/release the delegate). The
>> connectors themselves can't know when the views "disappear". Is
>> this a built in memory leak ?
>>
>
> After the connections are made the connectors are all released.
> They don't leak (or at least they should not leak)
>
that the NIBConnector is a fairly ephemeral object.
Is this in all cases true though ? As I understand it associations
are also some kind of connector, and they don't and shouldn't
disappear after loading. Maybe I am on the completely wrong track
here. Maybe associations are stored somewhere else entirely ? Are
they "NSTopLevelObjects" ? Sorry I don't have acesss to nibtool at
the moment to verify that they are or aren't.
Cheers
Nat!
------------------------------------------------------
Some people drink deep from the fountains of life, and
some just gargle. -- DLR
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Saturday, April 6, 2002, at 06:22 AM, Nat! wrote:
>
> Am Freitag den, 5. April 2002, um 01:52, schrieb Vince DeMarco:
>
>>
>> On Thursday, April 4, 2002, at 01:51 PM, Nat! wrote:
>>
>>>
>>> Am Mittwoch den, 3. April 2002, um 19:42, schrieb Vince DeMarco:
>>>
>>> What I am also wondering is, who owns and releases the connectors? If
>>> there is no "NSConnectors" key, the NSWindowController probably can't
>>> do that. And the views can't either, because at best they know about
>>> the connector as a delegate (and they don't retain/release the delegate)
>>> . The connectors themselves can't know when the views "disappear". Is
>>> this a built in memory leak ?
>>>
>>
>> After the connections are made the connectors are all released. They don'
>> t leak (or at least they should not leak)
>>
> Thanks to Greg and Vince for the info. I didn't fully comprehend that the
> NIBConnector is a fairly ephemeral object.
>
> Is this in all cases true though ? As I understand it associations are
> also some kind of connector, and they don't and shouldn't disappear after
> loading. Maybe I am on the completely wrong track here. Maybe
> associations are stored somewhere else entirely ? Are they
> "NSTopLevelObjects" ? Sorry I don't have acesss to nibtool at the moment
> to verify that they are or aren't.
>
What do you mean by associations??? (the ones in EOF??? or WebObjects???)
All connections in IB (outlets and actions) are done using connectors.
Apple Script Studio also uses connectors to do all of the things that it
does.
NSTopLevelObjects is basically what you see in the icon view in the IB
Document, What the document contains (its hierarchy) can be seen by
switching the document window in IB to outline mode
vince
> Cheers_______________________________________________
> Nat!
> ------------------------------------------------------
> Some people drink deep from the fountains of life, and
> some just gargle. -- DLR
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Saturday, April 6, 2002, at 12:53 PM, Vince DeMarco wrote:
> On Saturday, April 6, 2002, at 06:22 AM, Nat! wrote:
>
>> Am Freitag den, 5. April 2002, um 01:52, schrieb Vince DeMarco:
>>
>>> On Thursday, April 4, 2002, at 01:51 PM, Nat! wrote:
>>>
>>> After the connections are made the connectors are all released. They
>>> don'
>>> t leak (or at least they should not leak)
>>>
>> Thanks to Greg and Vince for the info. I didn't fully comprehend that
>> the NIBConnector is a fairly ephemeral object.
>>
>> Is this in all cases true though ? As I understand it associations
>> are also some kind of connector, and they don't and shouldn't
>> disappear after loading. Maybe I am on the completely wrong track
>> here. Maybe associations are stored somewhere else entirely ? Are
>> they "NSTopLevelObjects" ? Sorry I don't have acesss to nibtool at
>> the moment to verify that they are or aren't.
>
> What do you mean by associations??? (the ones in EOF??? or
> WebObjects???)
>
> All connections in IB (outlets and actions) are done using connectors.
> Apple Script Studio also uses connectors to do all of the things that
> it does.
>
> NSTopLevelObjects is basically what you see in the icon view in the IB
> Document, What the document contains (its hierarchy) can be seen by
> switching the document window in IB to outline mode
>
> vince
Is it true what the docs say about having to release top-level objects
(in
file:///Developer/Documentation/Cocoa/TasksAndConcepts/
ProgrammingTopics/LoadingResources/index.html) when loading a NIB
manually?
What do they mean by top-level objects? They obviously can't mean
File's Owner and First Responder, even though they show up in nibtool's
hierarchy. What about a naked NSView object that my code puts somewhere
else in the view hierarchy? What about the Font Manager object? If I
don't connect it to an outlet, do I still need to free it? If so, how?
--
Dustin
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
> From: Dustin Voss <d-j-v...>
>
> Is it true what the docs say about having to release top-level objects
> (in file:///Developer/Documentation/Cocoa/TasksAndConcepts/
> ProgrammingTopics/LoadingResources/index.html) when loading a NIB
> manually?
LoadingResources/index.html on 10.1:
"When you load a nib file, all its top level objects have a reference
count of one. When the objects are no longer needed, another object
needs to release them. That other object is usually the file's owner."
Short answer: yes; long answer: many top-level objects do not have a
referrence count of one after being loaded from a nib file, but they
were all owned by an object that is irresponsible and therefore need to
be released/autoreleased by another object.
> What do they mean by top-level objects?
Vince DeMarco answered this question:
>> NSTopLevelObjects is basically what you see in the icon view in the
>> IB Document, What the document contains (its hierarchy) can be seen
>> by switching the document window in IB to outline mode
> They obviously can't mean File's Owner and First Responder,
Since FirstResponder is actually nil, you don't need to worry about its
retain count. File's owner? No.
> What about a naked NSView object that my code puts somewhere else in
> the view hierarchy?
Yes.
> What about the Font Manager object?
Good question. I could guess, but I've never actually checked and I
don't know if it matters.
> If I don't connect it to an outlet, do I still need to free it?
Yes.
> If so, how?
You'll probably get lots of answer on this one. Its too late and I don't
have anything useful to say.
-jim
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Sunday, September 15, 2002, at 09:49 PM, James DiPalma wrote:
>> From: Dustin Voss <d-j-v...>
>>
>> Is it true what the docs say about having to release top-level
>> objects (in file:///Developer/Documentation/Cocoa/TasksAndConcepts/
>> ProgrammingTopics/LoadingResources/index.html) when loading a NIB
>> manually?
>
> LoadingResources/index.html on 10.1:
> "When you load a nib file, all its top level objects have a reference
> count of one. When the objects are no longer needed, another object
> needs to release them. That other object is usually the file's owner."
>
> Short answer: yes; long answer: many top-level objects do not have a
> referrence count of one after being loaded from a nib file, but they
> were all owned by an object that is irresponsible and therefore need
> to be released/autoreleased by another object.
>
>> What do they mean by top-level objects?
>
> Vince DeMarco answered this question:
>
>>> NSTopLevelObjects is basically what you see in the icon view in the
>>> IB Document, What the document contains (its hierarchy) can be seen
>>> by switching the document window in IB to outline mode
>
>> They obviously can't mean File's Owner and First Responder,
>
> Since FirstResponder is actually nil, you don't need to worry about
> its retain count. File's owner? No.
>
>> What about a naked NSView object that my code puts somewhere else in
>> the view hierarchy?
>
> Yes.
>
>> What about the Font Manager object?
>
> Good question. I could guess, but I've never actually checked and I
> don't know if it matters.
>
>> If I don't connect it to an outlet, do I still need to free it?
>
> Yes.
>
>> If so, how?
>
> You'll probably get lots of answer on this one. Its too late and I
> don't have anything useful to say.
>
>
Don't release the Font Manager, its a shared instance in the AppKit.
There is only one.
vince
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Monday, September 16, 2002, at 09:55 , Vince DeMarco wrote:
> Don't release the Font Manager, its a shared instance in the AppKit.
> There is only one.
Nevertheless, correct me please if I am wrong, but I believe that it
should (and easily could) be fixed by retaining ("overretaining") it when
a NIB is loaded, to comply with the general behaviour that all NIB
top-level objects are retained (or, more precisely, created and not
autoreleased).
I believe such a change would break no backward compatibility, since so
far nobody could release it lest the app do weird things; if you add the
retain, anyone would be able to consistently release all top-level objects
from a NIB as soon as it is needed no more, whilst the fact Font Manager
is actually a shared object would be encapsulated under the API level,
which I think is the right way to do such things.
---
Ondra Cada
OCSoftware: <ocs...> http://www.ocs.cz
private <ondra...> http://www.ocs.cz/oc
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
On Tuesday, September 17, 2002, at 04:44 AM, Ondra Cada wrote:
>
> On Monday, September 16, 2002, at 09:55 , Vince DeMarco wrote:
>
>> Don't release the Font Manager, its a shared instance in the AppKit.
>> There is only one.
>
> Nevertheless, correct me please if I am wrong, but I believe that it
> should (and easily could) be fixed by retaining ("overretaining") it
> when a NIB is loaded, to comply with the general behaviour that all
> NIB top-level objects are retained (or, more precisely, created and
> not autoreleased).
>
> I believe such a change would break no backward compatibility, since
> so far nobody could release it lest the app do weird things; if you
> add the retain, anyone would be able to consistently release all
> top-level objects from a NIB as soon as it is needed no more, whilst
> the fact Font Manager is actually a shared object would be
> encapsulated under the API level, which I think is the right way to do
> such things.
>
Yeah this would work fine too.
vince
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
I'm glad to see Ondra fighting to get Apple and others to recommend and
obey Apple's object ownership rules. I hope someone is listening. As for
me, I should not have suggested that it didn't matter if you release
NSFontManager; especially since some testing shows that it does matter.
For a practical example, I did this on both 10.1 and 10.2:
In PB, create new document based application
In IB, add an NSMenu and a "Font" menu item to "MyDocument.nib"
Build and run
Close initial window
Open new window
sharedFontManager returns nil (*) resulting in an exception:
Test[] *** -[NSCFArray addObject:]: attempt to insert nil
I demonstrated problems with NSFontManager in a discussion titled "Weird
problem with documents SOLVED" here:
http://cocoa.mamasam.com/COCOADEV/2002/07/1/39688.php
Basically, [[NSFontManager alloc] init] does not return an instance with
a retain count of +1 and NSWindowController happily releases all
top-level objects including a NSFontManager shared instance.
Ondra is right, I hope no one is surprised, Apple should not require us
to special case top-level objects that happen to be shared instances.
Code that obeys object ownership rules defined in Apple's documentation
should have no trouble getting released by NSWindowController.
(*) sharedFontManager returns nil because NSFontManager's dealloc method
sets it to nil (which it should do), but subsequent
init/sharedFontManager calls do not alloc/init a new instance.
-jim
> From: Ondra Cada <ocs...>_______________________________________________
>
>> From: Vince DeMarco <demarco...>
>>
>> Don't release the Font Manager, its a shared instance in the AppKit.
>> There is only one.
>
> Nevertheless, correct me please if I am wrong, but I believe that it
> should (and easily could) be fixed by retaining ("overretaining") it
> when a NIB is loaded, to comply with the general behaviour that all NIB
> top-level objects are retained (or, more precisely, created and not
> autoreleased).
>
> I believe such a change would break no backward compatibility, since so
> far nobody could release it lest the app do weird things; if you add
> the retain, anyone would be able to consistently release all top-level
> objects from a NIB as soon as it is needed no more, whilst the fact
> Font Manager is actually a shared object would be encapsulated under
> the API level, which I think is the right way to do such things.
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored. -
> From: Ondra Cada <ocs...>
>
> Nevertheless, correct me please if I am wrong, but I believe that it
> should (and easily could) be fixed by retaining ("overretaining") it
> when a NIB is loaded, to comply with the general behaviour that all NIB
> top-level objects are retained (or, more precisely, created and not
> autoreleased).
You are too kind, not retaining a shared instance during alloc/init is a
violation of object ownership rules. All top-level objects in a nib file
are owned by whoever loads that nib file and should be
released/autoreleased when they are done owning them.
-jim
_______________________________________________
cocoa-dev mailing list | <cocoa-dev...>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
