Re: Window-closing sequence in a Document-based App
Re: Window-closing sequence in a Document-based App
- Subject: Re: Window-closing sequence in a Document-based App
- From: Carlos Weber <email@hidden>
- Date: Thu, 24 Jan 2002 10:45:07 -1000
On Thursday, January 24, 2002, at 07:40 , Andrea Perego wrote:
>
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.
A trap I have fallen into is forgetting that many delegate methods take
a NSNotification * argument. Thus, the "windowWillClose" method is
actually
- (void)windowWillClose:(NSNotification *)aNotification
If you are implementing a -windowWillClose method (no arguments), you
are actually creating a new method, which nobody knows how to call.
(I don't know if this is your problem at all, but it passed thru my mind
reading your post.)