Re: NSDocument with fixed/auto-generated filename
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