FROM : Hamish Allan
DATE : Tue Jun 17 23:26:44 2008
On Thu, May 8, 2008 at 8:02 PM, Sean McBride <<email_removed>> wrote:
> On 5/8/08 1:45 PM, Dave Dribin said:
>
>>On May 8, 2008, at 9:22 AM, Sean McBride wrote:
>>
>>> On 5/8/08 1:53 AM, Dave Dribin said:
>>>
>>>> For kicks, I did try "peopleController.selectionIndex" as well as
>>>> "peopleController.selectedObjects" to no avail.
>>>
>>> So it seems you have observed the same as I: that
>>> keyPathsForValuesAffectingValueForKey does not seem to work with key
>>> paths, despite the docs saying it should.
I recently tried to make a key dependent on NSArrayController's
selection and ran into the same problem as you did.
Having done some preliminary testing, I think this is yet another
manifestation of my old nemesis, the NSController old/new values bug:
http://www.cocoabuilder.com/archive/message/cocoa/2008/5/20/207407
That is to say, it's not key paths that are the problem; it's bindings
involving NSController subclasses, which always send nil for old and
new values, thereby breaking downstream dependencies.
However, since posting that last message , I have discovered the new
NSKeyValueChangeNotificationIsPriorKey option for addObserver:...
options which means that when using your first suggested workaround
you can at least send willChangeValueForKey: messages *before* the
change occurs
> Otherwise, I suggest you make a sample app and file a Radar. This is on
> my long and growing list of things to pester people about at WWDC. :)
Did you have any luck with that? I'd love to know straight from the
horse's mouth why on earth this bug (which really dulls the sheen of
bindings) still hasn't been fixed in two major revisions of the OS.
Hamish
DATE : Tue Jun 17 23:26:44 2008
On Thu, May 8, 2008 at 8:02 PM, Sean McBride <<email_removed>> wrote:
> On 5/8/08 1:45 PM, Dave Dribin said:
>
>>On May 8, 2008, at 9:22 AM, Sean McBride wrote:
>>
>>> On 5/8/08 1:53 AM, Dave Dribin said:
>>>
>>>> For kicks, I did try "peopleController.selectionIndex" as well as
>>>> "peopleController.selectedObjects" to no avail.
>>>
>>> So it seems you have observed the same as I: that
>>> keyPathsForValuesAffectingValueForKey does not seem to work with key
>>> paths, despite the docs saying it should.
I recently tried to make a key dependent on NSArrayController's
selection and ran into the same problem as you did.
Having done some preliminary testing, I think this is yet another
manifestation of my old nemesis, the NSController old/new values bug:
http://www.cocoabuilder.com/archive/message/cocoa/2008/5/20/207407
That is to say, it's not key paths that are the problem; it's bindings
involving NSController subclasses, which always send nil for old and
new values, thereby breaking downstream dependencies.
However, since posting that last message , I have discovered the new
NSKeyValueChangeNotificationIsPriorKey option for addObserver:...
options which means that when using your first suggested workaround
you can at least send willChangeValueForKey: messages *before* the
change occurs
> Otherwise, I suggest you make a sample app and file a Radar. This is on
> my long and growing list of things to pester people about at WWDC. :)
Did you have any luck with that? I'd love to know straight from the
horse's mouth why on earth this bug (which really dulls the sheen of
bindings) still hasn't been fixed in two major revisions of the OS.
Hamish
| Related mails | Author | Date |
|---|---|---|
| Dave Dribin | May 8, 01:16 | |
| Sean McBride | May 8, 01:58 | |
| Dave Dribin | May 8, 08:53 | |
| Sean McBride | May 8, 16:22 | |
| Dave Dribin | May 8, 20:45 | |
| Sean McBride | May 8, 21:02 | |
| Hamish Allan | Jun 17, 23:26 |






Cocoa mail archive

