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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
