Re: objectInXXXAtIndex: exception
Re: objectInXXXAtIndex: exception
- Subject: Re: objectInXXXAtIndex: exception
- From: Bertrand Landry-Hetu <email@hidden>
- Date: Mon, 20 Jun 2005 18:39:47 -0700
I found out that I had another NSArrayController that was keeping a
selection that would make it crash. So I disabled the preserve
selection, avoid empty selection and the selects when inserted flags
and the crash went away. This is a good work around for now but
eventually I'll need that selection to be working. That array
controller was bound to an object controller which we are setting
programmatically the content of. So there seems to be a bug with that
specific combo on Panther (works fine on Tiger).
On 6/20/05, Bertrand Landry-Hetu <email@hidden> wrote:
> I updated my Object Model to make use of the right batch importer but
> on a few systems running Panther I still get the problem. My OM is
> basically a list of customer, each customer has a list of jackets.
> When the user wants to refresh the data (its coming from the WAN) the
> customer list is emptied and every jacket child is freed.
>
> in [JacketListEntity removeAllEntities]
>
> NSRange everyIndex = NSMakeRange( 0, [m_entities count] );
> [self will/didChange: NSKeyValueChangeRemoval
> valuesAtIndexes: everyIndex
> forKey: @"jackets"];
>
> Here is the stack crawl when the oob exception is raised.
>
> *** -[NSCFArray objectAtIndex:]: index (0) beyond bounds (0)
> Stack trace:
> 1 -[NSCFArray objectAtIndex:] (in Foundation)
> 2 -[JacketListEntity objectInJacketsAtIndex:] (in CocoaBridge)
> (SCBE_JacketListEntity.mm:157)
> 3 -[NSArrayController selectedObjects] (in AppKit)
> 4 -[NSArrayController setContent:] (in AppKit)
> 5 -[NSArrayDetailBinder _refreshDetailContentInBackground:] (in AppKit)
> 6 -[NSObject(NSKeyValueObservingPrivate)
> _notifyObserversForKeyPath:change:] (in Foundation)
> 7 -[NSController _notifyObserversForKeyPath:change:] (in AppKit)
> 8 -[NSController
> observeValueForKeyPath:ofObject:change:context:] (in AppKit)
> 9 -[NSObject(NSKeyValueObserverNotification)
> didChange:valuesAtIndexes:forKey:] (in Foundation)
> 10 -[JacketListEntity removeAllEntities] (in CocoaBridge)
> (SCBE_JacketListEntity.mm:679)
> 11 -[SCBE_ListBaseEntity invalidate] (in CocoaBridge)
> (SCBE_ListBaseEntity.mm:41)
> 12 -[SCBE_CustomerEntity invalidate] (in CocoaBridge)
> (SCBE_CustomerEntity.mm:119)
> 13 -[SCBE_CustomerListModel removeAllCustomers] (in CocoaBridge)
> (SCBE_CustomerListModel.mm:215)
> 14 -[SCBE_CustomerListModel refresh] (in CocoaBridge)
> (SCBE_CustomerListModel.mm:113)
> 15 -[SCBE_ListBaseEntity startRefreshing] (in CocoaBridge)
> (SCBE_ListBaseEntity.mm:119)
> 16 -[SYDMainWindowController refreshAll:] (in Synapse Desktop)
> (SYDMainWindowController.mm:679)
>
>
> The hard part is trying to figure exactly what is causing this ? are
> the NSObjectController & the NSArrayController objects the same or
> different object. Is there another controller wreaking havoc
> somewhere. And even worst it feels like a race condiction since only
> some machines have the problem...
>
>
> On 5/9/05, mmalcolm crawford <email@hidden> wrote:
> >
> > On May 9, 2005, at 3:45 PM, Bertrand Landry-Hetu wrote:
> >
> > > What happens is that the application starts up, the GUI connects to
> > > the model, everything works. Something triggers an update of our model
> > > and ends up calling removeAllObjects on the NSMutableArray that
> > > represents Bar. So to keep the bindings updated we wrapped that call
> > > in willChangeValueForKey:@"bar", didChangeValueForKey:@"bar", so it
> > > does trigger the NSArrayControllers that is bound to Foo.Bar.
> >
> > Umm, this is wrong. You're telling observers that something has
> > happened that hasn't...
> >
> > See:
> > <http://homepage.mac.com/mmalc/CocoaExamples/controllers.html>
> > "Batch import into an array, and other mass changes"
> >
> > You want to do the inverse of adding (so you'll use
> > NSKeyValueChangeRemoval etc.)...
> >
> > mmalc
> >
> >
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Cocoa-dev mailing list (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> >
> > This email sent to email@hidden
> >
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden