Thanks for fix above. I believe I finally figured out a way to make undo work reliably. The basic problem is that while Core Data correctly does the undo and redo on the data, NSOutlineView doesn’t necessarily see the changes and as the display gets out of the sync with the model, eventually an undo/redo command is issued without the correct data on the stack to perform it, resulting in the “NSUndoManager is in invalid state, undo was called with too many nested undo groups” error.

In my my, the user must be able to sort the outline by various criteria, as well as sorting just a few selected rows within any given group. This has to be un-doable, and however the outline happens to be sorted/subsorted when it’s saved, it should re-open with the items in the same order. Obviously, that’s where I’m using your sortIndex idea. I set the sort descriptors as needed, update the sortIndices with your -updateSortOrderOfModelObjects method. When the document is re-opened, the sort descriptors are first set to one that sorts by the sortIndex, recreating the previous order. Undo works on everything, sorts, name edits, drag reordering, collapse/expand.

To get undo working in your sample project, I downloaded a fresh copy and made these changes. It may not be the best way, but it does seems to work.

1) In ESTreeController.m, change -reloadData so that it expands -and- collapses items according to the reloaded data. This is to prevent the problem of collapsing a group item, undo it and having work, then redoing and having the Edit menu flash correctly (indicating there was something on the stack that gets redone) but there being no visible change.

Something like:

- (void)reloadData;
{
[super reloadData];
NSUInteger row;
for (row = 0 ; row < [self numberOfRows] ; row++) {
NSTreeNode *item = [self itemAtRow:row];
if (![item isLeaf]) {
if ([[[item representedObject] valueForKey:@”isExpanded”] boolValue])
[self expandItem:item];
else
[self collapseItem:item];
}
}
}

=====
2) When Core Data undoes/re-does something, say a sort, the model data is changed correctly, and all the sortIndex values are restored, the outline view needs to be told to reload its data. NSUndoManagerDidUndoChangeNotification/NSUndoManagerDidRedoChangeNotification work for this. If you allow sorting on criteria other than sortIndex, as described above, Core Data may have changed a bunch of sortIndex values, and to get the un-done sort displayed, we need to tell the treeController to to re-sort by the sortIndex before anything happens to call -updateSortOrderOfModelObjects, which will overwrite all the un- or re-done sortIndexes with the item’s current, pre-undone position in the outline. If that makes sense…

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{

[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(undoManagerDidUndo:)
name:NSUndoManagerDidUndoChangeNotification
object:nil];
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(undoManagerDidRedo:)
name:NSUndoManagerDidRedoChangeNotification
object:nil];
}

- (void)managedObjectsDidChange:(NSNotification *)notification
{
[outlineView reloadData];
[treeController setSortDescriptors:nil];
[treeController setSortDescriptors:[self treeNodeSortDescriptors]]; // keep treeController sorted by sortIndex (except during a sort by name, etc)
}

- (void)undoManagerDidUndo:(NSNotification *)notification
{
[outlineView reloadData];
[treeController setSortDescriptors:nil];
[treeController setSortDescriptors:[self treeNodeSortDescriptors]]; // keep treeController sorted by sortIndex (except during a sort by name, etc)
}

====
3) I was constantly getting this error

SortedTree Error setting value for key path treeNodeSortDescriptors of object (from bound object [entity: TreeNode](null)): [ setValue:forUndefinedKey:]: this class is not key value coding-compliant for the key treeNodeSortDescriptors.

To stop it, I just turned off the NSTreeController sortDescriptors binding to ESAppDelegate’s treeNodeSortDescriptors, and instead, set the sort descriptors in code in -awakeFromNib or -windowControllerDidLoadNib.

====
4) These errors were constantly being logged:

-[ESTreeNode isSpecialGroup]: unrecognized selector sent to instance 0×193e00

-[ESLeafNode isSpecialGroup]: unrecognized selector sent to instance 0×1a4910

[ valueForUndefinedKey:]: the entity Leaf is not key value coding-compliant for the key isExpanded.

-[ESLeafNode canExpand]: unrecognized selector sent to instance 0×171f80

According to http://www.cocoabuilder.com/archive/message/cocoa/2008/6/9/209710

these seem to be due to a bug in Leopard which causes the -outlineView: isGroupItem: delegate method to sometimes be sent a dealloced object when Undo/Cmd-Z is used immediately after a creating a new object with CoreData when the NSOutlineView is set to SourceList style in InterfaceBuilder.

Whew… My fix was just to turn off the source list style. In my app I don’t use the style, so changed -outlineView: isGroupItem: to always return NO.

Well, sorry for the long post, but I wanted to report back since your code helped me get my CoreData/NSTreeController app off the ground. Shoot me an email at the address in this form if you’d like the edited project. Thanks again.

Sorry for the late reply and for not updating that project properly. I should be moving over to my own server soon where I’ll be able to host whatever files I want to!

I realise now that I’d changed my implementation of -[NSTreeController flattenedContent] ages ago to be:

- (NSArray *)flattenedContent;
{
return [[self flattenedNodes] valueForKey:@”representedObject”];
}

which really helps in cutting down on such copy/paste errors. You’re correct that to be correct in your implementation that ESTreeNode needs a -descendants key. As I’d written the above method I hadn’t run into this one.

I need to have another look at undo, I’m surprised that its works for you. Maybe it was fixed be an OS update?…

Just tried it an it tells me that the undo manager is left in an invalid state with too many nested undo groups. Can you try and reproduce this on your machine?

Jon

In ESTreeNode.m:

- (NSArray *)descendants;
{
NSMutableArray *array = [NSMutableArray array];
for (ESTreeNode *child in self.children) {
[array addObject:child];
if (![[child isLeaf] boolValue])
[array addObjectsFromArray:[child descendants]];
}
return [[array copy] autorelease];
}

Small bug in NSTreeController_Extensions.m: the -flattenedContent method throws a valueForUndefinedKey exception, “the entity Group is not key value coding-compliant for the key descendants.”

The trouble is a mere copy/paste error, -flattenedNodes and -flattenedContent are very similar, and both do

[node valueForKey:@"descendants"].

However -flattenedContent is working with ESTreeNodes, not NSTreeNodes. The descendants key works in -flattenedNodes (calling your -descendants category on NSTreeNode), but clearly @”children” was intended here, to call ESTreeNode’s -children method.

That is, in -flattenedContent :

if (![[realNode valueForKey:[self leafKeyPath]] boolValue])
[mutableArray addObjectsFromArray:[realNode valueForKey:@"children"]]; // < -

This works fine.

-Bill

PS, dragging leaf objects and undoing seems to be working here - no problems.

Sorry it’s taken me a while to get back to you on this, I’m in a rather internet-less state at the moment!

Unfortunately I haven’t been able to get undo working for it, and you’re right that its goes haywire! I think it would require some inventive creation of undo-groupings if it’s possible to fit it into the undo architecture of Core Data at all.

In Scribbler, I’ve actually turned of the Core Data undo management and written my own for that parts that make sense. The way I use this source list, for management of files and folders like iPhoto does, it’s not a requirement to make moving a node an undoable action, so I haven’t pursued it.

Sorry I can’t shed any more light on it, if you get somewhere with it, please let me know.

Jon

Nice example app very helpful, was wondering if you where able to do the same thing but with undo working it, right now if you drag and drop a leaf from one place to another and hit undo the results from the undo are very random.

Rob

Would like to bug you again, not 100% related but since you mentioned NSPersistentDocument and core data in other posts…

I’ve got a core-data based app which is a non-document-based app (think iTunes, etc) yet I’d like to use the document-based machinery for it. In other words, I want to use NSPersistentDocument (ie. it’s undo features) + XSControllers architecture except that I’d like the document to be hard-wired to only file on disk — with no support for opening file types etc.

Is there some smart way to do this without changing Info.plist? Would you recommend this approach? Perhaps instantiating the Document myself and calling/simulating the makeWindowControllers machinery myself?

Tried that. No luck. It just hangs. I there’s an incompatibility with the version of IB you’re using and the official version 3.0. You used an unreleased beta so I expect there are some differences in the format of the XIB.