Forcing a refresh on a bound control

[Christiaan Hofman]

On 18 May 2008, at 12:34 PM, Clark Cox wrote:

> On Sun, May 18, 2008 at 3:20 AM, Christiaan Hofman  
> <cmhofman at gmail.com> wrote:
>>
>> On 18 May 2008, at 8:18 AM, mmalc Crawford wrote:
>>
>>>
>>> On May 15, 2008, at 2:35 PM, Christiaan Hofman wrote:
>>>
>>>> You can force a KVO notification by sending a will/ 
>>>> didChangeValueForKey:
>>>> pair of messages.
>>>>
>>> As has been said on numerous occasions, no, don't do this.
>>>
>>
>> I know it has been said. But I have never heard an alternative to  
>> forcing a
>> KVO change notification.
>
> IME, needing to "force" KVO notifications is a sign that my design is
> deficient.
>

That may be in some cases. But I have run into several situation where  
I could not change the design. E.g. when changes happen in code I  
don't control. Or when you want to force an update after a  
notification (in the sense of NSNotification) that is not necessarily  
associated to a change of an KVO observable property.

>> Given that dependent keys can only be set for the
>> same object...
>
> FYI, while true for 10.4, this is no longer the case with 10.5. Check
> out the +keyPathsForValuesAffectingValueForKey: method (and pay close
> attention to the fact that the returned set contains key *paths* not
> just keys).
>
> <http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueObserving_Protocol/Reference/Reference.html 
> >
>

Which is of course irrelevant if you're developing a Tiger compatible  
app (as I'm doing).

Christiaan

>> And if you would think there may be an alternative in this
>> particular situation (though I don't see it), I am talking about  
>> the general
>> situation. Please proof me wrong, but I couldn't find it.
>
> One can use KVO directly. As Malcom mentioned, one can have an object
> observe whatever value the check box is bound to, and then, when a
> change is registered, that object can set/change the appropriate value
> in the model that is backing the text view.
>
> -- 
> Clark S. Cox III
> clarkcox3 at gmail.com