In trying to eliminate extraneous undo groupings from my Core Data
document-based applications, I've noticed a simple paradox maybe
someone could explain.
In my persistent document's -init, I replace its undo manager, and
that of its managed object context, with my own which, for now, is a
subclass of NSUndoManager. On occasion, while Core Data is flipping
undo groups, I see that it somehow runs -beginUndoGrouping without the
-groupingLevel being incremented as I expect. This is easily observed
by overriding -beginUndoGrouping to do some logging:
- (void)beginUndoGrouping {
NSInteger oldGroupingLevel = [self groupingLevel] ;
[super beginUndoGrouping] ;
NSString* alarm = ([self groupingLevel] == oldGl + 1) ? @"
" : @" !!!!" ;
NSLog(@"2399 %s gl %d->%d%@ %p",
__PRETTY_FUNCTION__,
oldGroupingLevel,
[self groupingLevel],
alarm,
self) ;
}
This often, but not always, appears to be associated with a similar no-
op by -endUndoGrouping. Some log excerpts:
12:45:22.165 Test[77155:10b] 2399 -[SSYUndoManager beginUndoGrouping]
gl 1->1 !!!! 0x173abdf0
...
12:45:24.809 Test[77155:10b] 2399 -[SSYUndoManager beginUndoGrouping]
gl 0->0 !!!! 0x173abdf0
12:45:24.809 Test[77155:10b] 2599 -[SSYUndoManager endUndoGrouping] gl
0->0 !!!! 0x173abdf0
Is not -beginUndoGrouping always expected to increment the -
groupingLevel? What could be going on here?
This is Mac OS 10.5.8. I have been careful to always access the undo
manager only from the main thread.
Sincerely,
Jerry Krinock
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
