Re: Why does NSDocument do this? [resolved]
Re: Why does NSDocument do this? [resolved]
- Subject: Re: Why does NSDocument do this? [resolved]
- From: Graham Cox <email@hidden>
- Date: Fri, 22 Nov 2013 13:47:23 +0100
OK, I got it figured out. It was my fault of course, but an extremely complicated bug to unravel!
I have an object that listens for notifications from another object much higher up the object graph (at the document level). If this object is added while the document is open, this notification is set up correctly, but during dearchiving, the originating object isn’t yet available, so the notification was being set up with a value of nil, meaning it would accept any similar notification from any object.
Normally when the notification is received, there is a state change which is undoable. During dearchiving, the undo manager is disabled, so in theory this change is ignored. Normally I dearchive data members directly, but for this one, it has a bunch of associated setup, so it calls the setter method, which also wraps the undo preparation.
When a file finishes dearchiving and the document is fully constructed, the notification is sent, which is now picked up by ALL objects that want it, because the observation was added with nil. This causes similar objects in other files that have finished opening and have re-enabled undo to record an undo change, which subsequently dirties THAT document. Basically the notification setup was creating a web of cross-linked dependencies between files, which is why reverting one file seemed to dirty another.
Another pitfall to watch out for with NSNotificationCenter and threads, I guess. Lesson learned.
—Graham
On 22 Nov 2013, at 12:50 pm, Graham Cox <email@hidden> wrote:
> Opening files concurrently.
>
> When I open a single file, it opens fine and shows up initially unedited (not dirty), as expected.
>
> If I open several files by choosing multiple items in the NSOpenPanel, some of them get dirtied when they open.
_______________________________________________
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