PDF Creator - Viewing a .pdf file within the VFP application

[AndrewMozley]

I am running a VFP9 application, and am using PDFCreator to create the .pdf file. My code looks pretty much like this :

oPDFC = CREATEOBJECT("PDFCreator.clsPDFCreator","pdfcreator")
oPDFC.cStart("/NoProcessingAtStartup")
oPDFC.cOption("UseAutosave") = 1
oPDFC.cOption("UseAutosaveDirectory") = 1
oPDFC.cOption("AutosaveFormat") = 0
oPDFC.cDefaultprinter = "pdfcreator"
oPDFC.cOption("AutosaveFilename") = cpdfName
oPDFC.cOption("AutosaveDirectory") = cOutFolder
oPDFC.cprinterstop=.F.

SET PRINTER TO NAME (oPDFC.cDefaultprinter)
REPORT FORM (lRepName) NOCONSOLE TO PRINTER

This works fine and produces a .pdf file which I can view using Adobe. However I would like to provide the option for the user to view the .pdf file within the application. Is that possible?

I feel that it is probably defined somewhere within the PDFForge documentation, but have not really found my way round that yet.

Thanks. Andrew M.

 

[Mike Gagnon]

Put the Adobe Acrobat reader activex on a form.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[AndrewMozley]

Thanks Mike

Could you talk me through this, please. On the Form Controls Toolbar (Library Dropdown) there is an entry “Activex Controls”. At first this had no entries in it.

However I then went into Tools | Options , selected the ActiveX Controls radio button, and put a cross against Adobe PDF Reader and clicked OK.

This then meant that when I selected Activex Controls on the Form Controls Toolbar, Adobe Reader is indeed present. I can place this control on onto my Print form class (the icon is very small within the control on the screen).

However when I try to run a form based on my Print Form, an error comes up :
“Loading form or the data environment” OLE Error code 0x80004005 – unexpected error.
(If I remove the Adobe reader control from the form the form loads and runs OK, as before).

Is there something else that I need to do in order to include the Adobe Reader on my print form. And once I have done that, how (at run time) do I invoke the Adobe Reader with the pathname that I have established; I would hope that the user would not have to key this in again.

Sorry to be a bit slow, but thanks.

 

[Mike Lewis]

Andrew,

Mike's given you one possible solution. A simpler alternative would be to ShellExecute the PDF:

* Do this at the start of your app
DECLARE INTEGER ShellExecute IN shell32.dll ;
  INTEGER hndWin, ;
  STRING cAction, ;
  STRING cFileName, ;
  STRING cParams, ;
  STRING cDir, ;
  INTEGER nShowWin

* Do this when you want to display the PDF
lcFile = "c:\PDF\NyFile.PDF"
ShellExecute(0, "open", lcFile, "", "", 3)

The disadvantage of this approach is that, once you have opened the PDF, you no longer have any control over it. If the user wants to print it, or resize it, or do just about anything else, it will be up to them to do that from within the PDF viewer.

On the other hand, it has the advantage that you don't need any particular PDF software to be installed; it displays the file in whatever viewer program the user prefers.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[AndrewMozley]

Thank you Mike L. That works fine. I have Adobe reader installed on my machine with the appropriate file association and the .pdf file is displayed.

I see that Adobe and my app continue independently. Not sure why I would want to do it, but if I wanted to hold up my VFP processing until Adobe had done its thing, is that possible?

Andrew M.

 

[Mike Gagnon]

Andrew,
Before you open the form the activex need to know the name of the file it will be displaying.


Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Mike Lewis]

if I wanted to hold up my VFP processing until Adobe had done its thing, is that possible?

No, not using ShellExecute(). That was the point I was making. The PDF viewer is running independently of your application. Each will continue at its own pace.

However, there is another approach. You could do it like this:

owsh = CREATEOBJECT("wscript.shell")
owsh.Run("c:\PDF\MyFile.PDF", 3, .T.)

That will launch the user's preferred PDF viewer, and display the specified file, just like with ShellExecute(). But by passing .T. as the third parameter, you tell it to suspend your program for as long as the viewer is open. If the user switches back to your application while the PDF is active, they will see an hourglass.

But are you sure that's what you want? Why shouldn't the user be able to continue to interact with your app, even while the PDF is being viewed?

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Mike, no matter how hard I try, the error is persistent. Ignoring it works, but the moment the olecontrol is made visible I also get an OLE Error.

Using Acrobat 11 on Windows 7 here.

Release goPDFForm
Public goPDFForm
goPDFForm = CreateObject("form")
goPDFForm.AddObject("myPDF","Olecontrol","AcroPDF.PDF")
goPDFForm.myPDF.width = 800
goPDFForm.myPDF.height = 1200
goPDFForm.myPDF.LoadFile(GetFile("PDF"))
goPDFForm.myPDF.visible = .t.
goPDFForm.Show()

Solution might be to ignore the error programmatically, with TRY..CATCH:

Release goPDFForm
Public goPDFForm
goPDFForm = CreateObject("form")
goPDFForm.AddObject("myPDF","Olecontrol","AcroPDF.PDF")
goPDFForm.myPDF.width = 800
goPDFForm.myPDF.height = 1200
goPDFForm.myPDF.LoadFile(GetFile("PDF"))
TRY
   goPDFForm.myPDF.visible = .t.
CATCH
   *
ENDTRY
goPDFForm.Show()

Bye, Olaf.

 

[Olaf Doschke]

Judging from this thread the problem to use the control exists for VB6 and Delphi developers, too, any 32bit programming language.

https://forums.adobe.com/thread/1474715

I said I use Adobe REader 11, to be more precise version 11.0.09 and the problem seems to exist since the change from 11.0.06 to 11.0.07

Bye, Olaf.

 

[NasibKalsi]

Possibly divide the process into 2 pieces. First will create and view pdf. Second execute what is still pending. I mean make 2 command buttons.

nasib

 

[vernpace]

If Adobe is installed, you can view PDFs in the web browser control that ships with VFP. Call Navigate2(file.pdf). After it is loaded, a few Abobe methods are exposed: setView() and setShowToolbar(). I forgot all the setView parms, but "FitH" is one. Pass either .T. or .F. to setShowToolbar.

oleWebBrowser.Navigate2(file.pdf)
oleWebBrowser.Document.setView("FitH")
oleWebBrowser.Document.setShowToolbar(.F.)

 

[Olaf Doschke]

>if I wanted to hold up my VFP processing until Adobe had done its thing, is that possible?

Let me say more generally you may create a second process and wait for it to exit. Not with ShellExecute, though. Doing it without any dependency is quite cumbersome via CreateProcessEx and WaitForSingleObject, eg see

http://www.tek-tips.com/viewthread.cfm?qid=1184461,

the post with the lengthy code of Ed Rauh's api_apprun class.

Boris Borrisov also posted an easier way in an earlier post:

oWSShell = CREATEOBJECT("WScript.Shell")
oWSShell.Run(full_path_to_ext_application,1,.T.)

The last logical parameter allows you to specify whether to wait or not. I used WScript.Shell to replace RUN, but since a few weeks we have a single notebook not working with this. Tried to turn on WSH, but it didn't work out. Just a warning. The lengthy API based way to start and wait for a process doesn't depend on settings, these API calls are very core things needing to work. I'd prefer the two line alternative anyway, if you can.

Bye, Olaf.

 

[Steve-vfp9user]

Just a thought for creating PDF's, have you tried FoxyPreviewer? You don't need any other applications.

Thank you

Steve