On 09/02/2011, at 1:46 PM, Sherm Pendley wrote: > On Tue, Feb 8, 2011 at 9:29 PM, Graham Cox <graham....@bigpond.com> wrote: >> I'm trying to prevent NSDocument from doing any saving at all, for a demo >> version of my app. I need to suppress the menu commands (done) and all the >> automated UI such as the 'save changes' dialog and 'Save As' dialog even >> though the doc is marked dirty. I've also removed the actual save code. >> >> According to the docs for >> -canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:, if I >> immediately pass YES to the should close selector, it should accomplish >> this. Indeed, it does suppress the "do you want to save changes?" dialog, >> but the window does not close. >> >> What's the proper way to do this? I searched the archives but surprisingly I >> couldn't find any previous discussion of this, even though I would have >> thought it's quite a common thing. > > If you've removed the actual save code, why not simply let Cocoa go > through the motions and call your (empty) save method? Seems like a > lot of unnecessary trouble to go through, just to make it avoid > calling a method that isn't going to do anything anyway...
Well, it's not a nice user experience. They go through all the motions of saving, only to be presented with an error. Better in my view to just not start that whole sequence, then it's clear that saving is not possible with this version. I have found I can simply return NO from -isDocumentEdited and that does the trick, but it has the additional effect of suppressing the dirty indication. That's almost acceptable, but I'd prefer that worked normally since it's tied in with having undoable actions and so on. I also tried overriding -shouldCloseWindowController:delegate:shouldCloseSelector:contextInfo: but that gave the same result - the window stays open. On a side note, these callbacks seem very weird - they pass the selector to call to you, but then also specify that they must be of a certain signature (document:shouldClose:contextInfo:). Isn't that a bit redundant? Or should I be building an invocation around the selector I'm given rather than assuming the signature? I tried that, and it crashes hard, so I'm guessing that's not a good idea. I don't understand why these callbacks are so convoluted instead of just asking for a simple YES or NO answer to be returned. --Graham _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
