You are right, I have a similare project.
But I have like hundreds of graphic views witch are similar to one of
the DK drawing areas. You can activate or open one object in its own
view, edit the content and close it. Then you switch to the next, edit
it and so on. When you come back to the first Item, the undo should
address this and not the one that you edited bevor (and is not visible
any more) ...
So in the case of multiple selections the dummy UndoManager actually
doesn't need to do anything itself. It just has to aks each individual
item to undo:
NSArray * SelectedItems = [self selectedItems];
if ( SelectedItems ) {
for (GSItem* currItem in SelectedItems) {
[currItem.parent.undoManager undo];
}
}
And how i there a way to set the dirty state of the document if I use
my own undoManager. Can I register them somehow?
Thanks
Georg
Am 06.07.2008 um 06:33 schrieb Graham Cox:
I've done a lot of stuff recently with Undo in my DrawKit project,
which sounds a little like what you are doing also. I have to say,
having one undo manager per object sounds like a recipe for
confusion. It's just not how undo is intended to work, and not how
users expect Undo to work.
In DK, I have one undo manager per document which is the common
model, and all undo operations for any object go to the same UM.
Normally, you do not select the target for the undo manager when
*undoing* - the target is recorded when *doing*. Then when the user
invokes undo it just backtracks through all the operations you did -
it knows what the target object is for each op, you shouldn't need
to select it. Where you can interactively select objects (as in DK),
the undo manager also records the selection state, but only along
with any actual data changes made - simply changing the selection
isn't normally recorded as an undoable task in itself. Then when the
user undoes several things, the selection state also backtracks with
it, so it's clear (and automatic) what object was affected by the
undo.
By having one undo manager, it's also easy to manage the text in the
undo menu item to say what is going to be undone. Only by using the
undo manager in this expected way is this as easy as this - doing it
your way you'll have to force a menu change every time your
selection changes, which is probably possible, but definitely not
the expected way to do it. You say "it needs to be this way" but
why? It's so bizarre it's unlikely to win any friends amongst your
app's users, and surely, doing it the conventional way is a much
easier programming task too?
cheers, Graham
On 5 Jul 2008, at 9:07 pm, Georg Seifert wrote:
Hello,
I have a rather complicated undo setting
My document Object has a Array of independent graphical items
(containing some properties).
Each item should have its own undo/redo based of selection in the
interface. So I select Item_1, modify it, select Item_2 and modify
it, too. Then I want to be able to select item_1 again and undo its
changes.
I know that this is very unusual and may confuse users but it needs
to be this way.
I have a Instance of NSUndoManager in each of my items. But how do
I tell the menu which undoManager is "active" (to display an
appropriate actionName).
any suggestion is welcome.
Thanks in advance
Georg
_______________________________________________
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/graham.cox%40bigpond.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
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 [EMAIL PROTECTED]
