From: Christiaan H. <cmh...@gm...> - 2009-03-18 19:16:07
|
On Wed, Mar 18, 2009 at 7:56 PM, Christiaan Hofman <cmh...@gm...>wrote: > > On 18 Mar 2009, at 7:40 PM, Maxwell, Adam R wrote: > > On 03/18/09 11:29, "Christiaan Hofman" <cmh...@gm...> wrote: >> >> On Wed, Mar 18, 2009 at 7:23 PM, Maxwell, Adam R <ada...@pn...> >>> wrote: >>> >>>> On 03/18/09 11:17, "Christiaan Hofman" <cmh...@gm...> wrote: >>>> >>>> So this means that without _FVMappedDataProvider there's no need for >>>>> it? I >>>>> removed that because it was locking the PDF file. >>>>> >>>> >>>> What do you mean by "locking the PDF file"? >>>> >>> >>> The file is marked as opened, and you can't delete or modify it. >>> >> >> I can't reproduce this with my test program. I can rename, delete, and >> modify the file. >> >> > You're right that it can be deleted and modified. However, it /is/ listed > as open. Moreover, I wonder if the data provider doesn't run into trouble > when you do any of this? Is it really a good idea to map a file for a long > time when you're not really opening the file? > > Christiaan > > Correction, the trash refuses to permanently delete the file when it's linked in BD. This goes away with CFDataProviderCreateWithData. The caching and icon code is copied directly from googlecode. Anyway, I doubt it's right to keep a hold on the file. So still my question whether _FVSplitSet is relevant without it? And should any pdfDoc be released? Christiaan |