Hosting IE 8 In WinForms And Opening A PDF File

Question

We have a form that hosts the WebBrowser control. This is the only control over the form.

We pass the form of the path to the temporary PDF file, and it:

WebBrowser1.Navigate(Me._PathToPdf) 

When the form closes, it moves away from the PDF file:

 WebBrowser1.Hide() WebBrowser1.Navigate("about:blank") Do Until WebBrowser1.ReadyState = WebBrowserReadyState.Complete Application.DoEvents() System.Threading.Thread.Sleep(50) Loop 

Once the form is closed, the calling class then deletes the temporary PDF file.

This process works fine ... until we installed Internet Explorer 8. For some reason, a combination of IE8 and Adobe Acrobat 8 ​​(or 9) forces the extra file lock descriptor to fit into a temporary PDF file. The additional lock handle does not disappear until the entire application is closed. I should also mention that there are no locks in the file until Acrobat opens the file.

We can reproduce this on several machines, and it is always a combination of IE8 and Adobe Acrobat Reader. We can install Foxit Reader 3 instead of Adobe Acrobat, and everything works fine. Similarly, we can run the application on a computer with IE7 and Adobe Acrobat, and everything works fine. But when you mix the magic potion of IE 8 and Acrobat, you are in a mess.

Can someone tell me why I get an extra file lock that persists until the end of the application?

Thanks.

An example application demonstrating my problem can be found here: PDFLockProblemDemo.zip

Answer 1

It seems to me that the real problems are using the WebBrowser to host the Adobe Reader web browser plugin to display PDF files. Isn't there a better way to display PDF files directly without introducing a dependency on a web browser? Does the Adobe SDK or ActiveX control support that you can place directly inside your form?

---

UPDATE: I looked around and found this post where they access the Adobe ActiveX control ( AxAcroPDFLib.AxAcroPDF ) and just call:

 axAcroPDF1.LoadFile("mypdf.pdf"); axAcroPDF1.Show(); 

Answer 2

No solution was found, but more information: Previously, I tested with XP Pro, Acrobat * .x and .NET 2.0 (built with VS 2005). Since then, I have also been tested in a variety of scenarios, including Vista, Acrobat 9.x, and .NET 3.5 (built with VS 2008).

Same results: Until IE8 browser, the PDF file is not freed when Dispose () is called in the WebBrowser control. It is freed when the application is closed, but it does not help us ...

Hope this helps.

Answer 3

I have an answer that will not require temporary files.

I was forced to create a solution after I was not in the mood to rewrite all my code to use temporary files.

So here is what you do.

• Create a list of lines to store files to delete
  Dim filesToDelete As List(Of String) = New List(Of String)

• You need to install webbrowser in another pdf file,
  (I created an empty one - black or white, something works for you).
  So, like webbrowser1.navigate("blank.pdf" )

• Add the file you want to delete to the list of lines. therefore filesToDelete.Add(filename)

• Now here is the trick. Resources will not be released until you exit this event.
  So, you need to focus on something else, which will lead to the dismissal of another event.
  In my case, I used a tree view to view pdf.
  So, after marking the file for deletion using the method above, I would install treeview in another file.
  Therefore, in the TreeView1_BeforeSelect method, I made the obvious:
  
  If filesToDelete.Count > 0 Then
For Each f As String In filesToDelete
File.Delete(f)
Next
filesToDelete.Clear()
End If
  
  
  You can accept your own event, but I am sure that after marking for deletion you can find something that could lead to another event. Just follow the flow of your code for what comes next.

So you have it. Hope this helped someone.

Answer 4

We had the same issue with IE8 and Acrobat. In our case, we just needed to overwrite the temporary PDF file and redisplay it. We found that we can simply open the PDF, write 0 bytes, and then close it. After that, we will open the file and write the new PDF information, and then re-display the temporary file.

In general, we did not solve the problem of blocking files; instead, we simply left the attached file and reused the file until the user closed the application.

Hope this helps.