NSDocument subclass not dealloced after promising data - best way out this?
NSDocument subclass not dealloced after promising data - best way out this?
- Subject: NSDocument subclass not dealloced after promising data - best way out this?
- From: Keith Blount <email@hidden>
- Date: Sun, 5 Dec 2004 11:43:41 -0800 (PST)
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
Hello,
I have spent the past two days trying to find a tricky
bad access bug, and now that I've tracked it down I'm
not entirely sure what to do about it. I would be
grateful for any advice on how to fix it. This is the
setup:
1) In MyDocument's init method, I register as an
observer for several notifications.
2) In MyDocument's dealloc method, I unregister as an
observer
3) My document window contains an outline view.
Whenever the user starts a drag in the outline view
(in outlineView:writeItems:toPasteboard:), I declare
some types to the dragging pasteboard without actually
setting the data (otherwise the dragging becomes slow
and clunky). I have my pasteboard:provideDataForType:
method to deal with this if the data is requested.
So far, so good. But this setup is causing me crashes.
It seems that if I do any sort of drag operation in my
outline view, and then close the docoment window,
MyDocument does not get released. This means that
dealloc is never called, and consequently, MyDocument
is never unregistered as an observer. Thus, the closed
MyDocument may receive and act on a notification, and
its methods may try to access a view that *has* been
released when the window was closed - which results in
a crash.
The reason MyDocument is not released is because it
has promised to provide data to the pasteboard.
Does anybody know the best way of dealing with this?
I am thinking that I might just post some dummy data
to the pasteboard when I close the document window (as
it's drag and drop, the data has no meaning after a
drop has happened anyway), but even then, where would
I put the code? I would have thought I would override
close, but the docs say that this isn't always
called...
Many thanks for any advice,
Keith
Where
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden