Re: Custom binding problem...can't figure out how to trigger a notification on set

  • Thanks. This got me just about there. (Turns out I needed to save the
    keypath too and call setValue:forKeyPath). I'm wondering what the best
    strategy is for avoiding infinite recursion is. When I call
    setValueForKeyPath inside my setter, it triggers another set
    notification which causes the setter to be called again (and again).

    For simple values, I could check for equality and escape if there is
    no change, but for NSColor, I think the fact that I have conversions
    to usable color spaces in my code is making the equality comparisons
    fail.

    Thanks,
    Eric

    On 10/2/06, Mike Abdullah <mike.abdullah...> wrote:
    > Well as far as my understanding of your situation is, you really
    > ought to do something like this:
    >
    > In the bind: method of your view, make a note of the object you're
    > bound to.
    >
    > When the background colour needs to be set by the view itself, have a
    > look and see if you're bound to anything.  If not, simply set the
    > background color.  If you are bound to something, ask that object to
    > setValueForKey:
    >
    > Mike.
    >
    > On 2 Oct 2006, at 19:16, E. Wing wrote:
    >
    >> Sorry for the confusion. So what I'm after is the ability to make
    >> changes internal to my view subclass, but still some how notifiy a
    >> bound controller (if it exists) that I made these changes so anything
    >> that is bound to my view will know something has changed and will stay
    >> in sync (such as the NSColorWell).
    >>
    >> So some examples of why I want this:
    >> - On creation of my view class, I may internally set a default color
    >> (such as green), but how do I get the bound color well to start at
    >> green (it starts at black currently and not green).
    >>
    >> - My custom view may handle events and I may want to do something
    >> like this:
    >> - (void) mouseDown:(NSEvent*)the_event
    >> {
    >> [self setBackgroundColor:[NSColor blueColor]];
    >> }
    >>
    >> Since the event is defined in the view subclass, how do I notify the
    >> controller about this change?
    >> (Maybe this is somewhat analogous to the NSTableView in how its
    >> mouseDown can change the current selected item and other bound things
    >> will notice the change event?)
    >>
    >> - Somewhat hypothetical, but maybe my view class has a private NSTimer
    >> that fires off periodically and decides to change the color (perhaps
    >> to reflect the time of day, or perhaps I'm just doing color
    >> animation). Again, I would like to set a new color like in the
    >> mouseDown example, but how do I get the NSColorWell to keep up?
    >>
    >> Thanks,
    >> Eric
    >>
  • On Oct 3, 2006, at 2:46 PM, E. Wing wrote:

    > Thanks. This got me just about there. (Turns out I needed to save the
    > keypath too and call setValue:forKeyPath). I'm wondering what the best
    > strategy is for avoiding infinite recursion is. When I call
    > setValueForKeyPath inside my setter, it triggers another set
    > notification which causes the setter to be called again (and again).
    >
    This is illustrated in the Joystick example:

    <http://developer.apple.com/samplecode/BindingsJoystick/>

    and discussed in general terms in:

    <http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaBindings/Con
    cepts/HowDoBindingsWork.html
    >

    If a user interacts with a bound view, the view updates the object to
    which it is bound using KVC (in the example, in updateForMouseEvent:).

    If the model object is updated, it informs the view "indirectly" using
    KVO.  In its 'observeValueForKeyPath:...' method, the view updates
    itself but does *not* update the object to which it is bound (the
    view's setter methods should not update the object to which is it
    bound (in the example, see setAngle: and setOffset:, contrast with
    observeValueForKeyPath:...).

    Thus although there may be one update refresh cycle, it should not
    cause an infinite loop.

    mmalc
previous month october 2006 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