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

Reply via email to