Re: Grouping undo-able actions with CoreData
Re: Grouping undo-able actions with CoreData
- Subject: Re: Grouping undo-able actions with CoreData
- From: John Timmer <email@hidden>
- Date: Tue, 24 May 2005 23:05:49 -0400
Okay, if I had much hair left, I'd pull it out. There seem to be two
separate issues:
For starters, with the default undo manager of my managed object context,
only some actions in my GUI (I haven't figured out a clear pattern yet)
trigger the enabling of the "Undo" menu item. Many actions that alter a
managed object fail to enable the item. Stranger still, if you're using a
control that can trigger enabling, you don't actually have to change a
managed object in order to enable it - simply selecting some a popup menu
that's bound to a managed object but leaving its value unchanged will enable
the undo menu item. Once that's enabled, however, all the previous changes,
which didn't enable the menu item at the time they were performed, become
undoable.
The second issue is the bundled undo operations. On mmalc's advice, I
started the bundling when the event was triggered and, at the end, tried:
[[theContext undoManager] endUndoGrouping];
[theContext processPendingChanges];
Which, when I tried to undo it, resulted in the following being logged as
the app it hit an exception:
-observeValueForKeyPath:ofObject:change:context: only defined for abstract
class. Define -[_NSProxyWrapperMutableSet
observeValueForKeyPath:ofObject:change:context:]!
Skipping the manual bundling of undos, and setting the undo manager to group
by event resulted in the same thing being logged and same stack trace, so
it's not specific to my manual bundling. Getting rid of the
processPendingChanges call did not change the problem in any way.
Any advice would be very welcome.
JT
> The problem seems a bit weirder than what I first wrote. Some interface
> actions that change managed objects will trigger undo management to start,
> others won't. Once it's started, they all trigger it, even ones that did
> not immediately prior. (more specifically, changing sort descriptors bound
> to a managed object using a table column header doesn't trigger undo -
> changing a popup menu selection in the table that's bound to a different
> managed object will. Once the popup's changed, changing the sort
> descriptors is now undo-able).
>
> Taking advantage of this, the dialog I wanted to test for undo-ability will
> allow undoing. Unfortunately, it crashes with the stack trace below, none
> of which is in my code.
>
> Clearly, it's going to take some playing around to isolate the issue, so
> I'll probably wait until I get home tonight to try to figure things out in
> more detail. Thanks for the quick feedback and suggestion, though.
_______________________________________________
This mind intentionally left blank
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden