> On 24 Nov 2014, at 12:55 pm, Jerry Krinock <je...@ieee.org> wrote: > > To clarify the issue: -updateChangeCount: is called, as expected, when you > dirty the document. It is called again when you save the document, > apparently just after you save the document, because > >> This causes the document to be flagged as dirty, prompting the "Save >> changes?" dialog when it's closed (if that is enabled). > > > It is the second call to -updateChangeCount:, which occurs during/after the > save, that is the issue. Have I understood correctly?
Yes. The -updateChangeCount: mechanism is working normally for genuine changes, which are sent as the result of a notification from the undo manager. I'm getting an extra one after the save completes, but only for the first save, and only if it creates a new file rather than overwriting an existing one. >> It doesn't seem as if I'm doing anything wrong as we're not seeing this >> except on 10.10 > > See if it’s putting an action on the undo stack. If that is too opaque, > which it will probably will be if app is Core Data, consider the "Dave > Fernandes Override -willChangeValueForKey: Trick": It's not. A change from the undo manager has a completely different stack trace, where the undo manager sends a synchronous notification via NSNotificationCenter. This one seems to be something in the run loop (a queued task?) triggering a direct call to -[NSDocument _checkAutosavingThenUpdateChangeCount:]_block_invoke_2 () which is most definitely something internal and private and not something my code has (knowingly) set up. --Graham _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
