Is willChangeValueForKey: always needed?
Is willChangeValueForKey: always needed?
- Subject: Is willChangeValueForKey: always needed?
- From: David Catmull <email@hidden>
- Date: Thu, 16 Nov 2006 16:22:24 -0800
Does didChangeValueForKey: always have to be preceded by a call to
willChangeValueForKey:?
I have a case where the value in question is calculated based on
other values (which tab is selected, and whether a certain text field
has text), and the key is simply the name of the method that
calculates the value. So when one of those other values changes, it's
too late to say that the calculated value "will" change.
I'm wondering about this because I have a situation where my bindings
don't seem to be updating immediately, causing a unit test to fail.
- The unit test calls setValue:forKeyPath: on an NSObjectController
used to store the settings for my window's controls
- My window controller object is observing that keypath, and in
response it calls will/didChangeValueForKey:@"canGo"
- The "Go" button's enabled property is bound to the window
controller's canGo key
- The unit test calls [goButton isEnabled] and unexpectedly gets NO
- The unit test calls [controller canGo] and gets YES as expected
I thought perhaps willChangeValueForKey: might be caching the "old"
value to see if it really does change, but the canGo method doesn't
seem to get called there.
The user experience that this test is trying to simulate does in fact
work correctly - when you type something into the text field and the
correct tab is active, the button becomes enabled.
--
David Catmull
email@hidden
http://www.uncommonplace.com/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden