Re: Remove action on NSArrayController bound to table causes index beyond bounds
On Mar 24, 2009, at 01:56, Luke Evans wrote: Mmm... well, I'm coming around to the idea that something about my model might be getting screwed before the index out of range exceptions (though these still happen under the specific conditions noted). The "boundary condition" you referred to in your original post was deletion of a row that caused the vertical scrollbar to autohide. I've noticed in the past that this autohiding can trigger a surprisingly unintuitive sequence of method calls (because, basically, the view resizing associated with the autohiding comes in the middle of whatever else is going on). It would be worth changing your scroll view to *not* autohide its scroll bars and see if you can recreate the crash. (Prediction: it won't crash.) Unfortunately, that won't tell you whether the problem is in the frameworks or your code, but might help narrow down the possibilities. ___ 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
Re: Remove action on NSArrayController bound to table causes index beyond bounds
Mmm... well, I'm coming around to the idea that something about my model might be getting screwed before the index out of range exceptions (though these still happen under the specific conditions noted). However, I can reproduce the Core Data fault error when the managed objects in the table have no relationships to others (i.e. I don't create any of the possible relationship objects). So, I'm just adding and deleting 'root' objects that happen to be represented by a row, with no other objects attached (those relationships are properly set up w.r.t. deletion, but there shouldn't be any references there to 'dangle' as dodgy faults even if this wasn't the case). There are a couple of places that make reference to the managed objects that are bound to the rows, so its possible that the "remove:" on the array controller is causing Core Data to do some deletion of the managed object, but it is still referenced from a few places temporarily (for instance I have an "anchor selection" concept in a 'selection coordinator' that maintains a notion of the single selected object in the entire app that will appear in an 'inspector'). I can't think why this would cause a problem, and I'm in a pure GC environment w.r.t. those references). The core data faulting error definitely seems to occur when the model is saved. The only slightly odd thing I can conceive of (at the moment) is an undo group bracketing the remove: and a 'completion' method that occurs soon after the remove: as a delayed message from the run loop. This is so I can give an undo name to the removal operation without two undo registrations (one when remove: is called) and one when the actual work happens on another run loop cycle (as documented for the remove: action on NSArrayController). This seems to work, and I don't believe undo groupings should have any effect on the actual model operations - but could the grouping affect some aspect of the 'deletion' process? -- lwe On 24-Mar-09, at 12:27 AM, Luke Evans wrote: Check your Managed Object Model. You most likely have a relationship problem. Specifically, scrutinize your deletion rules on all relationships. Thanks. Well, as far as I can tell the model is in good shape, deletion rules are what I expect (and I have no "No Action" anywhere). ___ 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
Re: Remove action on NSArrayController bound to table causes index beyond bounds
Did you try googling the CoreData error message you pasted? One result comes from this very list's archives: Check your Managed Object Model. You most likely have a relationship problem. Specifically, scrutinize your deletion rules on all relationships. Thanks. Well, as far as I can tell the model is in good shape, deletion rules are what I expect (and I have no "No Action" anywhere). Moreover, there is absolutely no problem with deletion except in the given conditions (the remove action that causes the set of displayed rows to fit in the table). It's strange, but there you have it... that's what I'm seeing. I can add and remove the objects in the table without any sign of a problem until this boundary is involved. I was _guessing_ that the CoreData error was likely to be the result of the index out of bounds exceptions in the table binding code. That might turn out not to be the case of course, but the latter exceptions do occur before core data complains about not being able to fulfil a fault (which seems to happen at the next "commitEditing" before a periodic save). There are absolutely no examples of this error for the majority of instances of remove (the CoreData faulting error ONLY seems to occur after the array bounds exceptions has been induced). -- lwe ___ 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
Re: Remove action on NSArrayController bound to table causes index beyond bounds
On Mar 23, 2009, at 7:52 PM, Luke Evans wrote: *** -[NSCFArray objectAtIndex:]: index (8) beyond bounds (8) 2009-03-23 16:17:46.118 App[17940:817] *** -[NSCFArray objectAtIndex:]: index (8) beyond bounds (8) 2009-03-23 16:17:46.132 App[17940:817] CoreData could not fulfill a fault for '0x1a57a90 > Did you try googling the CoreData error message you pasted? One result comes from this very list's archives: http://www.cocoabuilder.com/archive/message/cocoa/2005/5/12/135677 http://archives.devshed.com/forums/bsd-93/coredata-could-not-fulfill-a-fault-411453.html Check your Managed Object Model. You most likely have a relationship problem. Specifically, scrutinize your deletion rules on all relationships. -- I.S. ___ 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
Remove action on NSArrayController bound to table causes index beyond bounds
I have a table bound to an NSArrayController that provides content from Core Data. This has been pretty trouble-free except that the hook up that removes the selected object/row (currently a 'minus' button under the table that uses the "remove" action on the controller) appears to cause an exception intermittently. The problem manifests as an index out of bounds exception (and often a subsequent CoreData error, though I think this is likely a knock-on effect). *** -[NSCFArray objectAtIndex:]: index (8) beyond bounds (8) 2009-03-23 16:17:46.118 App[17940:817] *** -[NSCFArray objectAtIndex:]: index (8) beyond bounds (8) 2009-03-23 16:17:46.132 App[17940:817] CoreData could not fulfill a fault for '0x1a57a90 > Here's the stack trace at the point the exception is raised, with the array controller's 'remove' still visible at the bottom. #0 0x93ed2c26 in -[NSException raise] #1 0x964f7571 in -[NSTableBinder _updateSelectionIndexes:] #2 0x964f6caf in -[NSTableBinder _observeValueForKeyPath:ofObject:context:] #3 0x964f69a9 in -[NSTableBinder observeValueForKeyPath:ofObject:change:context:] #4 0x94f66b0e in NSKVONotify #5 0x94ef70a5 in -[NSObject(NSKeyValueObservingPrivate) _notifyObserversForKeyPath:change:] #6 0x962d570a in -[NSController _notifyObserversForKeyPath:change:] #7 0x962d560b in -[NSController didChangeValueForKey:] #8 0x964f1920 in -[NSArrayController didChangeValuesForArrangedKeys:objectKeys:indexKeys:] #9 0x96690bb6 in -[NSArrayController _removeObjectAtArrangedObjectIndex:objectHandler:] #10 0x9668cd95 in -[NSArrayController removeObjectAtArrangedObjectIndex:] #11 0x9668d4ff in -[NSArrayController remove:] ... Now, the circumstance in which this occurs _appears_ to involve a boundary condition. If the deletion of the row is just about to cause the number of items in the table to fit vertically in the view (i.e. vertical scroll bar will disappear), then the exception can occur. I need to continue testing, but at the moment I'm confident in saying that this is a strong correlation. It may be causation. In the absence of this condition I appear to be able to add and delete items/rows quite happily using the array controller actions. At present, the array controller is configured for single selection and to preserve selection (I have tried turning the latter off, to no effect). I think I've seen some discussion in the list archives that may be related (index out of bounds when removing from a table), but I haven't read anything that gives me a bead on what to investigate next. Does anyone recognise these set of circumstances, or have any insight to why NSTableBinder's _updateSelectionIndexes might be getting upset? When the problem is not induced, the selected row correctly disappears and the table is left with no selection (which is allowed/ intended), so I'm not sure why the apparent reconfiguration of the view in its scroll view would have any different effect. However, as a rough guess it looks like something hasn't been updated with the new extent of the row indices in this case. -- Luke ___ 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
