• 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: Handling unpresented files with NSDocument
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling unpresented files with NSDocument


  • Subject: Re: Handling unpresented files with NSDocument
  • From: "email@hidden" <email@hidden>
  • Date: Thu, 04 Aug 2016 18:43:59 +0700

> On Aug 4, 2016, at 12:04 PM, Quincey Morris <email@hidden> wrote
>
> I went back to your original question, and read it a bit more carefully. The answer to this is “Yes!”, I think. When your NSDocument loading override is handed a file wrapper, you do not need to represent the audio files in your data model, nor do they need to be read into memory at all, unless you choose to do so. Just leave the audio file sub-wrappers alone, and keep the uber-wrapper around until save time. (What I usually do is delete the sub-wrappers for files that *are* changing, as edits are made. At save time, the absence of a file wrapper tells me I need to write out a new file and create its new sub-wrapper.) When you take that approach, the files with the untouched sub-wrappers should NOT need to be copied by the save**. Instead they are (atomically!) transferred to the new document package version representing the saved document.
>
> Isn’t that what you’re trying to achieve?
>
>
> ** Provided you are saving to a local HFS+ file system. Network disks and other file systems may not support this and require re-copying of the unchanged files.
>

Wow! I gave it a shot and it's working! I did have FileWrappers created for each audiofile but I created them new each time the fileWrapper(ofType:) function was called. Maybe that was the problem?

To suit my app, I now create an unmapped FileWrapper each time an audio file is imported and hold on to all of them in an array. This array then get's put in the main FileWrapper in my fileWrapper(ofType:) function.

Now, it wouldn't move the files when duplicating the document. But: Copying the FileWrappers over from document to document in the NSDocumentController's duplicateDocument(withContentsOf:copying:displayName:) function solved that, too. Maybe stuff will blow up on me this way, so more testing needs to be done, but this looks quite promising! Thanks so much!

Also, thanks for pointing out the file-system caveat. I'll have to test that in the near future.

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


References: 
 >Handling unpresented files with NSDocument (From: "email@hidden" <email@hidden>)
 >Re: Handling unpresented files with NSDocument (From: Quincey Morris <email@hidden>)
 >Re: Handling unpresented files with NSDocument (From: "email@hidden" <email@hidden>)
 >Re: Handling unpresented files with NSDocument (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Handling unpresented files with NSDocument
  • Next by Date: Need some NSComboBox debugging help
  • Previous by thread: Re: Handling unpresented files with NSDocument
  • Next by thread: NSCollectionViewItem lifecycle
  • Index(es):
    • Date
    • Thread