INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Jobs

OLEControl showing a document

OLEControl showing a document

(OP)
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

RE: OLEControl showing a document

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

RE: OLEControl showing a document

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

RE: OLEControl showing a document

(OP)

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

RE: OLEControl showing a document

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

RE: OLEControl showing a document

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

CODE

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

Bye, Olaf.

RE: OLEControl showing a document

(OP)
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

RE: OLEControl showing a document

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.

RE: OLEControl showing a document

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.

RE: OLEControl showing a document

Quote:

*** 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

RE: OLEControl showing a document

(OP)
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

RE: OLEControl showing a document

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

RE: OLEControl showing a document

(OP)

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

RE: OLEControl showing a document

Quote (SitesMasstec)

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

I proposed the form.init, not Olecontrol1.Init. In FORM.INIT 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.

CODE -->

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

Bye, Olaf.

RE: OLEControl showing a document

(OP)

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

RE: OLEControl showing a document

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.

RE: OLEControl showing a document

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.

RE: OLEControl showing a document

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

RE: OLEControl showing a document

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:

CODE

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."hammer

RE: OLEControl showing a document

(OP)
Dear colleagues:

After all I choose to use the ShellExecute() method, proposed by Mike.

Because the Microsoft Rich Text control method, that "worked fine" as I had said above, works fine for small RTF files (MyManual.rtf is a small one, for the purpose of tests here). The real file (application manual) with lots of pages and illustrations, took some minutes to load! And the user would think his/her computer halted!

I appreciated the help from all of you.

Thank you,
SitesMasstec

RE: OLEControl showing a document

Indeed large PDFs load slow, no matter if you navigate2 a file link of the PDF file or use HTML <object> or <embed> tags, so the ShellExecute might be the best approach, though the executed PDF viewr then also takes its time. What you're missing is the opportunity to show a certain page, an <object data="url/to/some.pdf#page=2" type="application/pdf"> as html content of a webborwser control document can do that.

Bye, Olaf.

RE: OLEControl showing a document

Perhaps the ideal solution would be to display the information in the form of a Windows Help file. That would give you all the formatting and graphics you need, including hyperlinks, plus the ability to drill down into topics and sub-topics, plus searching. Above all, it could be made context-sensitive, which a PDF cannot. And it would be properly integrated into your VFP app. So, for example, the Help window would automatically close when the user exits the app.

All you would need is a decents Help authoring package, plus the time and energy to create the Help file.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: OLEControl showing a document

Sure, the best form of an application manual is a chm help file, though a PDF printable manual also has its advantages. Help files don't nicely organize into a sequential flow of chapters, they are more a reference, though also books can have these two flavors of being narrative and just a comprehensive reference book.

Bye, Olaf.

RE: OLEControl showing a document

Large RTFs will work fine in a Rich Text control if you enable ActiveX dual interface support: SYS(2333,1) I have loaded RTFs larger than 100MB - very fast. Check it out.

For PDFs, we made a deal with Foxit Software for their ActiveX control. It has a great API and customers don't need to preinstall Foxit Reader. Furthermore, you don't have to deal with all the issues concerning Adobe. Here is a sample screenshot with the bookmarks open:

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Resources

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close