Watch, Follow, &
Connect with Us

Please visit our new home
community.embarcadero.com.


Welcome, Guest
Guest Settings
Help

Thread: Problems installing the Adobe Acrobat ActiveX coomponent


This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 5 - Last Post: Jun 23, 2017 12:20 PM Last Post By: Remy Lebeau (Te...
Enquiring Mind

Posts: 87
Registered: 10/6/08
Problems installing the Adobe Acrobat ActiveX coomponent  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2017 6:43 AM
Hi,

About a month ago I installed the Adobe Acrobat ActiveX component in the Delphi IDE on my laptop. The laptop has installed on it the same operating system version, the same users, and the same Delphi version as my desktop computer. I cannot remember whether I also separately imported the Acrobat type libraries at about the same time.

Yesterday and today I have been trying to install the same ActiveX component in the Delphi IDE on my desktop computer. The first problem I encountered was that a .bpl file could not be output. This turned out to be to due to permissions for the $(DELPHI)\Projects\Bpl directory. So I changed this to a folder having write permission, and I was then able to complete the installation steps.

When I finally succeeded in completing the ActiveX installation steps, I found that the number of icons that had been added to the ActiveX page of the Component Palette was very different on the Desktop to the laptop. On the laptop 1 small icon and 7 larger icons were added, each bearing the Adobe Acrobat logo. The small icon is labelled AcroPDF (AcroPDFLib_TLB) and the larger icons have labels such as AcroApp (Acrobat_TLB)). This indicates that in addition to the ActiveX component, components for each interface exposed by the Acrobat Type Library have been added to the component palette.

On the desktop computer, on the other hand, only two icons were added to the ActiveX page of the Component Palette, bearinging some default Delphi icon rather than the Acrobat logo. They are labelled AcroPDF (AcroPDFLib_TLB) and AdobeSPOpenDocumentsShim (AcroPDFLib_TLB).

I then tried to compile and run a Delphi program using the AcroPDF ActiveX control that I had coded on the laptop on the desktop computer. At design time the form shows an icon with the Acrobat logo, but at runtime the ActiveX component displays a blank rectangle whereas on the laptop the AciveX component properly displays the opened PDF document.

Can anyone give any pointers as to what could have gone wrong in the ActiveX installation procedure carried out on the desktop?

TIA
Enquiring Mind

Posts: 87
Registered: 10/6/08
Re: Problems installing the Adobe Acrobat ActiveX coomponent  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 17, 2017 10:48 AM   in response to: Enquiring Mind in response to: Enquiring Mind
As no-one has offered any advice on the question I posted I thought I would share a few findings after spending a couple of frustrating days trying to resolve the problem.

When I installed the ActiveX control on the laptop I selected the item “Adobe Acrobat 7.0 Browser Control Type Library 1.0 for ActiveX (Version 1.0)” in the Component>Import ActiveX Control .. form. This had the effect of generating both AcroPDFLib_TLB.pas and Acrobat_TLB.pas files. AcroPDFLib_TLB is generated from C:\Program Files (x86)\Common Files\Adobe\Acrobat\ActiveX\AcroPDF.dll, and Acrobat_TLB is generated from C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AcroRd32.dll
When I imported the ActiveX control on the desktop only the AcroPDFLib_TLB.pas file was generated. Why not the other type library that was imported on the laptop?

The AcroPDFLib_TLB.pas file on the desktop contains the error message:
1. Error creating palette bitmap of (TAcroPDF) : Error reading control bitmap
2. // Error creating palette bitmap of (TAdobeSPOpenDocumentsShim) : Registry key CLSID{24DA047B-40C0-4018-841B-6B7409F730FC}\ToolboxBitmap32 not found
The same file on the laptop does not include that message. This might explain why on the laptop the ActiveX control’s icon image is correct, whilst on the desktop a default image is used. The laptop is a more recent computer than the desktop, so the colour palette exposed by the ActiveX control might be compatible with the laptop, but not with the desktop.

On the desktop I found that I could not import Acrobat_TLB from AcroRd32.dll using the tools in the Delphi IDE, so I copied the Acrobat_TLB.pas file on the laptop to the correct folder on the desktop, and then added it to the Contains clause of the package for the ActiveX control. This had the effect of adding the previously missing components to the ActiveX the Component Palette page on the desktop. Good! But a significant difference between the palette components on the desktop and the laptop is that the desktop includes the additional component AdobeSPOpenDocumentsShim, not found on the laptop palette. Although the version numbers of the versions of Adobe Reader installed on the laptop and the desktop that are displayed in the Help>About window match, the type library on the desktop includes the TAdobeSPOpenDocumentsShim control which is absent in the laptop version.

I compared the code in the AcroPDFLib_TLB.pas files on the desktop and the laptop line by line and token by token and found many differences. There were 51 line mismatches and 921 token mismatches in iles generated about 6 weeks apart. The class TAcroPDF includes event properties OnError and OnMessage in the version generated on the laptop 6 weeks ago which are absent in the version generated on the desktop today. The component on the desktop throws an exception when run while that on the laptop runs satisfactorily.
The version of AcroPDFLib_TLB.pas on the desktop includes the class TAdobeSPOpenDocumentsShim described as an OLE control proxy class that is absent in the version on the laptop. In its place the laptop includes class CoAdobeSPOpenDocuments. There are significant differences in the implementation code of procedure TAcroPDF.InitControlData.

I also discovered that if one has made any errors installing an ActiveX component in the Delphi IDE, or one has removed certain components, and one then wishes to wipe the slate clean and uninstall an ActiveX control or one or more type libraries, the task is quite difficult to accomplish satisfactorily. For a start there’s no Uninstall action in the Component dialog box. On the Internet one can find instructions for uninstalling a component or package from the Delphi IDE, but the methods that I found only do a partial job. Files that are no longer necessary are not deleted, and neither are Registry entries.

If one then tries to reinstall the ActiveX component, one runs into error messages to the effect that a BPL file already exists in the search path. But shouldn’t the uninstall process have deleted any such files? And even if it hasn’t, why should these file from a previous installation cause the reinstallation to fail – couldn’t the reinstallation just delete the old files and insert the new ones?

The conclusion I have reached from this exercise is that if wishes to waste a lot of time trying to sort out problems difficult to solve because of the high probability for incompatibility between different software modules and the absence of adequate documentation about interfacing and installation issues, in other words if one has a masochistic desire for experiencing DLL brickwalls instead of being productive developing native Delphi programs, then by all means one should consider using third party components, ActiveX components, COM components and the like. My previous experience with trying to leverage COM and DCOM techniques quickly foundered on the hidden obstacles of poorly documented security and other operating system issues. I therefore feel somewhat vindicated in my normal policy of steering well clear of using third party DLLs in my own applications, and will happily at this point abandon any further attempts to get an ActiveX which works on my laptop to also work on my desktop! I shall use ShellExecute or CreateProcess instead, to launch Acrobat Reader as a separate process, and then get back to productive development.

Enquiring Mind wrote:
Hi,

About a month ago I installed the Adobe Acrobat ActiveX component in the Delphi IDE on my laptop. The laptop has installed on it the same operating system version, the same users, and the same Delphi version as my desktop computer. I cannot remember whether I also separately imported the Acrobat type libraries at about the same time.

Yesterday and today I have been trying to install the same ActiveX component in the Delphi IDE on my desktop computer. The first problem I encountered was that a .bpl file could not be output. This turned out to be to due to permissions for the $(DELPHI)\Projects\Bpl directory. So I changed this to a folder having write permission, and I was then able to complete the installation steps.

When I finally succeeded in completing the ActiveX installation steps, I found that the number of icons that had been added to the ActiveX page of the Component Palette was very different on the Desktop to the laptop. On the laptop 1 small icon and 7 larger icons were added, each bearing the Adobe Acrobat logo. The small icon is labelled AcroPDF (AcroPDFLib_TLB) and the larger icons have labels such as AcroApp (Acrobat_TLB)). This indicates that in addition to the ActiveX component, components for each interface exposed by the Acrobat Type Library have been added to the component palette.

On the desktop computer, on the other hand, only two icons were added to the ActiveX page of the Component Palette, bearinging some default Delphi icon rather than the Acrobat logo. They are labelled AcroPDF (AcroPDFLib_TLB) and AdobeSPOpenDocumentsShim (AcroPDFLib_TLB).

I then tried to compile and run a Delphi program using the AcroPDF ActiveX control that I had coded on the laptop on the desktop computer. At design time the form shows an icon with the Acrobat logo, but at runtime the ActiveX component displays a blank rectangle whereas on the laptop the AciveX component properly displays the opened PDF document.

Can anyone give any pointers as to what could have gone wrong in the ActiveX installation procedure carried out on the desktop?
Enquiring Mind

Posts: 87
Registered: 10/6/08
Re: Problems installing the Adobe Acrobat ActiveX coomponent  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2017 9:53 AM   in response to: Enquiring Mind in response to: Enquiring Mind
Update:

Although after much bother I have succeeded in installing both the AcroPDFLib_TLB and the Acrobat_TLB components onto the Component Palette of the desktop computer, the bitmap for the AcroPDF component is still not the correct Acrobat Reader icon, but the generic Delphi icon for a class. The good news, though, is that the component, once dropped on to a form, now seems to work, albeit in a somewhat erratic way. The error message to the effect that the application has stopped working that occurs on launch may be due to the AV virus checker rather than to an exception thrown by the application.

An interesting example of erratic behaviour is this. On the main form, I have two actions, one named ActionLoadFile, and the other ActionOpenLoadFile. The OnExecute of both actions is identical, and is:

procedure TForm1.ActionLoadFileExecute(Sender: TObject);
begin
  OpenDialog1.Filter := 'PDF Files (*.pdf)|*.PDF';
  if OpenDialog1.Execute then
     SetPDFFilename(OpenDialog1.FileName);
 end;
 
procedure TForm1.ActionLoadAnotherFileExecute(Sender: TObject);
begin
  OpenDialog1.Filter:= 'PDF Files (*.pdf)|*.PDF';
  if OpenDialog1.Execute then
     SetPDFFilename(OpenDialog1.FileName);
end;
 
procedure TForm1.SetPDFFilename(PDFFilename: widestring);
begin
  AcroPDF1.src:= PDFFilename;
  Invalidate;
end;
 
procedure TForm1.FormResize(Sender: TObject);
begin
  if AcroPDF1<>nil then
    AcroPDF1.SetFocus; 
  StatusBar1.Panels[0].Text:= GetPDFCptDimnsAsString;
end;
 


The interesting finding is that the two actions produce different behaviours! After executing ActionLoadFileExecute, on maximising the main form, the AcroPDF component, whose Align property is set to alClient, resizes to fit its parent window. But after executing ActionLoadAnotherFileExecute, on maximising the main form, the AcroPDF component is not resized to fit the parent window, retaining its initial size. At first I thought that this might have something to do with the order of execution of the actions. But further testing showed that every time I triggered the ActionLoadFileExecute action, the PDF control would correctly resize, whilst every time I triggered the ActionLoadAnotherFileExecute action, the PDF control refused to resize.

Can anyone shed any light on this apparently inconsistent behaviour - the same code producing different behaviours?

TIA
EM

Edited by: Enquiring Mind on Jun 22, 2017 6:11 PM
Enquiring Mind

Posts: 87
Registered: 10/6/08
Re: Problems installing the Adobe Acrobat ActiveX coomponent  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 23, 2017 2:38 AM   in response to: Enquiring Mind in response to: Enquiring Mind
Although the 2 actions ActionLoadFileExecute and ActionLoadAnotherFileExecute have identical code, they are called from different types of component. ActionLoadFileExecute is called from a button to which ActionLoadFile has been assigned, while ActionLoadAnotherFileExecute is called from a main menu item to which ActionLoadAnotherFile has been assigned. both these components are contained in form of class TForm1.

Now I also have a global procedure that takes a PDF file path as a parameter, then creates a form of class TForm1, and assigns the file pathname using the same procedure SetPDFFilename that is called in ActionLoadFileExecute. So this is a third route to calling the same AcroPDF.src:= Filename statement. The PDF ActiveX component displayed by means of this third method also fails to resize when its container window changes size, in spite of having its Align property set to alClient. The code of the global procedure in question is:


procedure ShowPDFFile(Filename: widestring);
var
  Form2: TForm1;
begin
  Form2:= TForm1.Create(nil);
  try
    Form2.AcroPDF1.Align:= alClient;
    Form2.SetPDFFilename(Filename);
    Form2.ShowModal;
  finally
    Form2.Free;
  end;
end;


So in summary, the question is, "Why does the code 'AcroPDF1.src:= Filename' produce a different behaviour with respect to resizing depending on where it is called from?"

EM

Enquiring Mind wrote:
[snip]
The interesting finding is that the two actions produce different behaviours! After executing ActionLoadFileExecute, on maximising the main form, the AcroPDF component, whose Align property is set to alClient, resizes to fit its parent window. But after executing ActionLoadAnotherFileExecute, on maximising the main form, the AcroPDF component is not resized to fit the parent window, retaining its initial size. At first I thought that this might have something to do with the order of execution of the actions. But further testing showed that every time I triggered the ActionLoadFileExecute action, the PDF control would correctly resize, whilst every time I triggered the ActionLoadAnotherFileExecute action, the PDF control refused to resize.

Can anyone shed any light on this apparently inconsistent behaviour - the same code producing different behaviours?

TIA
EM
Enquiring Mind

Posts: 87
Registered: 10/6/08
Re: Problems installing the Adobe Acrobat ActiveX coomponent  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 23, 2017 5:58 AM   in response to: Enquiring Mind in response to: Enquiring Mind
Enquiring Mind wrote:
Although the 2 actions ActionLoadFileExecute and ActionLoadAnotherFileExecute have identical code, they are called from different types of component. ActionLoadFileExecute is called from a button to which ActionLoadFile has been assigned, while ActionLoadAnotherFileExecute is called from a main menu item to which ActionLoadAnotherFile has been assigned. both these components are contained in form of class TForm1.

Now I also have a global procedure that takes a PDF file path as a parameter, then creates a form of class TForm1, and assigns the file pathname using the same procedure SetPDFFilename that is called in ActionLoadFileExecute. So this is a third route to calling the same AcroPDF.src:= Filename statement. The PDF ActiveX component displayed by means of this third method also fails to resize when its container window changes size, in spite of having its Align property set to alClient. The code of the global procedure in question is:

 
procedure ShowPDFFile(Filename: widestring);
var
  Form2: TForm1;
begin
  Form2:= TForm1.Create(nil);
  try
    Form2.AcroPDF1.Align:= alClient;
    Form2.SetPDFFilename(Filename);
    Form2.ShowModal;
  finally
    Form2.Free;
  end;
end;


So in summary, the question is, "Why does the code 'AcroPDF1.src:= Filename' produce a different behaviour with respect to resizing depending on where it is called from?"

EM

I think I have found the answer to the above question. The behaviour depends on which control in the form has focus when the PDF file is opened. When the file is opened by clicking on a button, the act of clicking on the button shifts focus to the button. When focus is then moved to the AcroPDF control after the file has been assigned to it, this makes the control resize its image. However if focus is on the AcroPDF control, clicking on a menu item to open a new file does not take the focus off it. So when the file is opened, focus is not reset on the AcroPDF control, with the consequence that its image does not get resized. I have found that one way of getting the AcroPDF control to resize is to call the following method from inside the FormResize event handler:

procedure TForm1.ResizeAcroPDFControl(AcroPDF: TAcroPDF);
begin
  if Self.Visible and (AcroPDF <> nil) then
    begin
      if CResizeOption= roFocusControl then
        begin
          {Take focus off AcroPDF control:}
          FocusControl(nil);
          {Reset focus on AcroPDFControl}
          FocusControl(AcroPDF);
        end
      else
        begin
          if ActiveControl= AcroPDF then
            {Take focus off AcroPDF control:}
            ActiveControl:= nil;
          {Reset focus on AcroPDFControl}
          AcroPDF.SetFocus;
        end;
    end;
end;
 
procedure TForm1.FormResize(Sender: TObject);
begin
  {Resize AcroPDF control by resetting focus on it:}
  {if Visible and (AcroPDF1 <> nil) then
    AcroPDF1.SetFocus; }
  ResizeAcroPDFControl(AcroPDF1);
  {Display current control dimensions to status bar:}
  StatusBar1.Panels[0].Text:= GetPDFCptDimnsAsString;
end;
 


Using the above code makes the behaviour consistent in each of the 3 cases highlighted in the previous post. However when the form is resized by dragging a corner, the AcroPDF control does not resize smoothly, there being a delay between successive fitted images during which the parent control's background is visible. I presume that this is an effect of taking focus off the control. But when I set the focus on the control directly in the FormResize event handler (as per code commented out), the resizing operation is smooth with no perceptible delay or flicker. Can anyone explain this?

EM
Remy Lebeau (Te...


Posts: 9,229
Registered: 12/23/01
Re: Problems installing the Adobe Acrobat ActiveX coomponent  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 23, 2017 12:20 PM   in response to: Enquiring Mind in response to: Enquiring Mind
Enquiring Mind wrote:

I think I have found the answer to the above question.

Old issue, been around for years. You discovered one of the possible
workarounds:

Resizing issues with TAcroPDF
http://www.tek-tips.com/viewthread.cfm?qid=1144334

AcroPDF resize problem
https://forums.adobe.com/thread/301827

Resize problem using AcroPDF in Delphi
https://stackoverflow.com/questions/4032988/

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02