On Feb 5, 2013, at 3:08 PM, Steve Mills wrote: > On Feb 5, 2013, at 15:12:43, Markus Spoettl <ms_li...@shiftoption.com> wrote: > >> I don't think it's meant to be overridden that way because the framework >> doesn't realize that the state has changed. You should probably call >> -setDocumentEdited: instead, or, as an alternative, implement undo and use >> an NSUndoManager which manages this stuff for you. > > From the docs for setDocumentEdited: > > "The window controller uses this flag to control whether its associated > window shows up as dirty. You should not call this method directly for window > controllers with an associated document; the document calls this method on > its window controllers as needed." > > As far as undo goes, we have our own cross-platform undo system and menu > items, so I don't see us implementing Cocoa's undo on top of that, and we > shouldn't be expected to. This is supposed to be what isDocumentEdited is > for. I'm not sure why it's not working for some cases. > > -
There's probably a KVO observer on isDocumentEdited; if nothing triggers setDocumentEdited then it doesn't know to check it. updateChangeCount: says If you are implementing undo and redo in an application, you should increment the change count every time you create an undo group and decrement the change count when an undo or redo operation is performed. Note that if you are using the NSDocument default undo/redo features, setting the document’s edited status by updating the change count happens automatically. You only need to invoke this method when you are not using these features. _______________________________________________ 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