Re: NSDocument with fixed/auto-generated filename

FROM : Lon Giese
DATE : Fri Jun 02 22:49:18 2006

I have exactly the same problem: how to cleanly short circuit the save 
panel.
I have exactly the same problem: menu validation is not working 
properly.

I posted these questions about a week or two ago and no one knows the 
answer.

Based on the silence I am presuming that the document architecture is 
1) bugged and 2) not well thought out in some areas or maybe it was 
designed only for simple situations.

For example, until OS X 10.4 there was not a straight forward method to 
init a new document of any complexity. I thought I was not 
understanding the docs and when I saw that I realized I was perfectly 
understanding the docs, and had stumbled across a limitation of the 
architecture.

I have not yet tackled the menu validation work a round. (other than 
override and not call super's  implementation)


Apart from a menu action (which you disabled)  the architecture closes 
a document and possibly brings up a save panel in two ways. #One, 
closing a window, #Two user quitting (or log out which is a whole 
nuther can of worms). Both events process a little differently.

When closing a window the window calls:

NSDocument's 
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:
( to stop some one from arguing with me I will say there is a similar 
method called first in the window controller but were not concerned 
with that here)

to prevent situation # 1 over ride this method in your NSDocument 
subclass:

canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:

you can safely ignore the should close selector and the window will not 
care (To stop another argument : I know this is not good style, but 
this is a work around due to deficiency in the doc architecture, and 
until apple obliges us, we gotta do what we gotta do)

in this method

1) save your document they way you want
2) make sure the doc dirty flag is not dirty
3) [super 
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:] ( super 
calls the shouldCloseSelector for you)
- or  -
1) save you document they way you want and call
2) [self close]  - this always closes a document - no matter what 
(shouldCloseSelector is not called)

//document is released - window closes
end of story - no save panel - everybody's happy


Problems arise when the users quits from the menu

this same method is now called by NSDocumentController

NSDocument's 
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:

is called again, but, you CANNOT ignore the shouldCloseSelector or else 
the application menu will lock up in certain situations.

to prevent situation # 2 over ride this method again
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:

1) save your document the way you want
2) clear the dirty flag
//call super
3) [super 
canCloseDocumentWithDelegate:shouldCloseSelector:contextInfo:] ( super 
calls the shouldCloseSelector for you)
// document is released - application quits


You may be saying the two are exactly the same! Yes! but only for the 
simplest situation. If for some reason the document is not in a savable 
condition, for instance some important field has not been filled in yet 
because you are taking a non-linear approach or several fields are 
interdependent and have to be validated as a group. Then things get 
tricky real fast and it makes a difference if the user is quitting or 
closing a window. If you want to know how I worked around that ask 
again.

I think the document architecture was designed for documents where it 
doesn't matter if it is saved in an incomplete state, like a 
spreadsheet or word doc, etc.  But in your case, and my case, saving an 
incomplete document may be unacceptable.


WooHoo the ultimate Mac App for 'The Sims 2' power users.
http://www.modthesims2.com/showthread.php?p=1239629
On Jun 2, 2006, at 9:56 AM, James Bucanek wrote:

> Greetings,
>
> I'm obviously doing something wrong. I have an NSDocument subclass 
> that allows a user to edit a "settings" file. The user can have 
> multiple settings documents.
>
> I want the document to behave exactly like any other document (new, 
> open, close, save, undo, revert, ...) EXCEPT for the single fact the 
> the user doesn't get to name the document. These "settings" files are 
> stored in a pre-defined folder in the user Preferences and their name 
> and window titled are derieved from the settings themselves. The name 
> of the file is auto-generated when the user saves the document.
>
> So, how I can create an NSDocument that behaves like any other 
> NSDocument, it just never asks the user to name the document or where 
> they'd like to save the file?
>
> I *thought* I could do this by simply
>
> 1) Disabling the Save As... command in validateMenuItem:
>
> 2) Overriding -[NSDocument saveDocument:]. In it I check to see if the 
> file for this document already exists. If not, I generate a unique 
> filename and write the file. If it does already exist, I simply call 
> [super saveDocument:].
>
> However, I'm having all manor of oddball problems and behaviour. If, 
> for example, I open an existing document, modify it, and issue a Save 
> command I often get a "The location of the document "xxx" cannot be 
> determined" warning with a Save As... button (Huh??????).
>
> Also, the isDocumentEdited/Save/Revert/Undo menus aren't behaving 
> themselves. After a save (even to an existing file) the Save, Revert, 
> and Undo commands are still active. I tried to hack that by managing 
> the Save menu myself and adding [[self undoManager] removeAllActions]; 
> [[self window] setDocumentedited:No]; [self 
> updateChangeCount:NSChangeCleared]; to the end of the saveDocument: 
> method. But even that isn't acting quite right, and I suspect that 
> it's not happening automatically becuase I've short-circuited 
> something somewhere.
>
> -- 
> James Bucanek
>  _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list      (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/
> <email_removed>
>
> This email sent to <email_removed>
>