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
Code:
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.
![[hammer]](/data/assets/smilies/hammer.gif "[hammer] [hammer]")