Re: NSArrayControllers not repopulating after NSPersistentDocument load
Re: NSArrayControllers not repopulating after NSPersistentDocument load
- Subject: Re: NSArrayControllers not repopulating after NSPersistentDocument load
- From: Quincey Morris <email@hidden>
- Date: Wed, 13 Jan 2010 14:50:25 -0800
On Jan 13, 2010, at 13:28, Daniel Wambold wrote:
> I have an NSPersistentDocument app using CoreData for storage. I have three NSArrayControllers to mediate between the three Entities in my Model and three NSTableViews. Everything works fine until I load a previously saved file. At that point, the controllers seem to have no content despite the fact that the tables are properly populated. That is, the NSTableView shows data, but po [self arrangedObjects] in GDB shows an empty array.
> At first I figured it was a timing issue, so I delayed the attempt to manipulate an object (accessed by [[self arrangedObjects] objectAtIndex:0]) with a message delayed by up to several seconds with no improvement. If I force a fetch, I can retrieve the data, but for some reason the controller is not taking care of this on its own. I have verified that the controller "automatically prepares content," and it's not fetching lazily, per IB. I'm sure I've missed something obvious, but I'm stuck. I'm not sure if it's relevant, but the value of [self managedObjectContext] is different if I check it in the NSPersistentDocument object immediately after - (BOOL)configurePersistentStoreCoordinatorForURL:(NSURL *)url ofType:(NSString *)fileType modelConfiguration:(NSString *)configuration storeOptions:(NSDictionary *)storeOptions error:(NSError **)error versus later, when my controller tries to manipulate its content. Although I modified the document's load method to investigate this (just a call to super followed by a break point), the same behavior exists even without overriding this method. If the answer is in the Apple Docs, I've missed it because I've read them several times now. Incidentally, the "Cannot access contents of an object controller after a nib is loaded" section of "Core Data Programming Guide" looked promising, and fetchWithRequest:merge:error returns YES, but it still doesn't cause the controller to repopulate. I've got perhaps 50 pieces of string data stored in this document, so it's not a volume of data issue, I don't think.
Your problem description is too wide to suggest an particular cause, but there are two *typical* causes of this sort of behavior:
1. You've created two objects where you only want one. For example, you've created an object in code, but also instantiated one in a nib file.
2. You've tried to follow connections during the nib loading processes, when some of them haven't been established yet.
Your problem sounds a bit like #1 -- if a NSTableView shows data, its NSArrayController has data, so if the debugger shows no data, the object you're looking at isn't the NSTableView's array controller. Also, the existence of two NSManagedObjectContext objects points in the same direction.
> The troublesome code, from my NSArrayController subclass, follows. The object, myNote, is sent, after a brief delay, from the Nib file of another object. I verified it contains a valid NSDate object.
>
> - (void) myChangeStartTime:(NSNotification *)myNote
> {
> [self setFilterPredicate:nil];
> [self rearrangeObjects];
> [[[self arrangedObjects] objectAtIndex:0] setValue:[[myNote object] dateValue] forKey:kMyDateBindingKey];
> }
I happen to think that subclassing a NSController object is a terrible idea, if it can be avoided. [Apologies in advance to those who've successfully and/or necessarily subclassed NSController -- I've no doubt there are times when it's a good idea, but I'm not going to let the facts stand in the way of an opinion. ;) ] NSController objects are glue objects, making any code you add to them turn into glue code, when it should likely be either data model code or user interface code.
One warning sign is the invocation of 'rearrangeObjects', which is in general a very big hammer. One of the purposes of bindings [my opinion, again] is to avoid the need to do anything to *all* objects whenever possible, since that may be expensive.
That last line of code is a bit worrying, too. Why is it a NSArrayController's responsibility to set up a data model's properties, and why isn't the notification being sent to the data model instead?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden