exception in code upgraded to use MappedFile instead of StdFile

[arbarnhart]

I posted about a problem with failing on open because the file didn't exist the other day but haven't heard anything yet. StdFile took a second parameter for the open mode I pressed on and tried creating the file myself. That makes it further but gets an exception when I Flush the FilterWriter before closing it.

                            FilterReader reader = new FilterReader(stm);

                            string fname = _ExtractDirectory + entry_name;

                            File.Create(fname).Close();

                            MappedFile f = new MappedFile(fname); //, MappedFile.OpenMode.e_write_mode);

                            FilterWriter writer = new FilterWriter(f);

                            writer.WriteFilter(reader);

                            writer.Flush();

Exception: {"Exception: \n\t Message: Output stream is corrupt\n\t Conditional expression: false\n\t Filename   : FilterWriter.cpp\n\t Function   : trn::Filters::FilterWriter::WriteFilter\n\t Linenumber : 104\n"}

hResult: -2146233088

[Aaron]

If you're trying to write the filter to disk, may want to try using Filter::WriteToFile instead:

https://groups.google.com/d/msg/pdfnet-sdk/4Fi53W8R-vY/oy-FJJ5WOa0J

If that doesn't help, could you try explaining a little more about your use case?  What are you trying to accomplish?

[arbarnhart]

That helps but I run into a different problem later. The use case is a portfolio PDF. If I find the Object "Collection", I iterate through the NameTree "EmbeddedFiles" in the "Collection" Object and write out each of the embedded PDF files into separate temporary files. In the previous version I used the old code that gave me trouble when I tried to convert to using MappedFile instead of StdFile. Using WriteToFile makes that much simpler and that part seems to work fine; I am getting all of my embedded files written to temporary files and can open and edit them. But the main file is left with a lock on it; I get an error in my code that opens it for writing to be sure I will be able to save. No other process has the file open; it is something in the library not closing out. If I just open a PDF that has no "Collection" Object, I don't have this problem. I am trying adding Disposes to various objects to see if I can clear this up.

[Ryan]

The Filter stream is keeping a handle open on the source document (PDF Package document in this case).

You can either call Filter.Dispose() after calling WriteToFile, or wrap in a using statement.

For example, based on the PDFPackageTest.cs file.

FileSpec file_spec = new FileSpace(i.Value());
using(Filter stm = file_spec.GetFileData())
{

...

}

[arbarnhart]

I tried calling Dispose() on each Filter, the NameTree and the Collection. It is still holding a handle open.

[Ryan]

Attached is a modified version of PDFPackageTest that triggers disposal on the filters, which works fine as far as I can tell. Hopefully it will help you solve your code.

[arbarnhart]

It is turning out to be more complicated than I originally thought. If I go through an open->close cycle on a PDF document, the next time I do it a handle will be left open. It turns out that if I try opening a PDF that isn't a portfolio, close it and then reopen it a second time and close it again, the handle will be left open. This is in code that was unchanged from bringing the project forward from 5.9.0. If I go through the same sequence in 5.9.0, it works. In 6.3.0, it does not. I will try to narrow it down a bit because "opening" a file is not a single operation. I mean opening and getting a lot of data. I am going to try working around this by getting the handle I need earlier in the process.

[Ryan]

Double check the PDFNet classes you are using, and see if they have a dispose method, if so, you would want to call Dispose on those explicitly, or put them in a using statement. Otherwise, you are relying on the GC to trigger that for you, and that typically happens a lot later then you would expect.