Error closing form with Tacropdf in Delphi

Asked

Viewed 566 times

3

This "blessed" component, unfortunately I need to use it, it happens that whenever I try to close the Form it closes, but always gives a Accessviolation.

There’s nothing in Form but a Tacropdf and a Close button.

The impression that gives is that the form is being closed before destroying the component, it happens that I have tried to use FreeAndNil(AcroPDF1); AcroPDF.Free; AcroPDF.Destroy etc etc... and nothing, he insists on giving the Accessviolation.

I put the construction of the Form inside a Try to solve the problem, but it is not the correct way, whenever I need to touch this Form in development time, here comes the damn Accessviolation.

Someone’s been through it and they’ve solved it?

Note: I solved this problem in another screen using Twebbrowser to open PDF, but I use this Tacropdf in several screens and I would have to rewrite them and could generate other problems in the application since this Twebbrowser is also an annoying component to stir, before going pro radical I would like to know if there is a more friendly solution for Tacropdf.

  • Marcelo, have you tried to put Freeandnil(Acropdf1); in "Formclose"? Can you detect in which line it gives Access Violation? This error may also be associated with src still being instantiated at the time of closing. Try to give a AcroPdf1.Src := '' before Freeandnil to see if it solves.

  • 1

    I already gave a Freeandnil, Destroy, Free... in all of them from the error, it seems to me that he does not let destroy the Acropdf that way.Src := '' I have not tried, I will see if it works. With debug and send to Units that has nothing to do with the component or the Form in question, as it is an Activex it seems that it works in parallel, this makes it difficult to debug.

  • Take a look if the AcroPdf1.Src := '' before Free help. I look forward to your return! If not, I look for another way to simulate this error.

  • 1

    I tried to put src := '', but the error continues, I made a very simple test application with the Acropdf component and the error persists, if you want to download the following link: http://mvsoftware.com.br/downloads/AcroPDF.rar

1 answer

6


The destruction should occur as soon as the Form invokes the Destroy of his "children".

What happens in this case is that one of your children is not an instantiated but initialized object, which usually occurs in some Activex components.

In some cases it is solved only by including Create of Form one CoInitialize which will instantiate all Activex Objects, and Close trigger the CoUnitialize which in turn removes all Actovex from the interface.

In the case of Acropdf, it is not an object that can be destroyed next to the interface, so we need to warn it that it needs to destroy itself.

I found in Soen a solution that, incredible as it seems to work for a long time.

Close-up:

AcroPdf1.ControlInterface._AddRef;

That way he’ll invoke the _Release of the component, it is no use to invoke _Release directly, there are internal processes of the application that must be performed for the done, such as its own allocated memory release.

It is not the fault of your Application or the component, it is the fault of Delphi itself that allows objects to be created without a well-made Class creation. I mean, there is a Construtor and there is no Destructor.

It is worth remembering that this component in VB.6 this does not occur so often.

Question with resemblance.

  • 1

    Boy, it doesn’t really work, rsrs, thanks Junior, when I was going to imagine that there is Acropdf1.ControlInterface. _Addref; to help Activex move memory, rsrs

Browser other questions tagged

You are not signed in. Login or sign up in order to post.