NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
- Subject: NSApplication Quit bug; Another Form of it. Learning Cocoa sample shows related bug.
- From: email@hidden
- Date: Tue, 17 Jul 2001 13:43:57 -0700
Bug: objects reanimated out of main nib file are not dealloc'd --
their dealloc methods are never called.
In one case, there is an easy fix (and it applies to any window close,
not just Quit application). But this needs to get set and discussed in
next edition of Learning Cocoa because the default in IB has the
"release on close" checkbox for new windows created in IB (or at least
the first default window) unchecked.
Custom View in DotView sample in Learning Cocoa had dealloc method
that is never called when Window application is Quit. (ch. 8, page 136;
add a breakpoint or NSLog call in dealloc and see it's never called).
This can be fixed by choosing "release on close" in IB. Especially
since the sample indicates that it's important to include a dealloc
method to release dynamically allocated instance variables (color in
this sample).
But the more serious cases (without trivial work-around):
Instance 1:
The Learning Cocoa (1st ed) Delegate Sample in Ch. 8 (pp
139-145): the delegate for the window is NOT called with
windowShouldClose: when the File -> Quit menu item is chosen (but IS
called when either the close dot in the title bar of the window or the
File -> Close menu item in File menu are selected). Checking the
"release on close" checkbox in IB does NOT fix this. the
windowShouldClose method is not called when the Quit menu item is
choosen.
Instance 2:
The Learning Cocoa (1st ed) Notification sample in Ch. 8 (pp
148-149) makes the same assumption I did, though for a different
object: the MyController instantiated in the main nib file. In fact
they make a special note to indicate that implementing the dealloc
method for the controller is critical to preventing the
NSNotificationCenter from sending notifications to an object that no
long exists.
The Bug is that the controller instantiated in IB in the main nib file
does not have it's dealloc method called. And yet the sample indicates
that it's important for it to get called because it removes the observer
from the notification center.
Now, yes, we can all agree that the app is quitting and so it can't
really matter (in some sense); but if at some later date the
notification center sends an "app quitting" notification or something,
this lack of dealloc call will suddenly make the app crash.
Additionally, we can agree that one could, perhaps, implement a
-applicationShouldTerminate somewhere (delegate to app?) and that
perhaps that would work (iterate through windows and figure out the
"nice" way to close them that calls windowShouldClose first and respect
that response), but then we have to have the code for windowShouldClose
be placed in two locations (which is weak). But really, this should be
in NSApplication (the File -> Close menu handling is there), or in
whatever object/chunk of code reanimated the main nib file.
SO. Anyone from apple care to comment? I'm new enough at this cocoa
stuff that I'd like to get a confirmation before I bother to spend the
time to write it all up formal with sample code showing the problem and
sending it in... (plus then I'd have to figure out the most useful place
to send it...).
thanks,
Tyler
P.S. I'll hold off on the "for a supposedly mature class library, there
seem to be an awful lot of holes in the way it operates" rant, and
instead just ask that we focus and work together to get these problems
IDENTIFIED, CONFIRMED and FIXED. I don't want to lose customers
because the software feels flakey. And I don't want to have to code
around 100 weird class library/framework bugs in order to make it NOT
appear flakey.
SO, we need appropriate apple employee responses to these items
(confirming, clarifying etc), and we need fixes asap.