Skip to main content
H
henkz62957220
Participant
June 19, 2019
Question

Form object (containing ActiveX) creation not getting past .EndInit()

  • June 19, 2019
  • 1 reply
  • 803 views

Hi,

I am trying to add PDF viewing features to a program (written in C# Visual Studio 2017). It needs to allow multiple PDFs open simultaneously. And repeatedly.

For this purpose I created a form and added the AcroPDFLib into it. I display it (and later hide it) in a separate thread from the main thread, because

my main thread needs to remain interactive (and AcroPDFLib needs to run in Single Thread Apartment mode). When I need to show a

PDF, I create and start a new thread. (I do notice that memory use gradually increases). I use fairly various sizes of PDFs for testing ( 60K up to 50 MB).

In my tests I use several PDFs to verify reliability.


This works fairly well, but from time to time creation of a form fails.Repeating the attempt also fails.

I added logging and found that it is at the line below (in the InitializeComponent() method of the form creation) that it 'blocks':


((System.ComponentModel.ISupportInitialize)(this.axAcroPDF1)).EndInit();

I also notice that if I do this test with only a single PDF type (repeatedly showing and hiding), the issue does not occur.

I use Acrobat Reader DC (2019.012.20035). The operating system I develop on is Windows 7, but I also have this issue on Windows 10.

Has anyone in this forum noticed this? (I have googled the issue and found 1 other user who encountered this; sadly with no further information).

Can anyone suggest a way to fix this?

    This topic has been closed for replies.

    1 reply

    T
    Test Screen Name
    Legend
    June 19, 2019

    Maybe you need to quit Acrobat Reader. See whether you can make the failure go away by killing all the Acrord32 processes. If so you need to factor that in somehow.

    H
    henkz62957220Author
    Participant
    June 19, 2019

    Thank you for replying!

    I checked but I do not see a Acrobat Reader process running. Not when things work or when they fail. But something may get left behind on the COM-side of things.

    note: I have noticed that the first PDF Form created by my application always seems to be successful.

    However, when I check the threads in my application after a failure (using Process Explorer), I do see several that have "AcroRd32.dll!" in their start address. I think these are the leftover threads of the PDF forms that have been shown and disposed. I marked these threads as backgroundthreads, but it seems they aren't removed when the task they were executing has finished.

    Should I try harder to destroy these threads?

    H
    henkz62957220Author
    Participant
    June 25, 2019

    Update:

    on closer inspection I did see an AcroRd32 process running (if very briefly).  But by changing the way I launch the form threads things seem to get cleaned up properly now, and I no longer see the blocking issue. Although the threads are not cleaned up, and increase in number often 4x for each display form thread.


    What has surprised me is how much memory opening and displaying a 44 MB PDF (with graphics) needs. My program takes about 90 MB, but when I open that test PDF it jumps to 550 MB (seen in process explorer) in the course of 20 s.

    When I use Adobe Reader DC to open that same pdf it jumps a little less (24 MB to 279 MB). So this seems to be an Adobe effect.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices