• 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: 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
  • Follow-Ups:
    • Re: NSDocument with fixed/auto-generated filename
      • From: Erik Buck <email@hidden>
    • Re: NSDocument with fixed/auto-generated filename
      • From: James Bucanek <email@hidden>
References: 
 >Re: NSDocument with fixed/auto-generated filename (From: Erik Buck <email@hidden>)

  • Prev by Date: Re: saveDocument newbie question
  • Next by Date: Noob question with printf error
  • Previous by thread: Re: NSDocument with fixed/auto-generated filename
  • Next by thread: Re: NSDocument with fixed/auto-generated filename
  • Index(es):
    • Date
    • Thread