On 23 Aug 2012, at 14:12, Markus Spoettl <ms_li...@shiftoption.com> wrote:
> I have an NSDocument based app that has uses packages do to store a complex
> structure.
>
> When I open a document, I keep the wrapper around handed to the document in
>
> -readFromFileWrapper:ofType:error:
>
> in order to lazy-load parts of the package when my app needs them. Similarly,
> I keep the wrapper when saving (which is the same object unless it's a new
> document that didn't have a wrapper before). And here the trouble starts.
>
> When I try to lazy-load package files after saving by requesting
> -regularFileContents on the corresponding wrapper that are located somewhere
> down the wrapper hierarchy, they are still available (meaning the sub-wrapper
> objects are there) but the content returned is nil.
>
> The documentation states that this can happen when the user moves the file
> after the wrapper has been created. I suspect that this is a side effect of
> safe-saving, which writes temporary files and moves them into place when
> everything worked out correctly.
>
> I'm fixing this by calling -readFromURL:options:error: on the document
> package's root wrapper in the completionHandler of NSDocument's
>
> -saveToURL:forSaveOperation:completionHandler:
>
> before calling the original completionHandler (I'm pasting the relevant code
> below).
>
> As it's not mentioned in the documentation anywhere (meaning saving packages
> will invalidate wrappers), it doesn't feel quite right. I've been using this
> a couple of months now without adverse effects, though.
>
> I'm wondering this is expected behavior and/or if there's a better way to
> make sure the wrapper points to the right place once saving is complete.
>
> I'm using the 10.7 SDK.
>
> Regards
> Markus
>
> - (void)saveToURL:(NSURL *)url ofType:(NSString *)typeName
> forSaveOperation:(NSSaveOperationType)saveOperation
> completionHandler:(void (^)(NSError *))completionHandler
> {
> [super saveToURL:url ofType:typeName
> forSaveOperation:saveOperation
> completionHandler:^(NSError *error) {
>
> if (error == nil) {
> [rootFileWrapper readFromURL:url options:0 error:&error];
> }
>
> completionHandler(error);
> }];
> }
Hi Markus,
It seems you're right; this is a side-effect of how NSDocument does
safe-saving. If the file wrappers internally hold onto the URL they were last
written to, that's no good if the file moves out underneath them. To cope
they'd have to be using a bookmark or file reference URL instead. Apple might
well be doing so in 10.8 or a later OS, but if you need to target 10.7, that
doesn't help!
I'd make two changes to your routine:
* Instead override -writeSafelyToURL:…. This is the method that's actually
responsible for doing the special file-handling
* You probably only want to ask the file wrapper to re-read if the operation is
a regular Save, Save As, or Autosave-in-place. For others, you want to remain
pointing at the original URLs I believe
One other question though, what does your writing code look like? Are you
overriding one of the -write… methods? Or implementing -fileWrapperOfType:… ?
_______________________________________________
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
