How to de-register value observers

  • After struggling for many days, I was finally able to create a custom
    view that could support binding to a custom property.

    I am using this view in a window NIB and the window controller for
    that NIB is the object providing the value the view and other
    standard controls in the window bind to.  The window controller is
    the delegate for the window and it attempts to free itself when the
    window closes.

    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.

    I'm assuming this message indicates a problem with the implementation
    for my window controller class, and I would like to eliminate that
    problem.  What is needed to prevent this message from occurring?
  • On Aug 29, 2007, at 8:54 AM, Tron Thomas wrote:

    > 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.
    >
    > I'm assuming this message indicates a problem with the
    > implementation for my window controller class, and I would like to
    > eliminate that problem.  What is needed to prevent this message
    > from occurring?

    <file:///Developer/ADC%20Reference%20Library/documentation/Cocoa/
    Reference/Foundation/Protocols/NSKeyValueObserving_Protocol/Reference/
    Reference.html#//apple_ref/occ/instm/NSObject/
    removeObserver:forKeyPath:>

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • Nick Zitzmann wrote:
    >
    > On Aug 29, 2007, at 8:54 AM, Tron Thomas wrote:
    >
    >> 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.
    >>
    >> I'm assuming this message indicates a problem with the implementation
    >> for my window controller class, and I would like to eliminate that
    >> problem.  What is needed to prevent this message from occurring?
    >
    > <file:///Developer/ADC%20Reference%20Library/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueObserving_Protocol/Reference/Reference.html#//apple_ref/occ/instm/NSObject/removeObserver:forKeyPath:>
    >
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    removeObserver:forKeyPath: is the equivalent for
    addObserver:forKeyPath:options:context, which is call by the object that
    wants to observe the value.

    Since the observing object registers itself, it seems that the same
    object should de-register itself as well.  I'm not sure how every
    registered object is supposed to know that the window controller is
    deallocating itself so they can de-register themselves.

    If the window controller should de-register the observers instead.  I'm
    not sure how it is supposed to know about all its observers.  I can't
    find a method that will provide that kind of information.  It seems that
    the window controller would have to override
    addObserver:forKeyPath:options:context so it can perform the task of
    tracking the registered observers, even though the super class is doing
    that already.

    How is all this de-registration supposed to work?
  • On 8/29/07, Tron Thomas <tron.thomas...> wrote:
    > After struggling for many days, I was finally able to create a custom
    > view that could support binding to a custom property.
    >
    > I am using this view in a window NIB and the window controller for
    > that NIB is the object providing the value the view and other
    > standard controls in the window bind to.  The window controller is
    > the delegate for the window and it attempts to free itself when the
    > window closes.

    This window controller of yours...

    Is it a subclass of NSWindowController?
    Is it the owner of the nib?
    If not a subclass of NSWindowController do you related the top-level
    objects in the nib at some point?

    -Shawn
  • On Sep 3, 2007, at 12:29 PM, Tron Thomas wrote:

    > removeObserver:forKeyPath: is the equivalent for
    > addObserver:forKeyPath:options:context, which is call by the object
    > that wants to observe the value.
    >
    > Since the observing object registers itself, it seems that the same
    > object should de-register itself as well.  I'm not sure how every
    > registered object is supposed to know that the window controller is
    > deallocating itself so they can de-register themselves.

    The first thing I would try is using NSNotificationCenter...

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • Shawn Erickson wrote:
    > On 8/29/07, Tron Thomas <tron.thomas...> wrote:
    >
    >> After struggling for many days, I was finally able to create a custom
    >> view that could support binding to a custom property.
    >>
    >> I am using this view in a window NIB and the window controller for
    >> that NIB is the object providing the value the view and other
    >> standard controls in the window bind to.  The window controller is
    >> the delegate for the window and it attempts to free itself when the
    >> window closes.
    >>
    >
    > This window controller of yours...
    >
    > Is it a subclass of NSWindowController?
    > Is it the owner of the nib?
    > If not a subclass of NSWindowController do you related the top-level
    > objects in the nib at some point?
    >
    > -Shawn
    The class is a subclass of NSWindowController and it is the owner of the
    NIB.
  • Nick Zitzmann wrote:
    >
    > On Sep 3, 2007, at 12:29 PM, Tron Thomas wrote:
    >
    >> removeObserver:forKeyPath: is the equivalent for
    >> addObserver:forKeyPath:options:context, which is call by the object
    >> that wants to observe the value.
    >>
    >> Since the observing object registers itself, it seems that the same
    >> object should de-register itself as well.  I'm not sure how every
    >> registered object is supposed to know that the window controller is
    >> deallocating itself so they can de-register themselves.
    >
    > The first thing I would try is using NSNotificationCenter...
    >
    > Nick Zitzmann
    > <http://www.chronosnet.com/>
    I'm not exactly sure how you are suggesting that NSNotificationCenter
    would be used.

    One idea I have every object that registers for a binding the controller
    would also register for a notification.  Before the controller
    deallocates, it would post a notification informing all the observers
    they should de-register.

    I don't know if it is possible that the controller would attempt to
    deallocate before all the registered object has responded to the
    registered notification.

    Perhaps there is a different way you are suggesting that
    NSNotificationCenter would be used.
  • On Aug 29, 2007, at 7:54 AM, Tron Thomas wrote:

    > I am using this view in a window NIB and the window controller for
    > that NIB is the object providing the value the view and other
    > standard controls in the window bind to.  The window controller is
    > the delegate for the window and it attempts to free itself when the
    > window closes.

    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
  • Chris Hanson wrote:
    > 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.
previous month august 2007 next month
MTWTFSS
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Go to today