The KVC infrastructure did not always generate value-changed
notifications for setValue:forUndefinedKey: overrides.
The setValue:forUndefinedKey: override should have nothing to do
with it. It's the setValue:forKey: call -- the one which provokes
the call to setValue:forUndefinedKey: --
On Aug 8, 2009, at 6:24 PM, Gabriele de Simone wrote:
On Aug 8, 2009, at 2:37 PM, Keary Suska wrote:
It used to be that if you overrode -[NSObject
setValue:forUndefinedKey:] your own subclass was responsible for
calling -[NSObject will/didChangeValueForKey: so that bindings and
observers would
On Aug 8, 2009, at 2:37 PM, Keary Suska wrote:
It used to be that if you overrode -[NSObject
setValue:forUndefinedKey:] your own subclass was responsible for
calling -[NSObject will/didChangeValueForKey: so that bindings and
observers would work as expected.
That was fine, since it allowed one
On Aug 7, 2009, at 12:50 PM, Gabriele de Simone wrote:
It used to be that if you overrode -[NSObject
setValue:forUndefinedKey:] your own subclass was responsible for
calling -[NSObject will/didChangeValueForKey: so that bindings and
observers would work as expected.
That was fine, since
It used to be that if you overrode -[NSObject
setValue:forUndefinedKey:] your own subclass was responsible for
calling -[NSObject will/didChangeValueForKey: so that bindings and
observers would work as expected.
That was fine, since it allowed one to provide different
implementations depe
