Hi all
I have a PDF file. It is easy for me to see it out of VFP program,all I do is click on that file.
But I want my users click on a button in the VFP program then it will open that PDF file.
What command should I use ?
Thanks for your help.
Either of these will bring up the default PDF viewer on the user's computer.
At runtime you may want to check if the user has a default viewer for PDF and if not then direct them to download and install Adobe Acrobat Reader And/Or provide the facility at the time that your application is getting installed since it will be reliant on PDF viewer of some kind.
Hi Slighthaze
Your help is excellent. It works real well. Thanks a lot.
Now I need to find the way to email this PDF file to the user's customers . Any suggestion beside Blat ?
PUBLIC oSMTPMail
oSMTPMail = NEWOBJECT("jmail.SMTPMail"
***If you aren't sure leave this commented out and let the object figure it out for you if possible
***oSMTPMail .ServerAddress = "mail.mchsi.com"
oSMTPMail.AddRecipient ("craig1442@mchsi.com"
oSMTPMail.SenderName = "SlightHaze"
oSMTPMail.Subject = "Sending Attachment Test..."
oSMTPMail.Body = "Hello World!"
oSMTPMail.AddAttachMent ("C:\AutoExec.bat"
oSMTPMail.Execute()
RELEASE oSMTPMail
I'm curious too: My example SendMail.prg would re-encode the file every time an email is sent: If 20 identical emails were sent, then the file would be re-encoded 20 times. And in my tests, a 128k PDF file took 1.95 seconds (65k/sec) to encode after loading using FileToStr, The transfer sending mail depends on your ISP connection.
A 479k PDF file took 68 seconds to encode (7k/sec). I'm not sure, offhand, why the non-linear results. (I re-tried the 128k file, and it took 1.7 seconds....)
A 329k PDF took 22.6 seconds (14k/sec).
It must be the output string building, which (appending a string to the end of another string) would get slower the longer the output string is. Perhaps outputting to a temp file then FileToStr the temp file would be quicker. Any other ideas?
Or, it seems STUFF() goes pretty quickly, (when not changing the length of the output string), so maybe allocate an output buffer of a calculated length, then just STUFF() the encoded characters into it.
FWIW: I tried changing UUEncode to use StrToFile() additive to build the encoded file, and this increased processing of a 320k file from 22sec to 34 seconds.
And I tried predicting the length, then using STUFF (I forgot that stuff doesn't stuff into the original string: It returns the new string as the result) and that increased a 320k file to 75 seconds.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.