Re: NSUndoManager - clearing a single 'redo' - Now->doesn't respond to removeAllActionsWithTarget
Re: NSUndoManager - clearing a single 'redo' - Now->doesn't respond to removeAllActionsWithTarget
- Subject: Re: NSUndoManager - clearing a single 'redo' - Now->doesn't respond to removeAllActionsWithTarget
- From: Bruce Veazie <email@hidden>
- Date: Mon, 9 Dec 2002 19:14:39 -0500
Thanks for the ideas, Bill.
I didn't try pfutzing with NSUndoManager itself. It occurred to me that
I could create a dummy target for that one undo and remove all actions
for that dummy target when the undo is performed. That should preserve
the documents other pending undo's and redo's.
I.e., when a new object is loaded by the document, it registers an
'undo' with a target of 'dummyUndo' class, alloc'd especially for the
purpose. 'dummyUndo' simply calls the document back when the undo is
invoked. Doc deletes the object and does a [undomanager
removeAllActionsForTarget:dummyUndo].
However, the 'Edit' menu now shows 'redo Add object.' Clicking it
doesn't appear to perform any action but 'Add object' is obligingly
moved to the undo stack to display 'Undo Add object,' which doesn't do
anything either.
I tried both the 'registerUndo' and 'prepareWithInvocation' methods as
well as throwing in some begin- and endgroupings for good measure in
various combinations as exasperation increased. I also tried targeting
the document method itself in the undo and performed a
'removeAllActionsForTarget:self' when the object was deleted.
To no avail. The 'Add object' action stays in the Edit menu.
Am I missing the use of the 'removeAllActionsForTarget' method or
perhaps some sort of menu item validation call? Any help?
on 02-12-08 8:59 PM, Bruce Veazie at email@hidden wrote:
Is there a way to prevent an 'undo' from being transferred to the
'redo' stack or to clear just the last redo?
I'm developing a document-based OpenGL modelling app. When an object
is
loaded from a file I register an 'undo load object' which deletes the
object - to permit the user to delete an object just loaded if it's
the
wrong file, etc. When Cmd-z is used to undo the load, i.e., delete the
erroneously loaded object, a 'Redo load object' gets stacked. I'd
prefer not to have that 'redo' on the stack.
Anyone know of a way to clear that single 'redo load' when the 'undo
load' is invoked?
I do something very like this to implement "live" undo and redo of text
field editing in Recipe 7 of my new book "Cocoa Recipes for Mac OS X:
The
Vermont Recipes" (Peachpit Press). I need to clear the redo stack when
the
user stops editing the field.
It involves subclassing the textfield, observing 3 Undo Manager
notifications, sending "fake" undo calls to move unwanted undo items
to the
redo stack, then registering a new action on the undo stack for the
same
text field in order to clear the redo stack. In the case of text fields
there is the additional complication of creating a separate field
editor,
but you wouldn't have to worry about that. The rest of the technique
might
work for you.
The trick lies in registering a new undo action for the same control.
That
has the side effect, you might say, of clearing the redo stack. At this
time, as far as I know, it is the only relatively easy way to clear
the redo
stack.
You could look at the private variables in the Cocoa headers and get
at the
redo stack that way, using a category to add a method to the undo
manager --
say, clearRedoStack. I played around with that approach just long
enough to
be able to read the redo stack. But you would have to spend a lot of
time
experimenting to make sure this didn't screw up a lot of internal
counters
and so on, and I'm not sure it's feasible.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
Bruce J. Veazie
email@hidden
http://veazie.org
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.