OLEControl showing a document 2

[SitesMasstec]

I opened a New Form and dragged on it an OleControl from de menu, chose 'Insert Control', and for Control Type I chose 'Acrobat PDF Reader'.

Well, I have a PDF document named "MyManual.PDF'. In which item of Properties window should I type the name 'MyManual.PDF'? And in the Properties window of the Form or of the OleControl?

Thank you.

Thank you,
SitesMasstec

 

[Mike Lewis]

Try calling the LoadFile method, passing the (fully-qualified) name of the PDF file that you want to open.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

If you only want to display the PDF (and possibly print it), you will find it much easier to use ShellExecute(). If you don't know how to do that, see

http://www.ml-consult.co.uk/foxst-26.htm

But if you want to programmatically turn the pages or do a search, then the ActiveX control will be necessary.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SitesMasstec]

Hi Mike!

ShellExecute() works well but in this case I don't want to use it. I want to open a window in my application showing a user guide (MyManual.PDF), so I will use the ActiveX.

But unfortunatly, I have not been able to implement it.
When I run the Form (please see bellow), an error appears.

Thank you,
SitesMasstec

 

[Tore Bleken]

You must include the path! And if an error occurs, please remember to tel us which error message you get.

 

[Olaf Doschke]

BEsides needing to give the whole pass, yo0u don't put code in that OleControl1 method, you make a call from outside, eg in Forms Init Event you do

THISFORM.OleControl1.LoadFile("C:\yourpath\toyour\MyManual.PDF")

Bye, Olaf.

 

[SitesMasstec]

Well, the PDF document is in the current directoty. But I put the path as you advised but the error appeared again*.

When executing the Form the error appears as:
"OLE error code 0x80004005. OLE object is being ignored. Record number 4."

In the object Olecontrol1, the LoadFile Procedure is:
*** ActiveX Control Method ***
LPARAMETERS filename
filename="MyManual.PDF"

Is the above correct?

(*) filename="D:\Sistemas\W\Receitas2\MyManual.PDF" shows error



Thank you,
SitesMasstec

 

[vernpace]

You need to do it in an IE control. This will get you started:

https://www.berezniker.com/content/pages/visual-foxpro/view-pdf-vfp-form

 

[Olaf Doschke]

That error most probably happens even before any form code is executed including yours. You still have no error handling implemented, it seems, so you just guess where the error comes from. This is telling, that the whole ActiveX control is ignored and not shown, most probably the Acrobat Reader Control is not compatible with VFP or a license is needed to run it.

You still might give it a try to do as I suggested and just call the method, as Mike also said and meant, and not program within it.

Bye, Olaf.

 

[Tore Bleken]

The point about the path is that although the picture may be in the current (VFP's) directory, that's not true for the OLEControl! The OLEControl's current directory is where that control is.

 

[Mike Lewis]

*** ActiveX Control Method ***
LPARAMETERS filename
filename="MyManual.PDF"

Is the above correct?

No, that's not what I said. I said to call the method, passing the filename as the parameter.

Try doing this in the control's Init:

this.loadFile("D:\Sistemas\W\Receitas2\MyManual.PDF")

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SitesMasstec]

Hi Mike!

The same error persists.

This is in the Init:
this.loadFile("D:\Sistemas\W\Receitas2\MyManual.PDF")

and this is in the LoadFile:
*** ActiveX Control Method ***
LPARAMETERS filename


Thank you,
SitesMasstec

 

[Mike Lewis]

According to MegaFox, there is another way of loading the PDF: set the control's src property to the fully-qaulified filename. They suggest doing it in the form's Init:

thisform.oleControl1.src = "D:\Sistemas\W\Receitas2\MyManual.PDF"

Might be worth a try.

If you really can't get it to work, think about the alternatives:

- ShellExecute() - see above. I know you said you wanted to display the PDF in a form, but you might accept that it should be in a window outside your application. After all, that's how most Help systems work.

- Display the PDF in a web browser control. You might need to adjust the settings of the web browser to launch PDFs within the browser rather than in their own window.

- If you have the source of the PDF, consider converting it to another format. For example, if you convert to RTF, you can display it in the Microsoft Rich Text control. Or in an OLE Control, using the "create from file" option, and specifying a RTF (or Word) document. (You will need to make the relevant control read-only in these cases.)

But with luck you'll get the Adobe control working.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[SitesMasstec]

Hi Mike!

Yes, great! The Microsoft Rich Text control option you presented worked very fine for my
purpose. Thank you.

Also I have the ShellExecute option for the document in a window outside the application (as you have said "that's how most Help systems work").




Thank you,
SitesMasstec

 

[Olaf Doschke]

This is in the Init:
this.loadFile("D:\Sistemas\W\Receitas2\MyManual.PDF")

I proposed the form.init, not Olecontrol1.Init. In [highlight #FCE94F]FORM.INIT[/highlight] you put, you leave the ActiveX control as it was when you added it to the form, this is not touched at all. Redo it from scratch, you only use it, you access it from the form level, you do nothing from within itself.

THISFORM.Olecontrol1.LoadFile("D:\Sistemas\W\Receitas2\MyManual.PDF")

Bye, Olaf.

 

[SitesMasstec]

Hi Olaf!

Ok, I created a New Form, and in the Init I put:
THISFORM.Olecontrol1.LoadFile("D:\Sistemas\W\Receitas2\MyManual.PDF")
and I put nothing more in the Form

And I drag the OleControl to the form, and chose (Insert Control) Adobe PDF Reader in the Control Type, and OK.
and nothing more

And the error persists,




Thank you,
SitesMasstec

 

[Olaf Doschke]

OK, then this ActiveX control is not compatible with VFP at all. But you should do one thing, before anything else: Implement error handling.

In main.prg put

ON ERROR Do errorhandling WITH ERROR(), MESSAGE(), MESSAGE(1), PROGRAM(), LINENO(), LINENO(1)

* your further main.prg code including DO FORM
DO FORM pdfform
* eventually ending in READ EVENTS


PROCEDURE errorhandling
   LPARAMETERS nError, mess, mess1, mprog, mlineno, mlineno1

Text To lcErrMessage NOSHOW TEXTMERGE
Error number: <<LTRIM(STR(merror))>>
Error message: <<mess + iif(empty(mess1),'','(+mess1+')')>>
Program with error: <<mprog>>
Line of code with error: <<mess1>>
Line number of error: <<LTRIM(STR(mlineno))+ iif(mlineno1=mlineno,'','/'+LTRIM(STR(mlineno1)))>>
Endtext
   MessageBox(lcErrMessage,0,"Error!")
   Set Step On
ENDPROC

Now I bet the error you see happens in main.prg at the line DO FORM pdfform, not in the code of the form Init() nor in the code you added earlier, and that will point out the error happens because the Acrobat Reader ActiveX control refuses to run at all. There are other famous cases - license related, ie you can only use Winsock OCX on a form, not standalone as an OLE control class.

I manage to show a PDF with Foxit PDF Reader, so you may switch from Acrobat to that. anyway, your idea will depend on what users have installed, so using something like RTF is better suited anyway, as you want to embed it in your form. The RTF control only depends on you adding it in your setup, it is within the list of OCXes coming with VFP you can also redistribute, whereas Acrobat Reader ActiveX will depend on Acrobat Reader installed, and even though it is free, you have to advise users to install Acrobat as requirement before installing your software, you can't inlcude the Acrobat in your setup. You also should think about such issues, before you even start thinking about using any ActiveX control.

All that aside, the main point is, this error handling has the advantage of showing you the position the error happens, which the native Foxpro error message doesn't tell you. PROGRAM() and LINENO() are very valuable information. A downside is you don't have the cancel/suspend/ignore buttons the native error message gives you, but you can also do your own message box form with these and more options, and since the error handling routine has SET STEP ON after the MessageBox you go into suspended mode and can single step back to the place the error happened and do further debugging, inspect variables and their values, etc.

The code is taken from the help topic for ON ERROR and only modified to have one more parameter and show the message in a MessageBox instead of printing it on screen with the "?" command, very unfortunate way of displaying an error message, especially when it happens within a form with AllowOutput=.F.

I know it's not the first time I point this out to many people and I even think I especially already pointed you toward this. I have the feeling about 50% of questions about errors are solvable by better error handling and debugging abilities. You can really see which line causes an error, the native error message is really stupid in that aspect, you can really continue executing code and go back to the place and try things right at the place the error occurred.

And this is just the start, I can't give you my full error handling routine here, as it is very involved with lots of things you don't have, so it's very dependent on more things and not easy to share. There are parts in it handling specific errors like OLE errors, database/table trigger errors, ODBC errors and more. You should make use of AERROR and ASTACKINFO, especially when you also set the project to include debug info in an EXE to get the most of ASTACKINFO.

Bye, Olaf.

 

[Olaf Doschke]

Now I downloaded Acrobat Reader DC and it is not only happening at runtime, once you save a form with an "Adobe PDF Reader" control put on it, even just reopening the form in the form designer this error of ignoring the control appears. The whole control is not compatible with VFP, obviously.

It doesn't really surprise me, I'd guess about 25% of controls VFP lists for you to add on a form won't work with VFP, especially controls not coming from MS and not designed for VFP contrary to dbi or Exontrol or Chilkat controls, which are even coming with VFP sample code of uage. Just understand VFP only lists the what windows registry offers without having any idea about control compatibility. Also, as already said, you can't expect anyone to have the same controls installed as you, so you always better avoid the use of ActiveX or limit yourself to things you purchased for VFP and what comes with VFP. Anything else, like eg Foxit Phantom PDF, is luck.

If you really want to display PDFs, the best way I think is going through Microsoft Web Browser control and use it with navigate2("file://"+pdffilename). This will take whatever IE and/or Windows settings for displaying PDF within an IE are and should even work if the standard program for that is Acrobat Reader. Notice: Even after making Acrobat the default for the PDF extension and also from within IE settings, the Web Browser still resolves a PDF file URL by displaying the Foxit PDF control within the Webbrowser control for me, your mileage may vary, but it's pretty easy and will take whatever works within IE browser.

Bye, Olaf.

 

[Mike Lewis]

SitesMasstec, it's good to see that you now have a working solution. I'm not surprised the Rich Text Control works better, as it is a Microsoft control and one that is supplied as part of the VFP package rather than being a third-party product.

It's a pity that you didn't get the Adobe control to work. I can only assume there is some compatibility issue.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Scott24x7]

SitesMasstec,
I can't help but add in this other possibility. I have a similar thing where I want certain documents to be available fast and easy (the user doc also being one of them).
What I have done is build a dynamic menu, so any file that is placed into a "HELP" directory will automatically be available from a HELP menu at the top line. You just click help, and all the docs in that directory appear as menu items by file name in the dropdown list. You click them, and they get launched with a shellexec (I know you want to avoid that but this is so flexible I think you might like the result).

The code is very simple, add it into your common procedure file:

PROCEDURE MENUINFO

lnHelpBooks = ADIR(laHelpBooks,"HELP\*.PDF",'',1)
*
DEFINE PAD HELPGROUP OF _MSYSMENU PROMPT '\<References' KEY ALT+R, 'ALT+R'
ON PAD HELPGROUP OF _MSYSMENU ACTIVATE POPUP HELPGROUP
DEFINE POPUP HELPGROUP MARGIN RELATIVE SHADOW COLOR SCHEME 4
*
FOR BookBuild = 1 TO lnHelpBooks
	DEFINE BAR BookBuild OF HELPGROUP PROMPT '\<'+LEFT(ALLTRIM(laHelpBooks(BookBuild,1)),;
		LEN(ALLTRIM(laHelpBooks(BookBuild,1)))-4)
ENDFOR
*
ON SELECTION POPUP HELPGROUP DO SHELLEXEC WITH '"'+SYS(5)+SYS(2003)+'\HELP\'+ALLTRIM(PROMPT())+'.PDF"'

This assumes a directory called HELP in the same location as your main program.
This will place a "References" menu at the end of your main menu. I have it restricted to only getting .PDF files in this case, but other extensions can also be utilized. It's really handy for keeping reference docs available in an application. (We do a lot of work with "standards", and we need to refer to them all the time, so we built this, to make it easy to launch the standards .PDFs without having to navigate for them in the application. This also allows users to add or remove documents that they want, and no programming required.)


Best Regards,
Scott
MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"Everything should be made as simple as possible, and no simpler."