Thankyou both for your advice - it's good to have you set me right on that one. Fortunately mine is a relatively uncomplicated case, and so [NSArrayController add/removeObject:] should do the job nicely
It feels a bit odd doing it that way, just because it makes the NSArray almost redundant in the whole thing - it's declared as a backing store, but this way I don't actually end up accessing it for anything. There's a rather long and redundant-seeming chain running from NSArray instance variable -> property -> binding -> NSArrayController -> IBOutlet -> instance variable that I actually manipulate. Oh well, if that's the way it's meant to be... On 23 Sep 2014, at 19:57, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > On Sep 23, 2014, at 11:36 , Lee Ann Rucker <lruc...@vmware.com> wrote: > >> On Sep 23, 2014, at 9:15 AM, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk> >> wrote: >>> >>> [*] One slight glitch - if I add an object to the NSMutableArray then it >>> does not immediately show up in the table, I have to call >>> will/didChangeValueForKey on the property that returns the array. I don’t >>> know if that is expected behaviour (maybe I should be adding via the array >>> controller somehow?). This is not a problem, but I mention it for >>> completeness, just in case it’s indicative of something funny that is going >>> on that I don’t fully appreciate. >> >> Yes, it’s complicated. The ArrayController doesn’t know about changes that >> are made directly to the NSMutableArray. You can use [NSArrayController >> addObject:] for simple cases, or spend a lot of time with the KVC >> programming guide, especially “Collection accessor patterns for to-many >> properties”. > > In fact, Lee Ann is being a little bit kind here, because Jonny really is > Doing It Wrong™. > > Because the UI is using bindings, it is *necessary* to update the array > KVO-compliantly. Simply adding objects to the NSMutableArray isn’t > KVO-compliant, hence the lack of automatic updating of the UI. > > The underlying problem is in thinking of the data (that is, the “M” in MVC) > as an array instead of a indexed to-many property. When you make that > conceptual change, then, yes, you end up in a deep relationship with the KVC > programming guide. > > There is** a quick and dirty way of fixing this, though, without cracking > open any programming guides. Anywhere that you update the NSMutableArray > (either by referencing its instance variable “myArray” or “_myArray”, or a > property “someObject.myArray" that provides access to that instance > variable), you can use a mutable proxy instead. For example, in the class > that has the array, instead of: > > [_myArray addObject: something]; > > or: > > [self.myArray addObject: something]; > > you would write: > > [[self mutableArrayValueForKey: @“myArray”] addObject: something]; > > and you should magically see the updates start working. But the KVC > programming guide is a better bet for a long-term relationship. > > > ** Subject to the proviso that I’m just writing this, not doing it ATM, so I > may have missed something. > _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
