On Thu, Jan 12, 2012 at 4:32 PM, Gideon King <gid...@novamind.com> wrote: > I have a situation where I need my document's contents on disk, even if it's > a new document with no changes, so I thought I would just make sure that the > document had autosaved before I complete my action on the file, and just pick > up the URL of the last autosave from the document and use that. (I'm running > this on Lion) > > > I use: > > - > (void)autosaveWithImplicitCancellability:(BOOL)autosavingIsImplicitlyCancellable > completionHandler:(void (^)(NSError *errorOrNil))completionHandler
This seems sketchy. It would be nice if NSDocument gave us access to the logic it uses to decide where to write autosaved untitled documents (rdar://problem/10206220), but if you want to save the document you should almost certainly just call -saveToURL:ofType:forSaveOperation:completionHandler: directly. If you don't already have a -fileURL or an -autosavedContentsFileURL, you should give it a URL somewhere inside your Application Support directory. > > Now this is fine, except that it only works if the user has made at least one > change to the document. > > The documentation says that it invokes the - (BOOL)hasUnautosavedChanges > method to determine whether to save the document. So I overrode that method > so that during my operation, it will return YES. > > I expected this to ensure that the document would be saved, but it ignores > this and doesn't autosave it. It does actually call this method during the > autosave call, but seems to not take notice that I returned YES. > > So I tried putting a dummy undo action in just before calling autosave, and > then undoing it afterwards, just to ensure that the document was dirty. That > didn't work either. I put it in an undo group, but that didn't work either. I > forced a checkpoint in the undo manager, but that didn't work either. > > So I thought I would try the document updateChangeCount: method, calling > NSChangeDone before calling autosave, then NSChangeUndone afterwards. That > worked! I removed all the other stuff and *only* had the updateChangeCount: > calls in there, and it still autosaved. > > So I have a solution that works, but I'm thinking that my override of > hasUnautosavedChanges should have forced the autosave. Is this a bug that it > doesn't? How is NSDocument going to know to call -hasUnautosavedChanges? Something needs to provoke that. The autosave timer only gets scheduled in response to -updateChangeCount:, and that's what checks for -hasUnautosavedChanges. --Kyle Sluder _______________________________________________ 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
