On Windows, if I open an existing PDF file and let PDFTron handle the Properties dialog from within the control if the user sets a password then when I save I will get an exception - “Compressed object is corrupt” - every single time with any PDF file.
Hi can you please provide more details.
What platform/language are you using?
What version of PDFNet
Does this occur in our SDK sample project or only your own?
Exact steps to reproduce.
If you wrote your own code, then include related code, including showing the password string being passed in.
Windows, C#, PDFNett DLL version is 6.5.2.33480
Windows can be 7, 8 or 10. Can you point me at the best sample to use? Our app creates a new PDFDoc object using the file, call InitSecurityHandler and sets the document as the document in a PDFViewControl which handles the property window and when we save we pass in SDFDoc.SaveOptions.e_remove_unused. There is other code I am stepping over that would save some additional data and it still happens but I need a simpler example.
One interesting thing I happened to notice is that the save seems to have completed and the password is set.
Are you modifying the document while it is being viewed in PDFViewCtrl? If so, then you need to lock the document for writing, as the viewer is running background threads which use the document.
pdfviewctrl.DocLock(); // get write lock ..... pdfviewctrl.DocUnlock();// release lock
See here for more info
https://groups.google.com/d/msg/pdfnet-sdk/pDZsqrjCEdg/HYvfg_R4LUIJ
In the test case, the only modification done was done by the built in Properties dialog.
The info you just sent me to says:
Conversely, if you are happy with the existing ‘one document, one thread’ model previously used in PDFNet 5.9., you can continue to work with this system. No change is required on your behalf.
Single thread is fine for our application.
There is more to the story; I was getting confused about where exactly it crashes. It saves okay and then gets the crash on reopen. the reason it does that is we save to a temp file and only delete and copy over original if successful. It crashes on InitSecurityHandler. But if I restart, it works okay. So I suspect my logic now; sorry to bother…
That line is in reference to the case where you are doing everything your self, and not using PDFViewCtrl.
For example, if you wanted to convert all pages to a PNG, you could do it single threaded, with no locking, or do multiple pages simultaneously using the lock API.
However, if you are using PDFViewCtrl to view the PDFDoc object, and you are also using the PDFDoc object (either read or write) at the same time, then you need to use the locking API. PDFViewCtrl operates mostly in background/worker threads.