Re: Where and how do I know a save completed successfully?
Re: Where and how do I know a save completed successfully?
- Subject: Re: Where and how do I know a save completed successfully?
- From: Charles Jenkins <email@hidden>
- Date: Fri, 08 May 2015 05:46:06 -0400
I may have a fundamental misunderstanding of how a document class, a text view, and an undo manager work together.
I made these override functions in my Document class:
override func updateChangeCount( change:NSDocumentChangeType ) {
println( "updateChangeCount:" )
super.updateChangeCount( change )
if change == .ChangeCleared {
println( "Change count cleared. Now clearing modification flags" )
project.resetModificationFlags()
}
}
override func updateChangeCountWithToken(
changeCountToken:AnyObject,
forSaveOperation saveOperation:NSSaveOperationType
) {
println( "updateChangeCountWithToken:forSaveOperation:" )
let before = documentEdited
super.updateChangeCountWithToken( changeCountToken, forSaveOperation:saveOperation )
let after = documentEdited
println( "Before=\(before); after=\(after)" )
project.resetModificationFlags()
}
I start my app and type some junk in the main window’s text view, where Undo works, then save.
updateChangeCount: is never called, ever. I expected it to be called upon changing text in the text view and again upon saving.
updateChangeCountWithToken:forSaveOperation: is called after saving, but the “before" and “after" flags are both FALSE, meaning that my typing in the text view didn’t cause the document to be marked as edited.
Here’s the way I thought things worked: the first time you type into a text view, it needs to get an undo manager in order to put the change on its undo stack. Unless you do something special, it will get the window’s undo manager, which will also (for a document window) be the document’s undo manager. So I thought I’d be dealing with exactly one undo manager. When the undo stack contains operations, the change count is non-zero, and the document knows it has been edited.
Somehow, that’s not all true for me. At the time updateChangeCount:forSaveToken: is called, the document’s undoManager property returns a value: an undoManager with zero levelsOfUndo, which may mean it’s going unused. The text view’s undoManager property returns nil.
I already tried plugging the document’s undoManager into the text view after the NIB loads, but the text view’s undoManager property isn’t directly settable.
As a text editor, shouldn’t my app have just one undo manager for each Document, one that works for the document window and the text view contained within it? If so, how do I configure that?
—
Charles
On April 29, 2015 at 10:19:22 AM, Uli Kusterer (email@hidden) wrote:
On ٢٩/٠٤/٢٠١٥, at ١١:٠٨, Charles Jenkins <email@hidden> wrote:
I think it most likely I’m doing this in the wrong place. But what’s the right place? Overriding NSDocument’s setFileModificationDate() would seem like the best way, but the NSDocument Programming guide says messages are sent to setFileURL:, setFileType: and setFileModificationDate: “if appropriate,” so I’m not sure I can count on getting that message.
I don't think that's a good spot, as it isn't explicitly connected to file saving. I'd try updateChangeCount: instead, and check for NSChangeCleared.
Also, keep in mind that "Save to..." and the likes also may get used on your document, saving to a different file but (IIRC) leaving the original document dirty. Maybe I'm misremembering what they do, but all those definitely need testing.
-- Uli
http://stacksmith.org
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden