I don't know if this was the issue that Steven was asking about, but I've been wondering if there is a recommended way to persist the undo stack so that it's still available if you restart the app, or close and re-open the document. It's always bothered me that there is this great mechanism for handling undo, but that all the history is thrown away when you close the app.
-- Doug On 24 Mar 2012, at 01:04, Graham Cox wrote: > You can read and write to the Application Support folder. > > But FILES in an Undo stack? That makes little sense to me. > > If you want to undo changes to a file, store the changes or the command that > will cause the changes in the undo stack. If you are changing the > organisation of files on disc then save a description of that organisation in > the undo stack. You may want to read up on the way Cocoa utilises Undo, > because it sounds like you might not have a good grasp on it. > > Even if you need to store very large objects in the undo stack, unless you > can prove it's a serious problem, just let the memory get paged to disk VM > naturally. It's rare that users need to undo a very long history, so even if > the older history is paged out, the chances are the user will never know. > > --Graham > > > > > > On 24/03/2012, at 10:17 AM, Steven wrote: > >> Hello, >> >> Where is the correct place to store an on-disc undo stack associated with a >> NSDocument instance ? >> The stack may contain several potentially large files so we don't want them >> to occupy memory. >> For a compound document the stack could reside in a directory NSFileWrapper. >> For a single file document should a temporary directory be used ? >> I guess the chosen location may need to persist beyond the occurrence of the >> automatic termination feature. >> Any advice appreciated. >> Thanks. >> >> Steven. >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected]) >> >> 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: >> https://lists.apple.com/mailman/options/cocoa-dev/graham.cox%40bigpond.com >> >> This email sent to [email protected] > > > _______________________________________________ > > Cocoa-dev mailing list ([email protected]) > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/doug%40wiredthing.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
