Kyle: Thanks for your reply.
I have done some playing around and I am now a bit closer to being able to do this on my own. One more question: If I set my custom view to be an observer for employeesArray with the keyPath "selectedObjects", my custom view indeed does get an observeValueForKeyPath: message whenever the employeesArray selection changes. Observing "selectedObjects" like this is exactly what I should be using, right? Getting confirmation on that would be great. However, I also notice that if I do the following in the observeValueForKeyPath method: id newAttribute = [changeDict objectForKey:NSKeyValueChangeNewKey]; NSLog(@"%@", [newAttribute className]); what gets printed is, alas, NSNull! Is this the very same bug you spoke about? Getting confirmation on that as well will tell me that I understood your message properly. And yes, just to make it clear, I did set NSKeyValueObservingOptionNew when registering as the observer :) Getting these extra clarifications and info on whether I'm on the right path would help me alot. Thank you, U ---------------------------------------- > Date: Thu, 19 Mar 2009 14:39:17 -0400 > Subject: Re: Easy question about bindings for a custom view > From: kyle.slu...@gmail.com > To: ulaibee...@hotmail.com > CC: cocoa-dev@lists.apple.com > > 2009/3/19 Ulai Beekam : >> I want to create a custom view that displays (editable) text fields on the >> top of each other, as many as it takes, that display the *first names* of >> the currently selected items in employeesArray. So naturally, how many text >> fields are displayed depend on how many items in employeesArray are selected. > > Are you sure you don't just want to use an NSTableView, maybe with a > custom data cell? > >> My question is: How would I implement the 'value' binding for my custom >> view? Can you point me in the right direction? Should I use an >> NSMutableArray that updates on the fly as selection changes in the array >> controller? Or what? I'm a bit stuck. > > Follow the MVC pattern as exemplified by NSTableColumn: don't store > anything. Instead, use an NSTextFieldCell to draw the contents of > your view and handle editing. > > A note about implementing binding to collections (to-many relations): > make sure in your implementation of > -bind:toObject:withKeyPath:options: you register for KVO notifications > from every object in the collection. This means you will have to > un/rebind in -observeValueForKeyPath:ofObject:change:context:. Due to > a "why the hell have they not fixed this yet"-level bug in the > NSController classes[1], the change dictionary doesn't contain the > old/new values keys, which means you will need to iterate through the > new objects and compare them to the objects you're already observing, > removing yourself as an observer of the ones that are no longer there > and adding yourself as an observer of the new ones. > > [1] http://homepage.mac.com/mmalc/CocoaExamples/controllers.html#ibBindings > > --Kyle Sluder _________________________________________________________________ Show them the way! Add maps and directions to your party invites. http://www.microsoft.com/windows/windowslive/products/events.aspx_______________________________________________ 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
