chrisblunt.com

A frustrating problem I came across today when I tried binding an NSPopUpButton’s selection key to an NSArrayController’s selection was that the NSPopUpButton would always display a ‘ghost’ object -one of the opaque classes internal to Cocoa/Core-Data Bindings(<_NSControllerObjectProxy… or similar).

It turns out that NSPopUpButton does not record the user’s selection, so even if I had been able to get rid of the ghost object, I wouldn’t have been able to access the selected object.

The solution is to manually maintain a currently selected object in the window controller - File’s Owner in Interface Builder; in this case, selectedPackage:

In MyWindowController.m:

- (void)setSelectedPackage:(NSManagedObject *)package
{
// ... checks ...
selectedPackage = package;
}
 
- (NSManagedObject *)selectedPackage
{
return selectedPackage;
}

In Interface Builder, the NSPopUpButton should be bound to the NSArrayController (Packages) and the File’s Owner as:

Content: Packages.arrangedObjects
Content Values: Packages.arrangedObjects;modelPath=packageName
Selection: File’s Owner.selectedPackage

A default selection can then be provided by calling the setSelectedPackage: method.

Hours of searching for an answer were beginning to lead me to the conclusion that it was impossible to unfault transient properties of an NSManagedObject after loading them from a datafile.

The Problem: A ’smart’ group to show expiring domains based on their (transient, calculated) isExpiring property worked until the document was saved. On saving, the objects in the context became faults and the smart group no longer worked. This was also true of re-loading a saved document - the domain’s isExpiring property would not be unfaulted.

ame

The Solution: It’s a horrible solution, but seemingly the only way to get the faults to fire (calling [domain will/didAccessValueForKey:@"isExpiring"] did nothing). On awakening the smart group from a fetch, a quick NSFetchRequest is created to fetch all the Domain objects and unfault their @”data” propety. This is no doubt a dirty piece of code, but seems to force the calculated properties to be unfaulted.

- (void)awakeFromFetch
{
ame [super awakeFromFetch];
ame [self commonAwake];
ame
ame NSError *error;
ame NSFetchRequest *fr = [[[NSFetchRequest alloc] init] autorelease];
ame [fr setEntity:[[self fetchRequest] entity]];
ame
ame NSArray *results = [[self managedObjectContext]
ame SEnumerator *enumerator = [results objectEnumerator];
ame id object;
ame
ame while( object = [enumerator nextObject] ) {
ame NSLog( [object valueForKey:@"domainName"] );
ame [object willChangeValueForKey:@"data"];
ame [object didChangeValueForKey:@"data"];
ame }
}

With this now working, I can finally continue implementing the business logic in HM2.0, and stop worrying about the intricacies of Core Data and the dark art of Bindings.