On 30 Dec 2009, at 18:19, Gordon Apple wrote: > When in the course of undo events, it becomes necessary to introduce > multiple undo managers, certain issues arise. For example: How to handle > the document change count? > > I currently have at least a half dozen independent undo managers for my > document, which I keep in a bank near the document level. Each undo manager > is monitored for change notifications, and dings the document's change count > appropriately. This seems to work, except that, being the meticulous > systems engineer that I am, I'm a strong believer in Murphy. For a new or > newly opened document, this will correctly ask the user to save when the > document is closed, and then zeros the doc's change count. However, if the > user first saves the document, then decides to change something in one undo > context, then undoes something in another undo context, the change count > will be zero and closing the doc will not ask for a save. (Doing such > changes in the opposite order will pop the "undo after save" dialog.) > Anyway, this is not the desired result. > > It looks like I need to maintain individual change counts for each undo > manager, zero them all on "save". When closing the doc, ANY non-zero > (positive or negative) change count should trigger the "save" dialog. > > Am I making this too hard, or is there a more straightforward way?
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. Fortunately it's a fairly simple behaviour, and the APIs it uses are pretty well documented. > > Also, why the heck is there no accessor to read the doc's change count? I > could let the doc handle it if non-zero, and otherwise scan the undo bank > and pop the save dialog is necesssary. I would argue that it's a bit like -retainCount. If you have code that is reading the value of -retainCount you're almost certainly doing it wrong, but it's occasionally handy to have the value available when debugging. It probably would have been nice if Apple had done the same for change count, but when you look at all the confusion -retainCount causes newbies, it's more understandable._______________________________________________ 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
