So in the case of insertion to m_array, we just have to reset content
property:
// somewhere in the code
[self willChangeValueForKey: @"content"];
[m_array insertObject: url atIndex: 0];
[self didChangeValueForKey: @"content"];
// in the -observeValue...
[controller setContent: m_array];
well?
2011/9/27 Quincey Morris <quinceymor...@rivergatesoftware.com>
> On Sep 27, 2011, at 12:18 , Ariel Feinerman wrote:
>
> So it is good news. Do -insertObject: atIndex:, -removeObject: or
> removeObjects: use KVO? I guess they do.
>
>
> If you use these methods, you don't have to write any manual
> synchronization code. Your original array will contain the modified
> contents.
>
> However, in your case ('setContent: m_array'), KVO isn't involved. Kyle
> sent me the following message off-list. I don't think he'll mind if I post
> it here, since the information reflects badly on me, not on him.
>
> On Sep 27, 2011, at 10:47 , Kyle Sluder wrote:
>
> You cannot KVO-observe an NSArray. -[NSArray
> addObserver:forKeyPath:options:context:] is implemented to throw an
> exception.
>
>
> Well, I thought I'd run out of stupid things to say about
> NSArrayController, but apparently I can still confuse myself.
>
> As Kyle suggests, when you 'setContent:' on an array controller, it cannot
> observe the array because KVO doesn't allow it, and, there just isn't a way
> to update the array itself KVO compliantly. Under those circumstances, using
> the NSArrayController methods ('addObject…', 'removeObject…',
> 'insertObject…') will update the array properly, but updating the array
> directly won't cause the array controller to notice.
>
> Oddly, when I wrote some code to check out a couple of details, I found
> that:
>
> -- when the array controller is *bound* to its content array, its 'remove:'
> method works fine
>
> sorry for the question, hm I slightly don't understand in cocoa bindings so
how to bound the controller to its content array?
> -- when the array controller's "content" property is merely set to the
> content array, 'remove:' does nothing
>
> In the second case, I had a document object with an IBOutlet to the array
> controller, and I set it up with [arrayController setContent: theArray].
> When my deletion button action method looked like this:
>
> - (IBAction) deleteIt: (id) sender {
> [arrayController remove: sender];
> }
>
> nothing got deleted. (And, yes, I let the app go back to the main event
> loop before checking.)
>
> When my deletion action method looked like this:
>
> - (IBAction) deleteIt: (id) sender {
> [arrayController removeObjects: [arrayController selectedObjects]];
> }
>
> the deletion worked fine. That's in spite of the fact that 'remove:' is
> documented to do what the second version does, though deferred to the next
> iteration of the run loop.
>
> Maybe I made a stupid mistake, but it's a bit puzzling.
>
>
>
--
best regards
Ariel
_______________________________________________
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
