On Jun 27, 2012, at 22:12 , Jerry Krinock wrote:
>> On May 21, 2012, at 20:44 , Jerry Krinock wrote:
>
>>> -(void)setRating:(float)rating
>>> {
>>> // Stuff to make reverse binding work…
>>> NSDictionary* bindingsInfo = [self infoForBinding:@"rating"] ;
>>> id object = [bindingsInfo objectForKey:NSObservedObjectKey] ;
>>> NSString* bindingsPath = [bindingsInfo objectForKey:NSObservedKeyPathKey]
>>> ;
>>> [object setValue:[NSNumber numberWithFloat:rating]
>>> forKeyPath:bindingsPath] ;
>>>
>>> // Set ivar, needsDisplay
>>> …
>>> }
>
> But after I bound instead to a "multiFoo" class to make that work, I found
> that the extra setting of the data model was causing model values to be
> copied from one model object to the next when the I simply selected one model
> object and then changed the selection to a different model object.
Interesting stuff. :)
Looking back at this code, it seems that you probably always needed to separate
the two "directions" of value-changing. Since the model->view updates are
coming via KVO, the setter should only contain the second part ("Set ivar,
needsDisplay").
It seems to me this should prevent selection changes from rebounding onto the
data model.
> A better place for pushing the value to the data model is in the
> input-handling method of the view, -mouseDown: in the case of my star rating
> control. Moving the above code to -mouseDown: fixed the problem.
Using mouseDown kinda feels wrong to me. Wouldn't it make more sense to do the
first part of the existing code ("Stuff to make reverse binding work") in an
action method?
> - (IBAction) changeRating: (sender)
> {
> // Stuff to make reverse binding work…
> NSDictionary* bindingsInfo = [self infoForBinding:@"rating"] ;
> id object = [bindingsInfo objectForKey:NSObservedObjectKey] ;
> NSString* bindingsPath = [bindingsInfo
> objectForKey:NSObservedKeyPathKey] ;
> [object setValue:[sender objectValue] // since the ivar doesn't have
> the value yet
> forKeyPath:bindingsPath] ;
> // this value should now bounce back to the control via the setter,
> thus
> }
That way you're not dependent on *how* the control gets a new value.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
