Re: Bindings & Reverting Properties
Re: Bindings & Reverting Properties
- Subject: Re: Bindings & Reverting Properties
- From: Quincey Morris <email@hidden>
- Date: Sat, 22 Aug 2009 01:00:34 -0700
On Aug 22, 2009, at 00:14, Dave Keck wrote:
What led you to believe you needed to call the setter recursively?
All you
need is:
The only reason I did that was to show that the correct KVO
notifications would be invoked by reverting the happy property from
within the setter. It was a gross oversimplification, and I'm sorry.
:)
I realize that KVO notifications are sent automatically, and
implicitly surround the -setHappy: setter. But to illustrate my point,
I used the setter from within the setter to show that even with two
more (implicit) -willChange/-didChange notifications, the UI does not
reflect the model property if the model property is 'reverted' from
within the setter.
I think you missed my point. Well, points.
First, within the setter, willChange/didChange have no effect, whether
invoked explicitly or implicitly. (Actually, they may have an effect,
but not the correct effect. Attempting to nest willChange/didChange is
a Bad Idea because KVO notifications aren't nestable.)
Second, there's no need. The KVO mechanism in no way depends on the
value of the property, on exit from the setter, being the value passed
into the setter. If you change then revert the underlying value (the
instance variable) in the setter, the reverted value is the one that
will be contained in the KVO notification as the "new" value. So you
don't need to trigger any *additional* KVO notifications, because the
one you get for free is enough.
You gave this example:
- (void)setHappy: (BOOL)newHappy
{
happy = newHappy;
[self willChangeValueForKey: @"happy"];
happy = NO;
[self didChangeValueForKey: @"happy"];
}
The immediate problem here is the presence of willChange/didChange. If
you change it to:
- (void)setHappy: (BOOL)newHappy
{
happy = NO;
}
and a checkbox bound to it doesn't stay unchecked, then the real
problem is elsewhere.
_______________________________________________
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
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden