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: Quincey Morris <email@hidden>
- Date: Wed, 20 Jan 2010 14:00:41 -0800
On Jan 20, 2010, at 06:06, Gwynne Raskind wrote:
> I created an NSObjectController at the top level of the nib, and connected its "content" outlet to the application delegate. I then created a second NSObjectController, and bound its "contentObject" binding to "selection.player" on the first controller. Repeat inwards until there are four controllers, one for each level of the above-described model objects. (This is not the natural configuration, but rather one of the variants I tried in the process of trying to make this work. The original configuration was a single object controller bound to the app delegate.)
>
> Finally, I bound several views' "value" bindings to the controller for the Info object, with the appropriate model keys for the Info class, one of which is the aptly-named "title" (not to be confused with Sir Not Appearing In This Film). The full key path for the NSTextField in question is "selection.player.track.info.title", where selection is the app delegate.
There really isn't a reason to continue using 4 object controllers. The exercise of trying 4 of them has *proven* that the "deep" key isn't the problem.
> 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.
_______________________________________________
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