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”}
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.
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.
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.
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.