Ah! That's what I missed. Thanks. I assume that just tests the zero state of changeCount. Maybe I can override that to return YES if any count is non-zero.
This is a fairly complex document, involving a data hierarchy and various contexts (and editable windows) within that hierarchy. Some of the contexts operate at different levels within the hierarchy. With a single undo manager, I found that it was easy to confuse the undo process and crash it, not to mention the possibility of applying undo to data not visible on the screen at the time. I solved some of the problems by clearing the undo stack when the user changed tab-views in the hierarchy. However, with other windows independently displaying some of the content of the hierarchy, it simply proved unworkable to use a single undo manager. On 12/30/09 12:55 PM, "Mike Abdullah" <cocoa...@mikeabdullah.net> wrote: > I am surprised you actually need more than one undo manager for the document, > but will trust that this is the case. The only way that I am aware of to get > the behaviour you want is going to be writing your own version of the change > count system that handles multiple stacks. i.e. maintain several change count > values internally, and override -isDocumentEdited to go by that. _______________________________________________ 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
