Re: Modifying the save path in an NSDocument based application
The answer, if anyone else is thinking of answering this question, is to use
NSFileWrapper - ensuring that Document is distributed as a bundle is
unchecked for the folder that you generate.
Simples. And my apologies to all here for not investigating further before
posting a question.
On 18 Sep 2013, at 20:54, Pax 45rpmli...@googlemail.com wrote:
Okay, the plot thickens. I've now updated my app for the app store -
sandboxing is now enabled. Sandboxing breaks the save path modification,
and particularly my creation of a folder:
if(![fileManager createDirectoryAtPath:directory
withIntermediateDirectories:NO
attributes:nil
error:error])
{
NSLog(@Failed to create directory \%@\. Error: %@ - this
save will most likely fail entirely., directory, error);
}
else
{ ... }
With sandboxing enabled, the creation of the directory always fails - unless
the user opts to save in the Downloads directory. Most odd.
The user can choose to save an undecoded version of the file wherever they
like. I have set read/write access for the Downloads Folder - which probably
explains this. How can I get read/write access to wherever the user chooses
to extract the files (most likely Documents, loose in their home folder, or
the desktop?)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
Okay, the plot thickens. I've now updated my app for the app store -
sandboxing is now enabled. Sandboxing breaks the save path modification, and
particularly my creation of a folder:
if(![fileManager createDirectoryAtPath:directory
withIntermediateDirectories:NO
attributes:nil
error:error])
{
NSLog(@Failed to create directory \%@\. Error: %@ - this
save will most likely fail entirely., directory, error);
}
else
{ ... }
With sandboxing enabled, the creation of the directory always fails - unless
the user opts to save in the Downloads directory. Most odd.
The user can choose to save an undecoded version of the file wherever they
like. I have set read/write access for the Downloads Folder - which probably
explains this. How can I get read/write access to wherever the user chooses to
extract the files (most likely Documents, loose in their home folder, or the
desktop?)
On 17 Sep 2013, at 15:20, Jerry Krinock je...@ieee.org wrote:
On Sep 17, 2013, at 07:49:56, Pax 45rpmli...@googlemail.com
wrote:
I thought that this would be nice and simple
No. Overriding anything in the AppKit document architecture is playing with
fireworks, especially since Auto Save and Versions. To be safe, when you're
done, retest all of the functions: Duplicate, Rename, Move To, Browse All
Versions, etc., in all OS X versions you're deploying to.
On 2013 Sep 17, at 06:41, Steve Mills smi...@makemusic.com wrote:
You might try overriding
saveToURL:ofType:forSaveOperation:completionHandler: instead. writeToURL is
at a very low level in the save operation, and if you look at the stack, I
bet writeSafelyToURL:ofType:forSaveOperation:error: is one of the callers of
writeToURL.
Steve's advice looks good to me. For a picture of the Save operation, in
Xcode's Documentation browser, check out
Document-Based app Programming Guide for Mac Alternative Design
Considerations Message Flow in the Document Architecture Saving A
Document Figure 6-6 at the bottom of the page
Supposedly this document has recently been updated to reflect Auto Save and
Versions, but I haven't verified that.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/45rpmlists%40googlemail.com
This email sent to 45rpmli...@googlemail.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
On Sep 17, 2013, at 07:49:56, Pax 45rpmli...@googlemail.com wrote: I have a slightly odd requirement in that I need to modify, under certain circumstances, the save path used for an NSDocument based application. The reason for this is that I may, depending on the format chosen by the user, need to unpack the data into multiple files. Under this circumstance, I want to create a folder at the location specified by the user, with the name of the source file (less the extension) as the folder name, and then I'll unpack the source file into this directory. I thought that this would be nice and simple - but it seems that the URL used when saving is an intermediate URL. My file doesn't get created at the final destination location (and, because it doesn't, I can't easily modify the path). What I planned to do is this: - (BOOL)writeToURL:(NSURL *)url ofType:(NSString *)inTypeName error:(NSError **)outError When I check url I get something like file://localhost/private/var/folders/6w/6dmwl9c938g4m94jm7s_8ml8gn/T/TemporaryItems/(A%20Document%20Being%20Saved%20By%20Extractor)/Christmas.ext You might try overriding saveToURL:ofType:forSaveOperation:completionHandler: instead. writeToURL is at a very low level in the save operation, and if you look at the stack, I bet writeSafelyToURL:ofType:forSaveOperation:error: is one of the callers of writeToURL. What that does is first write the file to a temp file, then if all goes well, moves it to the actual location, replacing the original file if it exists. So you'll want to let that happen. But up in saveToURL you should be able to point it to your new dir at a higher level, before writeSafelyToURL does its thing. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
On Sep 17, 2013, at 07:49:56, Pax 45rpmli...@googlemail.com wrote: I thought that this would be nice and simple No. Overriding anything in the AppKit document architecture is playing with fireworks, especially since Auto Save and Versions. To be safe, when you're done, retest all of the functions: Duplicate, Rename, Move To, Browse All Versions, etc., in all OS X versions you're deploying to. On 2013 Sep 17, at 06:41, Steve Mills smi...@makemusic.com wrote: You might try overriding saveToURL:ofType:forSaveOperation:completionHandler: instead. writeToURL is at a very low level in the save operation, and if you look at the stack, I bet writeSafelyToURL:ofType:forSaveOperation:error: is one of the callers of writeToURL. Steve's advice looks good to me. For a picture of the Save operation, in Xcode's Documentation browser, check out Document-Based app Programming Guide for Mac Alternative Design Considerations Message Flow in the Document Architecture Saving A Document Figure 6-6 at the bottom of the page Supposedly this document has recently been updated to reflect Auto Save and Versions, but I haven't verified that. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Modifying the save path in an NSDocument based application
Thanks Jerry, Thanks Steve, You guys rock! If you're ever in London I definitely owe you beer! On 17 Sep 2013, at 14:41, Steve Mills smi...@makemusic.com wrote: You might try overriding saveToURL:ofType:forSaveOperation:completionHandler: instead. writeToURL is at a very low level in the save operation, and if you look at the stack, I bet writeSafelyToURL:ofType:forSaveOperation:error: is one of the callers of writeToURL. What that does is first write the file to a temp file, then if all goes well, moves it to the actual location, replacing the original file if it exists. So you'll want to let that happen. But up in saveToURL you should be able to point it to your new dir at a higher level, before writeSafelyToURL does its thing. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
