• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSDocument with fixed/auto-generated filename
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSDocument with fixed/auto-generated filename


  • Subject: Re: NSDocument with fixed/auto-generated filename
  • From: Lon Giese <email@hidden>
  • Date: Fri, 2 Jun 2006 13:49:18 -0700

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@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden


This email sent to email@hidden


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >NSDocument with fixed/auto-generated filename (From: James Bucanek <email@hidden>)

  • Prev by Date: Re: Newbie error
  • Next by Date: Re: NSDocument with fixed/auto-generated filename
  • Previous by thread: NSDocument with fixed/auto-generated filename
  • Next by thread: Re: NSDocument with fixed/auto-generated filename
  • Index(es):
    • Date
    • Thread