On Dec 4, 2009, at 4:29 PM, Graham Cox wrote: > However, what about the bug where opening and closing a group but doing > nothing in between creates a bogus empty undo task? This comes into play > when grouping things that occur over a series of events, for example mouse > drags. It would be nice if I could just open a group on mouse down, and close > it on mouse up. Depending on what the mouse actually does, it might not > submit any undoable tasks to the undo manager. So this bug means that case > has to be detected and the undo stack cleaned up. Ultimately this is the > problem I'm trying to workaround - you would not believe how complicated it > can get.
Not sure if that's the only case you encounter where an undoable action spans over more than one event. If it's just the mouse drag stuff why not submitting the action when the mouse drag is complete? From my point of view that would be the logical thing to do, adding undo actions "along the trail" sounds wrong. What I expect to do in a drag is changing a collection of objects from one state (before the drag) to another (when the button is released). Everything in between is just interaction to animate the drag but it doesn't change the state permanently, at least I wouldn't expect it to. As I said, I can't imagine a purpose for this. That doesn't mean that there isn't something I hadn't thought of - in which case I'd like to be enlightened. Regards Markus -- __________________________________________ Markus Spoettl
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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
