> On 2014 Nov 23, at 19:44, Graham Cox <graham....@bigpond.com> wrote:
> 
> In my document-based app I'm seeing the following which does not occur on 
> 10.9 or earlier.
> 
> I create a new document, dirty it by adding some content, then manually save 
> it as a new file. The document's -updateChangeCount: method is called with a 
> change of NSChangeDone.

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?

> Has anyone else noticed this?

I just checked this in one of my NSPersistentDocument apps.  -updateChangeCount 
does *not* get called during a save operation.  My answer is “no”.

>  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":

#if 0
#warning overrode willChangeValueForKey.  Do not ship this.
/*!
 @brief    In a Core Data document-based application, you
 often have the problem of the close button getting a dirty
 dot immediately after a new document is created or an old
 one loaded, or you just want to know what the hell is
 happening when you click "Undo" and nothing happens.
 Paste this code into the NSManagedObject subclass that you
 suspect may be changing, or even better, if you have a
 NSManagedObject parent class for all your subclasses
 paste it in there.  Activate the #if above, compile,
 and run your app so that the dot gets dirty.  Then click
 Undo until the dot becomes clean as you watch the console.
 Any changes to your model will be logged.
 
 @details  Thanks to Dave Fernandes for this idea!
 */
- (void)willChangeValueForKey:(NSString*)key {
        NSUndoManager* um = [[self managedObjectContext] undoManager] ;
        // Todo: Since NSUndoManager is not thread-safe, should create
        // an NSInvocation here and invoke these next two on main thread:
        BOOL isUndoing = [um isUndoing] ;
        BOOL isRedoing = [um isRedoing] ;
        if (isUndoing || isRedoing) {
                NSLog(@"%@ %@did changed value for key: %@",
                          [[self entity] name],
                          isUndoing ? @"un" : @"re",
                          key) ;
                // Optional: Put a breakpoint here and debug to see what caused 
it
                ;
        }
        [super willChangeValueForKey:key];
}
#endif
_______________________________________________

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

Reply via email to