Re: One Shot Windows: WARNING
Re: One Shot Windows: WARNING
- Subject: Re: One Shot Windows: WARNING
- From: Matt Neuburg <email@hidden>
- Date: Tue, 10 Feb 2009 10:18:56 -0800
- Thread-topic: One Shot Windows: WARNING
On Tue, 10 Feb 2009 11:12:17 -0500, Michael Ash <email@hidden>
said:
>On Tue, Feb 10, 2009 at 1:02 AM, Matt Neuburg <email@hidden> wrote:
>> Actually, having looked at your example, I reproduced the crash from the
>> bottom up by starting with the Document Architecture template.
>>
>> I created a window controller class, made it the Document nib's owner,
>> overrode makeWindowControllers, put a table view in the window, made the
>> nib's owner the table view's data source, and put code in the window
>> controller to populate the table. Sure enough, it worked fine, but when I
>> unchecked One Shot, it crashed if I closed the window with command-W.
>>
>> The crash doesn't happen if there is just an NSDocument; it has something to
>> do with the intermediate NSWindowController. m.
>
>The order of object destruction in a graph such as this is not well
>defined. You have no guarantees as to who will go first. As such,
>whenever you have a weak reference to an object, such as the
>dataSource outlet in a table view, you must explicitly break that weak
>reference in your -dealloc method. If you don't, the possibility
>exists that the table view will outlive your object *and* that it will
>try to message it after it has gone. This is likely to be the root of
>your problem here.
>
>The solution? Explicitly nil the table view's dataSource in your dealloc
method:
>
>- (void)dealloc {
> [tableView setDataSource:nil];
> [super dealloc];
>}
That doesn't work. Did you try it? (Seth did provide a link to the actual
example.) The problem is that nothing has been dealloced yet.
The way to contribute here is to download Seth's example, run it, and see
what you can do to prevent the crash without checking One Shot. I've tried
to prove to myself that there's something wrong with his setup but I haven't
managed it so far (that is why I recreated the crash starting with the stock
document app template).
When you close the window using command-W (though not when you close it by
clicking the close button), there is a chain of redraws (displayIfNeeded
down the view hierarchy) culminating in a call to
_dataSourceValueForColumn:row: which crashes. Although the crash does not
occur if there is no data (number of rows is zero), I have found no point at
which one can interfere to prevent the crash. For example, I tried
intercepting performClose: and throwing a switch that would set the number
of rows to zero, but the crash still occurs.
The only solution I have found so far is the same as Seth's - simply to make
sure the window is One Shot. Believe me, I struggled against this; I spent
all evening yesterday trying to prove him wrong. I failed.
The following points seem to me particularly noteworthy:
(1) The template, as Seth points out, has One Shot checked. All the examples
of document architecture apps that I can find at Apple's site have One Shot
checked.
(2) The documentation says nothing about this. This is the part that Seth
seems to regard as scandalous (and one can't help agreeing). The
documentation is unanimous in stating that One Shot has something to do with
the window object being deleted when the window is hidden or miniaturized.
It says nothing about what happens when the window is closed, and it
certainly does not pick out closure with command-W as being different from
closure by clicking the close button.
(3) If you rewrite the example for Tiger only (I'm using Xcode 2.4 on my old
Tiger machine running 10.4.11) there's no problem; unchecking One Shot does
not cause the same crash.
All of that makes me wonder whether Seth has not uncovered a Leopard bug.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.tidbits.com/matt/default.html#applescriptthings
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden