Many thanks for your replies, Adam and Quincey, much appreciated. By placing the methods in my model object rather than in my view object (I was kind of using the view as both view and controller), I now have both tables updating with objects getting inserted and edited. Great - thank you!
I'm still having other bindings woes here, though, all because I think I'm trying to wrap up too much in my view object. It might help if I explain what I'm trying to do a little better... My app has a source list with allows the user to view or edit different types of file. It can edit text files and view QT movies, web archives, PDF files and images. The main view can be split so that the same document (or different documents) can be viewed in each pane of the split view. All of this is straightforward (well, relatively), in that the PDF views, movies etc are not editable, so viewing them in two panes isn't a problem. Viewing and editing text in each pane isn't a problem either, given that the text system architecture means that two text views sharing the same text storage will automatically update to reflect edits made in the other. Now, I am trying to add a list view, comprising a table, some buttons beneath it for adding and removing items, and a colour well for changing the background colour of the list view itself. I want the list view to work like the text view, in that if it shares its underlying model (the DataList object in this case, which stores the background colour and the list array) with another list view, each will be updated accordingly. To this end, I have my list view owing the table controller in order to view the data list model. I know you generally separate them, but my thinking was to emulate the way a text view owns its layout manager unless built by hand (a text view created in IB owns its layout manager, but if you build up the architecture in code, the layout manager will be separate). I have a feeling I'm approaching this all wrong, given that now I'm trying to bind my DataList object's -backgroundColor to the view's backgroundColor so that changes to the background colour in one view will automatically update in the other, but this doesn't work at all (the model object's accessors never get called). So, I'd be grateful for general advice in how to approach the problem of having this custom view use the same data model in the set up I've described. I'm aware I sound like a complete idiot here, but honestly, I've been coding in Cocoa a few years, it's just that I've never need to get much deeper in bindings than a simple array/array controller relationship... Many thanks again for the advice and help - I appreciate it. All the best, Keith ----- Original Message ---- From: Adam P Jenkins <[EMAIL PROTECTED]> Of course it's true that the model objects shouldn't know anything about the view. My point was that if your model object implements proper Key-Value coding methods for the content property, then each controller can register as an observer of the model's content property to be notified when new content objects are added or removed, and respond appropriately, for instance by adding itself as an observer to the new content object. Maybe I'm wrong, but it seems to me that the problem is you're assuming that if you setup an observer for your DataList.content property, the observer will only be notified if the whole content array is replaced. However that's not the case: if DataList implements the proper indexed accessors, then the observer of the DataList.content property will also receive notifications of type NSKeyValueChangeInsertion, NSKeyValueChangeRemoval, or NSKeyValueChangeReplacement when items are inserted, removed, and replaced from the content array. So if I understand correctly, DataList is your model object, and it has an array property called "content". So assuming your DataList class implements indexed accessors for the content property, as described here: http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/AccessorConventions.html then you could subclass NSArrayController and in your subclass have code like this: DataList *dlist = somehow get hold of the DataList for this controller; [dlist addObserver:self forKeyPath:@"content" options:(NSKeyValueObservingOptionNew| NSKeyValueObservingOptionOld) context:NULL]; Multiple controllers can register as observers. Your controller would also need to implement observeValueForKeyPath:ofObject:change:context:, which would get called whenever the DataList's content property was changed, including having objects added or deleted from it. The observeValueForKeyPath:ofObject:change:context: method could then handle new objects being added by registering as an observer, and objects being deleted by unregistering as an observer. See Apple's Key-Value Observing Programming Guide for more details. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [EMAIL PROTECTED]
