Re: Bindings & Reverting Properties
Re: Bindings & Reverting Properties
- Subject: Re: Bindings & Reverting Properties
- From: Dave Keck <email@hidden>
- Date: Fri, 21 Aug 2009 21:06:37 -1000
> Someone has to say it: Why?! :-)
>
> I can't imagine any possible reason why any design should make it possible
> for prefs saving to fail. Just because I can't imagine it doesn't make it
> impossible, but it sounds very, very wrong.
Well it seems my attempt to over-simplify the situation has raised
more questions than answers. I should've expected that. =)
One of the special features of the preferences controller is that it
requires an AuthorizationRef to save the preferences. If the
authorization times-out, then I ask the user to re-authorize. If the
user clicks 'Cancel' in the authorization window, then the preferences
will fail to save because the authorization isn't valid. No amount of
checking can ensure that the authorization will be valid at precisely
the instant that I actually attempt to write the preferences file to a
privileged location; therefore, I need to be prepared to handle the
error.
> With respect, your entire approach is suspect. You might get a better
> answer if you explain your overall goal and why you feel the preferences
> system needs to be modified in this way to accomplish this goal.
Whenever something in the UI changes, MyPrefsController is sent a
-setValue: forKey: message. It overrides -setValue: forKey: to look
something like -setHappy: in my original email:
- (void)setValue: (id)newValue forKey: (NSString *)key
{
[self willChangeValueForKey: key]; // Need to manually trigger the
notifications because we're overriding setValue: forKey:
[newEntries setObject: newValue forKey: key]; // Set the property
in our internal dictionary...
[self didChangeValueForKey: key]; // Need to manually trigger the
notifications because we're overriding setValue: forKey:
if (![self save])
[self revert]; // The changes made here aren't reflected in
the UI despite the correct KVO notifications being sent.
}
Let's assume -setValue: forKey: is being called because the user
checked a checkbox in the UI (the checkbox went from being unchecked
to checked), and let's also assume that saving fails because the user
clicked 'Cancel' in the authorization window. These conditions lead to
MyPrefsController -revert'ing, which should lead to the checkbox in
the UI becoming unchecked again. The correct KVO notifications are
sent in -revert, but they still don't cause the checkbox to become
unchecked. If I schedule -revert to be called on the next iteration of
the run loop, it works. But because -revert is called from the
-setValue: forKey: that resulted from the checkbox becoming checked,
the UI ignores any changes to the property that would otherwise
trigger the UI to reflect the model property. And this is what I was
trying to show with -setHappy:.
Here's a better version of -setHappy: that shows my problem:
- (void)setHappy: (BOOL)newHappy
{
happy = newHappy;
[self willChangeValueForKey: @"happy"];
happy = NO;
[self didChangeValueForKey: @"happy"];
}
Imagine a checkbox is bound to the happy property. With a setter such
as the one above, I would expect that as soon as you try to check the
checkbox, it becomes unchecked. But that's not what happens - the
checkbox works like any other checkbox.
Does all that make sense?
Thanks,
David
_______________________________________________
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