Window-closing sequence in a Document-based App
Window-closing sequence in a Document-based App
- Subject: Window-closing sequence in a Document-based App
- From: Andrea Perego <email@hidden>
- Date: Thu, 24 Jan 2002 18:40:54 +0100
Hi!
As a punishment for my hubris in starting my cocoa-programming
activity with a rather large project, I experience every now and then
some puzzling behavior, puzzling at least for my scarce experience.
This time, my concern is about the sequence of messages that go on
whenever a window is closed in a document-based app. In Apple's docs
(Overview of Programming Topic: Document-Based Applications) one
reads:
* When the last window of a document is closed, the document is
also closed. The window, window controller, and document are all
released.
I'd guess that the closing sequence is window -> windowcontroller -> document.
My problem arose from the fact that I wished to call from my
NSWindowController subclass a method of my subclass of NSDocument
within the "dealloc" method of the former class:
..... subclass of NSWindowController ....
-(void)dealloc
{
[[self document] doSomeThing];
....
}
I discovered almost immediately that nothing was performed, since the
"document" instance variable of my controller was =nil at that time.
[BTW, on the recent thread about whether it is possible to send
messages to nil: this is a case in which one would perhaps prefer
some more "resented" reaction by the run-time]. Then, I figured I
could move the call into the "windowWillClose" delegate method, since
my window controller acts as window's delegate, but I had no luck,
either. After peppering my methods with "NSLog", I was able to trace
the actual sequence:
2002-01-24 17:25:57.649 testspectra1[788] setDocument called with doc=(null)
2002-01-24 17:25:57.649 testspectra1[788] windowWillClose
2002-01-24 17:25:57.661 testspectra1[788] Myspectradocument deallocated
2002-01-24 17:25:57.661 testspectra1[788] mywindowcontroller deallocated
(Please, forgive the sloppy capitalization: it's done just in the
NSLog's output, not in the code itself).
From this log, one concludes that the first sign a
NSWindowController's subclass receives that it's about to die is just
having its "setDocument" method called with document=nil. Even the
delegate message "windowWillClose" comes later.
Another "strange" thing is the fact that the NSDocument's subclass
gets deallocated before the window controller. Looking at the stack
frame with gdb
revealed that a mysterious "_windowWillClose" message (note the "_")
is sent to the window controller before "setDocument", but this
should be, AFAIK, a private method not to be relied upon (even if it
were possible to do it).
This behavior is no real problem for me, since I can re-code the
thing and avoid calling a method of the document controller, but I'm
posting it as a warning to fellow newbies and to pose a couple of
questions to the more experienced developers:
- is there some earlier warning for a windowcontroller that its
window is about to close, than [controller setDocument:nil]?
- must one deduce as a general rule that a windowcontroller shouldn't
call methods of its "NSDocument" subclass?
TIA
Andrea Perego
University of Florence - Phys. Dept.