Re: Unexpected extra "change" notification in 10.10
Re: Unexpected extra "change" notification in 10.10
- Subject: Re: Unexpected extra "change" notification in 10.10
- From: Jerry Krinock <email@hidden>
- Date: Sun, 23 Nov 2014 20:55:58 -0500
> On 2014 Nov 23, at 19:44, Graham Cox <email@hidden> 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 (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