Make your own free website on
 Tips & Trix
Launching Acrobat Reader from your Publication 

Grafx Pax
Tips & Trix
Search NeoDezign

If you need to launch Acrobat Reader from your Publication it would seem as easy as a DOSCommand. That's what I thought... As it turned out, it wasn't as easy as that. 

This procedure is not very hard to setup. It's fairly straight-forward. The hard part was figuring out that Acrobat and DOSCommand do not like each other... 

...and another strange thing you can do with Windows shortcut files. 
First of all... give up trying to open your PDF file in Acrobat using DOSCommand. Even the later versions of Acrobat don't work. Of course, we're going to blame it on Adobe. ;) 

This problem occurs when there is a long filename involved in the DOSCommand. If the folder where the PDF file sits is a long filename or, the PDF file itself is a long filename then you will probably get this error message. I found that older versions of Acrobat produce this error regardless of long or short filenames.

The end-goal is to launch the .PDF file using a Windows shortcut and let Windows associations take care of starting Acrobat Reader. The road to get there is a bit odd so, bare with me because the solution, simple as it is, causes some of it's own problems. All have their own individual solution. The only way to explain it all is one-step-at-a-time. 

* Place your .PDF file in the same folder as your PUB. 

* Make a shortcut that points directly to the .PDF file. For this demonstration, name the shortcut "print"

Ex. "C:\Program Files\NeoBook for Windows\MyApp\manual.PDF"

Problem 1: The path in the shortcut is specific to your computer. Normally, you would want to correct this right away. In this case don't worry about it. This will not be a problem... (more on that later) 

Problem 2: When your project is all complete and you're ready to package it as a single Setup.EXE the Installer program will try to package the target file of the shortcut instead of the intended .LNK file. So you need to trick the Installer into packaging it by renaming the extension...

* Open a DOS window to rename the shortcuts' extension.

REN print.LNK print.LN_ 
Because the extension of the shortcut is now renamed to ".LN_" an Installer program will now package the shortcut file. 

* For the Page Action of the first page enter the following script. This script will look for the existence of "print.LNK". If it is not found it will copy "print.LN_" as "print.LNK". 


FileExists "[PubDir]print.lnk" "printexist"
IF "[printexist]" "=" "False"
FileCopy "[PubDir]print.LN_" "[PubDir]print.LNK"

* Make a button with the following Actions... 


MessageBox "Print Manual?" "Do you want to PRINT the Manual?|    ( Requires Adobe Acrobat Reader )" "    Yes    |No" "[AskPrint]"

IF "[AskPrint]" "=" "1"
DOSCommand "print.lnk" "" "Normal+RunOnce"

We're not done yet but, go ahead and test this. It should work ok. 

Now, you're probably wondering about that shortcut and that the path will not work on an end-users system. Actually, it will work. Remember, I said this one was strange! The only way you'll believe me is if you see it for yourself.

* Compile your Publication. 

* Copy your ".EXE", the "print.LN_" and the ".PDF" file to a totally different location. Even another hard drive if possible. Run it. Launch the .PDF file with your Print Button then exit your program.

* From Windows Explorer right click on the "print.LNK" file and select properties to look at the path statement of the shortcut. 

What does the path statement say?

It should reflect the new location! How'd that happen?! 
Who cares? It works!