Вопрос

I have an NSManagedObject called appointment that I edit the attributes of. If I the user presses cancel I want to reverse all of those edits.

If I do (example code)

[[appointment managedObjectContext] setUndoManager:[[NSUndoManager alloc] init]]; //however doing a nslog on undoManager still shows it as (null);
[[[appointment managedObjectContext] undoManager] beginUndoGrouping];
appointment.startTime = 11;
appointment.endTime = 12;
appointment.customer = @"Tom";
[[[appointment managedObjectContext] undoManager] endUndoGrouping];
[[[appointment managedObjectContext] undoManager] undo];

shouldn't it undo all change changes in between beginUndoGrouping and endUndoGrouping? It seems there are numerous ways to do this but I cannot seem to find the correct way. What is the correct way to undo changes on an NSManagedObject?

Это было полезно?

Решение

I imagine that is just an example of the order in which events would proceed, and not an actual example.

Did you, by chance, forget to give the ManagedObjectContext a NSUndoManager?

I believe you get one by default under OS X, but under iOS, you have to specifically provide one.

You want to be sure to set the undo manager when you create your MOC...

managedObjectContext.undoManager = [[NSUndoManager alloc] init];

If the undo-manager is nil, after doing this, then you are using multiple MOCs, or some other code has reset it.

Also, for the purpose of debugging, check the appointment.managedObjectContext property, and make sure it is not nil and references a valid MOC.

EDIT

Ok, I just went and wrote a quick test, using a simple model. Maybe you should do something similar to see where your assertions are failing (you can just add normal assert in your code path - I did this one as a unit test so I could easily add it to an existing project).

- (void)testUndoManager
{
    NSDate *now = [NSDate date];
    NSManagedObjectContext *moc = [self managedObjectContextWithConcurrencyType:NSConfinementConcurrencyType];
    STAssertNil(moc.undoManager, @"undoManager is nil by default in iOS");
    moc.undoManager = [[NSUndoManager alloc] init];
    [moc.undoManager beginUndoGrouping];
    NSManagedObject *object = [NSEntityDescription insertNewObjectForEntityForName:EVENT_ENTITY_NAME inManagedObjectContext:moc];
    STAssertNotNil(moc, @"Managed Object is nil");
    STAssertEquals(moc, object.managedObjectContext,  @"MOC of object should be same as MOC");
    STAssertNotNil(object.managedObjectContext.undoManager, @"undoManager of MOC should not be nil");
    [object setValue:now forKey:@"timestamp"];
    STAssertEqualObjects(now, [object valueForKey:@"timestamp"], @"Timestamp should be NOW");
    [moc.undoManager endUndoGrouping];
    STAssertEqualObjects(now, [object valueForKey:@"timestamp"], @"Timestamp should be NOW");
    [moc.undoManager undo];
    STAssertNil([object valueForKey:@"timestamp"], @"Object access should be nil because changes were undone");
}

EDIT

The MOC of a managed object can be set to nil under several conditions. For example, if you delete an object, and then save the mod, the MOC will be set to nil for that object...

NSManagedObject *object = [NSEntityDescription insertNewObjectForEntityForName:@"SomeEntity" inManagedObjectContext:moc];
[object.managedObjectContext deleteObject:object];
[moc save:0];
// object.managedObjectContext will be nil

Another, less common case, but a sign that there may be a memory issue with the MOC... Under ARC, the MOC of a managed object is a weak pointer. Thus, if the MOC goes away, that pointer will be reset to nil. Under non-ARC, the pointer will just have the old value, and your results will be undefined... probably a crash.

So, if managedObject.managedObjectManager is nil, the most likely culprits are:

  1. The object was never inserted into a MOC
  2. The object was deleted from a MOC
  3. The MOC was deleted

Другие советы

The biggest reason undo doesn't work with Core Data is not creating and setting the undo Manager...

 newManager = [[[NSUndoManager alloc] init] autorelease];
 [newManager setLevelsOfUndo:4];
 myManagedObjectContext.undoManager = newManager;

You also don't need the Begin/end undoGrouping, as that's done for you.

It's also possible (partly because that's done for you) that the undo won't work until you go back to the event loop and are called next time. (In other words, cutting up the user's hitting the undo button may not work.)

Ah, you just added the comment above. Please post the code that does the setting, as your undoManager being null would obviously make it not work.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top