Invoking a PDF

[Tim Reed]

Hello ... my Dad is dabbling in VB & has a question about invoking a PDF (to
display a help file or manual). Myself, I don't know VB - but I *do* know
how to post to a NG <g>. If anyone has a solution, I would pass it on with
appreciation. Thanks! - Tim

=====================================

I'd like to include in a Visual Basic (VB6) program a command that would
bring up the User's Manual. I'm pretty much settled on the idea that the
manual should be an Acrobat .pdf file (as being the most common
denominator).

It's easy enough to have a statement like:

Shell ("... (tree path) ... Acrord32.exe FileName.pdf,
vbMaximizedFocus)

which works fine on my machine, where I know what the pathname is, but the
problem is, based on a review of our two computers and another, that the
user's machine might have any of a half-dozen versions of acrobat's
PDFreader. So how to find the path and name?

It occurs to me that Windows has some way of solving this. Click on any
..pdf file and Windows opens it with whatever Acrobat reader it chooses (not
neccessarily the latest version on the computer). How does Windows locate a
reader? Is there a simple way I can have my program find it? Or better
still, get it found by some Windows default?

[Tim Reed]

"Randy Birch" <rg************@mvps.orgwrote in message
news:01**********************@news.astraweb.com...

Note though that ShellExecute performs the action specified based on the
file association of PDF. If a user or another application has modified
PDF
from opening with Adobe Acrobat, your dad's users won't or may not get the
result he expects.

You can use the FindExecutable API to determine what file is currently
associated with PDF files. Acrobat reader's exe is named either acroread
or
acrord32 depending on the version; the full version of acrobat uses a
different file (acrobat.exe?). To use FindExecutable you point the API at
a
file of interest (e.g. the PDF file or any dummy (empty) file that has a
PDF
extension that you create), and the call returns the executable used to
open
that file based on the registry settings of the user.

By using FindExecutable he can therefore determine/ensure the exe file
name
matches an application appropriate for his PDF help file (by testing the
return value with Instr()), then - his choice - either use exe returned
from
the call to open the PDF file directly (the full path and filename is
returned), or proceed to call Shell Execute knowing that will open the
file
as expected.

A FindExecutable demo can be seen here
(http://vbnet.mvps.org/code/system/findexecutable.htm) and a complete
example of what Shell Execute can do can be seen at
http://vbnet.mvps.org/code/shell/shellexecute.htm

Thanks for the additional info, I have passed it along.

But ... curiously, ShellExecute didn't work for him as expected:

>I never solved the error to the effect that no application was found to
associate with .pdf extention -- which is coo-coo, since clicking on any
.pdf file in Windows Explorer does open it via Acrobat Reader, and I did
find an association via RegEdit.

If invoking a PDF by doubleclicking on it works (opens it in Acrobat
Reader), why would ShellExecute behave any differently?

[Randy Birch]

As mentioned, shellexecute honours the associated file setting in the
registry. As long as the registry entries for pdf and acrobat file are
proper, and the parameters used in making the shellexecute call are valid,
there is no reason why shellexecute would fail that I know of.
--
Randy Birch
MS MVP, Visual Basic
http://vbnet.mvps.org/

Please respond to the newsgroups so all can benefit.
"Tim Reed" <da**************@comcast.netwrote in message
news:a-******************************@comcast.com...

"Randy Birch" <rg************@mvps.orgwrote in message
news:01**********************@news.astraweb.com...

Note though that ShellExecute performs the action specified based on the
file association of PDF. If a user or another application has modified
PDF
from opening with Adobe Acrobat, your dad's users won't or may not get the
result he expects.

You can use the FindExecutable API to determine what file is currently
associated with PDF files. Acrobat reader's exe is named either acroread
or
acrord32 depending on the version; the full version of acrobat uses a
different file (acrobat.exe?). To use FindExecutable you point the API at
a
file of interest (e.g. the PDF file or any dummy (empty) file that has a
PDF
extension that you create), and the call returns the executable used to
open
that file based on the registry settings of the user.

By using FindExecutable he can therefore determine/ensure the exe file
name
matches an application appropriate for his PDF help file (by testing the
return value with Instr()), then - his choice - either use exe returned
from
the call to open the PDF file directly (the full path and filename is
returned), or proceed to call Shell Execute knowing that will open the
file
as expected.

A FindExecutable demo can be seen here
(http://vbnet.mvps.org/code/system/findexecutable.htm) and a complete
example of what Shell Execute can do can be seen at
http://vbnet.mvps.org/code/shell/shellexecute.htm

Thanks for the additional info, I have passed it along.

But ... curiously, ShellExecute didn't work for him as expected:

>I never solved the error to the effect that no application was found to
associate with .pdf extention -- which is coo-coo, since clicking on any
.pdf file in Windows Explorer does open it via Acrobat Reader, and I did
find an association via RegEdit.

If invoking a PDF by doubleclicking on it works (opens it in Acrobat
Reader), why would ShellExecute behave any differently?