exception in code upgraded to use MappedFile instead of StdFile

69 views
Skip to first unread message

arbarnhart

unread,
Jan 2, 2015, 7:26:45 AM1/2/15
to pdfne...@googlegroups.com

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

unread,
Jan 2, 2015, 1:00:23 PM1/2/15
to pdfne...@googlegroups.com
If you're trying to write the filter to disk, may want to try using Filter::WriteToFile instead:


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




arbarnhart

unread,
Jan 5, 2015, 10:40:41 AM1/5/15
to pdfne...@googlegroups.com
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

unread,
Jan 5, 2015, 3:42:34 PM1/5/15
to pdfne...@googlegroups.com
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

unread,
Jan 6, 2015, 10:36:51 AM1/6/15
to pdfne...@googlegroups.com
I tried calling Dispose() on each Filter, the NameTree and the Collection. It is still holding a handle open.

Ryan

unread,
Jan 6, 2015, 2:28:00 PM1/6/15
to pdfne...@googlegroups.com
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.
PDFPackageTest.cs

arbarnhart

unread,
Jan 7, 2015, 11:39:13 AM1/7/15
to pdfne...@googlegroups.com
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

unread,
Jan 7, 2015, 2:06:05 PM1/7/15
to pdfne...@googlegroups.com
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.
Reply all
Reply to author
Forward
0 new messages