Re: Problem using bindings with deep key paths
Re: Problem using bindings with deep key paths
- Subject: Re: Problem using bindings with deep key paths
- From: Gwynne Raskind <email@hidden>
- Date: Wed, 20 Jan 2010 17:37:53 -0500
On Jan 20, 2010, at 5:00 PM, Quincey Morris wrote:
>> It didn't work. The UI did not update with the values in the Info object for the given Track in the Player. I tried a couple dozen things, and finally found that the UI updated correctly when I generated a fake KVO notification for the "player" key in the application delegate.
>>
>> It seems to me that this means that the object controller(s) are not observing the changes made to the various sub-objects of the application delegate. In other words, given the key path "player.track.info.title", any change to any key along that path is ignored unless "player" is considered to have changed as well. I've verified that all the accessors are fully KVC and KVO compliant (most are synthesized properties), and I've tried a long list of combinations of flags on the controllers and individual bindings.
> It seems to me that you've *proven* that one of the properties along that key path is not being updated KVO compliantly, either in general or specifically in the series of initializations related to nib loading. The idea of suspecting the observers, while attractive in that it shifts the blame to Cocoa, is not supported by the proven robustness of the bindings implementation, so I'd put that thought way down your list. :)
>
> I'd suggest you try adding 4 user interface objects (for example, text fields bound to "player.description", "player.track.description", "player.track.info.description" and "player.track.info.title", as model keys of a single object controller) to find out which property is malfunctioning. That will suggest which piece of code to examine for KVO-uncompliance, or possibly for some other problem.
>
> Also, as usual, remember to check your console log for exception messages. KVC/KVO has an annoying habit of running *nearly* correctly after an exception, so it's easy to forget to check.
As usual, the blindingly obvious proves to be the problem. I had ensured perfect KVC/KVO compliance, and I was using the compliant accessors everywhere except for one place: the delegate's -awakeFromNib method where I create the Player object in the first place. I declared the property readwrite in the class extension and changed player = [[Player alloc] init] to self.player = [[[Player alloc] init] autorelease], and suddenly it all worked. (Though it vaguely annoys me that I have to add a spurious retain/autorelease to the Player object.)
Thanks for your help, Quincey; your suggestion of binding a series of text fields made the problem instantly obvious :).
-- Gwynne
_______________________________________________
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