Changing indexes of TableView suddenly gives uncaught CPRangeException

[rvanzon]

Today I updated my Cappuccino install. And suddenly the next error:

Frameworks/Debug/Foundation/CPException.j:51 Uncaught CPRangeException: -[_CPObservableArray objectAtIndex:]: index (1) beyond bounds (1)

When I change the items in a View-based CPTableView or when I reload the data. The error is not appearing on every item, but I can't find out any difference. The value of the table columns are bound to an arraycontroller,

The project is pretty big, so hard to isolate the problem. It never happened before, so I think the problem is in the Cappuccino-code. Does it maybe has to do with the memory leak or enumeration of rows fixes?

I have the idea this error occurs when the items of the arraycontroller change. It really breaks the complete app.

I included the stack trace.

Any idea?

Update:
I created a simple example: http://cl.ly/122v0M1O361U

[cappbot]

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

[rvanzon]

I think the problem could lay here:
f9ce1d1#diff-aa0563e0c33eefcca2ffbfcd64535ff0L553

[rvanzon]

Ok, I investigated it a bit more. My situation: I have an ArrayController which binds the Content Array to the items-array of the fileowner. The tablecolumn binds Value to the ArrayController with Controller Key "arrangedObjects" and no Model Key Path. The Text Field which is member of the Table Cell View binds it's value the Table Cell View with Model Key Path "objectValue.name".

When reloading the data I set the items to nil after receiving data. Then I make an array of new data. The error occurs when the items are set to nil.

[cacaodev]

i've tried your example and deleted the [self setItems:nil] call . The rows seem to be correctly updated when I hit the reload button.

Can you explain, in your server-client situation, why you needed to set the model to nil, and what do you expect, and why do you think it is a bug (cocoa test welcome).

[rvanzon]

Yes, without setting to nil it works. But sometimes there are no results. So I clear the results and then get new results.

I must say, this always worked. And also I think it should work. Also [[self items] removeAllObjects] gives the error. This means everything only works while there are items.

The bad thing, my app is completely broken now, because on several places empty items lists occur.

[rvanzon]

update: if you replace setting items to nil into [[arrayController content] removeAllObjects]; and attach the arrayController in the Xib to arraycontroller. The same error appears only it occurs at the 10th item:

-[_CPObservableArray objectAtIndex:]: index (10) beyond bounds (10)

It looks like the CPArrayController doesn't 'know' the items are cleared and just tries acces it rows which are not there anymore.

[rvanzon]

ok, a workaround (and probably a better way anyway) is to use [arrayController setContent:newData];
}, where newData is local initialised, instead of cleaning items first.

The above seemed to work, but if there are no items, the error occurs.

I really think every app that uses CPArrayControllers and updates it's content with an empty list are broken now....

[cacaodev]

@rvanzon : When you want to change something in the model, the official way is to act directly on the collection holding the data, not the CPArrayController. But you need to do it in a indexed KVO way in order to inform the controller of your changes.
Maybe you could switch to the mailing list because I am not sure this is a bug.

[rvanzon]

@cacaodev Ok, will do that. But I am sure it's a bug, because manipulating the data is exactly the problem. Also, this never happened before and in Cocoa I use the exact same method.

[toddfreese]

I am seeing the exact same thing after updating from master as well.

[cacaodev]

Found the problem. If you bind the table content binding to arrangedObjects, instead of binding the column value, it should work without error.

I agree this could be considered as a bug because a) it worked before and b) it works in cocoa. But with view-based table views, we are supposed to use the content binding. That's what the cocoa doc says even if they don't explicitely state it won't work with the column binding.

In my opinion we should depreciate column binding in view-based tables because it doesn't really make sense (views are identified by their identifier, not the column), or when this is fixed warn about the recommended usage.

@toddfreese do you also have a view-based table with column value binding ?

[toddfreese]

I will have to look. I started noticing it in CUP.

[cacaodev]

This should fix the bug. Thanks for reporting it.

[rvanzon]

@cacaodev It works again. Thanks for fixing! :)