Are you establishing the binding in Interface Builder or in code?
If you're establishing the binding in code by sending your custom view
-bind:... in your NSWindowController subclass, best practice would be
to send your custom view -unbind:... in "the opposite" method in your
NSWindowController subclass.
For example, if you're setting up the binding in an override of the
-[NSWindowController windowDidLoad] or -[NSWindowController
awakeFromNib] method, it would be a good idea to tear down the binding
in an override of the -[NSWindowController close] method. This way
your uses of -bind:... and -unbind:... will be balanced.
I find that when I close the window, I get the following message in
the debugger:
An instance 0x30fda0 of class <My Window Controller Class> is being
deallocated while key value observers are still registered with it.
Break on _NSKVODeallocateLog to start debugging.
One other thing you could do if you know the bound-to object will go
away when the window closes is register your custom view for the
appropriate NSWindow notification, and when the notification is
posted, unbind your custom binding. After all, you're not "re-using"
this view anyway, so you don't need to worry about re-establishing the
binding again later; you're just going to load the nib anew creating a
different view object with its own instance of the custom binding.
-- Chris
I am establishing the binding in Interface Builder.
_______________________________________________
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
