Re: [CoreData] Undo of insert - how to close the removed object's window?
Re: [CoreData] Undo of insert - how to close the removed object's window?
- Subject: Re: [CoreData] Undo of insert - how to close the removed object's window?
- From: Kaspar Fischer <email@hidden>
- Date: Tue, 6 Dec 2005 18:46:16 +0100
Hi,
I have just found a solution to the problem and want to
share it, as it might be useful to others who want to
close a window when its associated object is removed.
As outlined in the original post, the problem is that
when I observe the change in the "books" array and close
the removed book's window using
[windowController close];
[self removeWindowController:windowController];
the window is not released but only autoreleased (which
means that it gets deallocated not immediately but only
at the end of the current event loop). Because of this,
the removed book has still active observers when CoreData
removes it. And this causes the crash (or, if you run your
executable with the option "-NSBindingDebugLevel 1", an
assertion failure "An instance 0x6252ec0 of class blabla
is being deallocated while key value observers are still
registered with it. Break on _NSKVODeallocateLog to
start debugging.")
I have found the following remedy. Instead of the
above two calls, I do
NSAutoreleasePool *subpool = [[NSAutoreleasePool alloc] init];
[wc close];
[self removeWindowController:wc];
[subpool release];
This causes the window to be released immediately, with
the side-effect of unregistering all observers and
bindings.
Regards,
Kaspar
P.S. Maybe one could also use a NSArrayController for the
windows of the books...?
On 15.11.2005, at 10:43, Kaspar Fischer wrote:
Hi all,
My CoreData document maintains a list of books (the
list is an attribute called "books") and each book may
have an associated window (displaying the book's details).
Now if I add a book, open its window, and perform undo,
I want (i) the book to be removed again (CoreData does
this automatically for me) and (ii) to have the window
closed.
I implemented this by observing the "books" attribute
of my "project" entity: whenever the "books" set changes,
I observe this and step through all windows, closing the
ones that have been removed.
This has one problem: although I remove the window,
it and its subviews are not immediately released (I guess
they are only autoreleased and will be deallocated at
the end of the event loop). As a conequence, my subviews
-dealloc methods are not called, and as these unbind
several bindings, I end up with a closed window that
still has active bindings in some subviews.
The result is that CoreData sends change notifications
to the controllers of these bindings -- and this of course
results in a crash because the bindings are still here,
but the book has already been removed!
I think this is a general pattern, and I would like
to ask if anybody has a solution for it? The pattern is:
in a model, some objects may have an associated window;
how can I make sure that the window gets closed if the
objects are removed due to undo/redo?
Very curious for solutions,
Kaspar
_______________________________________________
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