Re: NSDocument with fixed/auto-generated filename
Re: NSDocument with fixed/auto-generated filename
- Subject: Re: NSDocument with fixed/auto-generated filename
- From: Martin Redington <email@hidden>
- Date: Tue, 20 Jun 2006 04:02:23 +0100
I have pretty much exactly the same problem as Lon and James.
I would like to provide a default name for the document, and avoid
the user having to see the Save Panel.
In an ideal world, I would simply be able to call setFileName or
setFileURL on the NSDocument, and then call saveDocument: to write it
out.
According to the saveDocument: comments,
"The default implementation saves the document in two different ways,
depending on whether the document has a file path and a document type
assigned. ***If path and type are assigned, it simply writes the
document under its current file path and type after making a backup
copy of the previous file***. If the document is new (no file path
and type), it runs the modal Save panel to get the file location
under which to save the document. It writes the document to this
file, sets the document’s file location and document type (if a
native type), and clears the document’s edited status."
So it would seem that according to the docs, this should do exactly
what I want. I'm not keen to ditch the NSDocument framework, in order
to get, what seems to me, to be a fairly simple variation.
As it stands, when I call saveDocument: having set the fileName/URL
(fileType) is correctly set as well, I get "The location of the
document "DocumentName" cannot be determined", with Cancel and Save
As options.
I also get the disabled Save Menu that other people have reported.
Any pointers on how to programmatically set the filename and save the
file without user intervention would be great. Note that I would
still like Save As, and Save to be operational.
On 2 Jun 2006, at 23:49, Erik Buck wrote:
It should go without saying that if you don't want most of the
behavior build into NSDocument, don't use it. The TextEdit.app
sample application that is distributed with
Apple’s Cocoa developer tools is an example of a multidocument
application that
does not use the multidocument-support classes. The Sketch.app
sample does use the
built-in multidocument support. Examining TextEdit.app’s source
code and compar-
ing it to Sketch.app is a good way to contrast the different
approaches to multidocu-
ment support.
I recommend that if you want to take over document saving so that
documents are auto-saved or validated before saving you should
implement -(NSApplicationTerminateReply)applicationShouldTerminate:
(NSApplication
*)anApp to do what you want and possibly even delete the "Save" and
"SaveAs" menu items via Interface Builder.
"Cocoa Programming" ISBN 0672322307 contains a chapter that
explains the way NSDocument works and re-implements a similar
system just for educational purposes in Chapter 9.
From the book:
As a general rule, the built-in classes save a lot of work and
ensure a high degree of
compatibility and consistency with other applications. Using the
NSDocument and
NSDocumentController classes can also simplify the implementation
of scripting and
undo features in applications.
A certain amount of support for multidocument applications is built
into the
NSApplication class. NSApplication provides delegate methods that
enable
customization of standard application behaviors regarding multiple
documents. For
example, Mac OS X applications that support multiple documents are
expected to
open a new untitled document under some circumstances. The
–applicationShouldOpenUntitledFile:delegate method can be
implemented in an
application object’s delegate to control that behavior. The
following delegate
methods are provided to enable the application object’s delegate to
control multi-
document behavior without using the built-in multidocument support
classes:
-(BOOL)application:(NSApplication *)anApp
openFile:(NSString *)filename
-(BOOL)application:(NSApplication *)anApp
openFileWithoutUI:(NSString *)filename
-(BOOL)application:(NSApplication *)anApp
openTempFile:(NSString *)filename
-(BOOL)application:(NSApplication *)anApp
printFile:(NSString *)filename
-(BOOL)applicationOpenUntitledFile:(NSApplication *)anApp
-(BOOL)applicationShouldHandleReopen:(NSApplication *)anApp
hasVisibleWindows:(BOOL)flag
-(BOOL)applicationShouldOpenUntitledFile:(NSApplication *)anApp
-(NSApplicationTerminateReply)applicationShouldTerminate:
(NSApplication
*)anApp
-(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication
*)anApp
The NSApplicationclass implements most of the standard behaviors
expected of
multidocument classes without intervention by its delegate. The
delegate methods
should only be used when there is a need to deviate from the
standard behaviors. If
the Application Kit’s classes for supporting multidocument
applications are used, the
delegate methods are almost certainly unnecessary
...
The MYDocumentManager class implements the following application
delegate
methods:
- (NSApplicationTerminateReply)applicationShouldTerminate:
(NSApplication *)sender;
- (BOOL)application:(NSApplication *)sender openFile:(NSString *)
filename;
- (BOOL)applicationShouldOpenUntitledFile:(NSApplication *)sender;
- (BOOL)applicationOpenUntitledFile:(NSApplication *)sender;
The -applicationShouldTerminate:method is implemented to check for any
unsaved documents and give users a chance to save them. The
-application:openFile:method is implemented to open documents when
they are
double-clicked in Finder or dropped on an application icon.
Finally, the
-applicationShouldOpenUntitledFile:and -applicationOpenUntitledFile:
methods control how the application handles untitled documents.
The MYDocumentManager class works closely with the NSApplication
class to imple-
ment features that users expect from multidocument applications.
Because an
instance of the MYDocumentManager class is the delegate of the
NSApplication
instance, the document manager is automatically added to the
responder chain and
can receive action messages sent up the responder chain.
MYDocumentManager imple-
ments three actions that are sent by user interface objects such as
menu items:
-newDocument:, -openDocument:, and –saveAllDocuments:. The
MYDocumentManager
instance receives these action messages when user interface objects
send them up the
responder chain and no other object handles them.
MYDocumentManageralso imple-
ments the -documentWillClose: and -makeDocumentActive: actions that
are sent up
the responder chain by NSDocument instances.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40ucl.ac.uk
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