Re: Delegate methods[SOLVED]
Re: Delegate methods[SOLVED]
- Subject: Re: Delegate methods[SOLVED]
- From: Neil Earnshaw <email@hidden>
- Date: Wed, 20 Aug 2003 14:20:28 +0100
It's a nasty newbie gotcha.
NSWindow provides many delegate methods. Some of them are invoked by
sending a message directly to the delegate, perhaps like this:
BOOL shouldClose = YES;
if ( _delegate && [_delegate
respondsToSelector:@selector(windowShouldClose:)] ) {
shouldClose = [_delegate windowShouldClose:self];
}
Others seem to be managed by the window adding the delegate as an
observer. The delegate doesn't know that it has been made an observer
and the documentation doesn't explicitly say,
"If the delegate implements windowWillClose: then the window will
register the delegate with the default notification center to receive
NSWindowWillCloseNotification's. If the delegate executes
removeObserver:self outside its dealloc method then it will not be
notified when the window closes."
The current documentation's fine for Cocoa/NextStep gurus who've
internalized all these subtle nuances of the architecture, but us
newbies have to find out the _really_ hard way.
Another note for newbies: The documentation for notifications clearly
states that the observer is not retained. Unfortunately, it doesn't
point out that the observed object _is_. So, if you have any cyclic
notification chains it is _not_ sufficient to removeObserver:self in
your dealloc method because dealloc will never get called. Instead,
one of the objects in the circle must removeObserver:self outside the
dealloc method. Once the chain has been broken, then the whole lot
will get cleaned up (as long as dealloc removes the object from the
notification center).
Message to Apple: In four months of learning to build Cocoa
applications, _nothing_ has caused as many problems as notifications.
The problems are not with the notification mechanism itself, but with
the subtle dependencies they introduce. Mac OS X is new to Apple
developers. That means there are lots of newbies out there. Revising
the documentation with them in mind will help turn them towards the
Mac, not away from it.
-Neil
On Tuesday, August 19, 2003, at 10:02 PM, Neil Earnshaw wrote:
When you make a subclass of NSWindowController the delegate of an
NSWindow it becomes eligible for windowWillClose. Is the notification
mechanism involved in the receipt of windowWillClose?
I don't think it is, but under some conditions my window controller
doesn't get the windowWillClose call when I click the little red
button. The window does go away, but later when I close the
application it pops back up again and asks me if I want to save. When
I select no it really does get released. The reason I suspect that
the notification mechanism is playing a part in this is that when I
comment out [nc removeObserver:self] in the window controller, the
window really does release all its resources the first time I try to
close it.
Is there some other way in which the window can decide not to call the
delegate's windowWillClose method (other than setting the window's
delegate to nil)?
Neil Earnshaw
Consultant Software Engineer
Object Software Engineers Ltd
email@hidden
Tel : 01747 854 852
Mbl : 07870 209 102
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
Neil Earnshaw
Consultant Software Engineer
Object Software Engineers Ltd
neil @ ose-ltd.com
Tel : 01747 854 852
Mbl : 07870 209 102
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.