Open PDF from Menu option

[Johannvdwalt]

I found one previous thread in this regards, but it did not help me with my problem.

I have a slide show (turorial) that has several PDF documents associated with the tutorial. I want to have buttons that will automatically open the PDF document. What I've tried is to call and external program like this: "Acroread32 supportingdocs/detail1.pdf". "acroread32" is the acrobat reader. (lets not digress by talking about the fact that certain people may not have acrobat installed). "supportingdocs" is a sub folder under my PTE project. I use the normal syntax for specifying a relative folder. When I click on the menu option, acrobat reader is started but it cannot find the file specified. It tries to find it relative to acroread32.exe.

I dont think I can make use of a full path as I want to burn the slideshow as well as the supporting documents to a CD and I obviously do not know what the user's CD drive letter will be. How do I overcome a problem like this?

What I hope to find in response is that somebody (maybe the developers) will tell me to use the following environment variable which will contain the path to the executable PTE slideshow, and that I can therefore use that to specify the place for my supporting docs. Something like this:

Acroread32 "%PTE_BASE_PATH%/supportingdocs/detail1.pdf"

This will obviously solve the problem as %PTE_BASE_PATH% will then be expanded to whatever the drive letter and folder name is where my slideshow exists!

Thanks in advance

Johann van der Walt

[JRR]

I found one previous thread in this regards, but it did not help me with my problem.

I have a slide show (turorial) that has several PDF documents associated with the tutorial. I want to have buttons that will automatically open the PDF document. What I've tried is to call and external program like this: "Acroread32 supportingdocs/detail1.pdf". "acroread32" is the acrobat reader. (lets not digress by talking about the fact that certain people may not have acrobat installed). "supportingdocs" is a sub folder under my PTE project. I use the normal syntax for specifying a relative folder. When I click on the menu option, acrobat reader is started but it cannot find the file specified. It tries to find it relative to acroread32.exe.

I dont think I can make use of a full path as I want to burn the slideshow as well as the supporting documents to a CD and I obviously do not know what the user's CD drive letter will be. How do I overcome a problem like this?

What I hope to find in response is that somebody (maybe the developers) will tell me to use the following environment variable which will contain the path to the executable PTE slideshow, and that I can therefore use that to specify the place for my supporting docs. Something like this:

Acroread32 "%PTE_BASE_PATH%/supportingdocs/detail1.pdf"

This will obviously solve the problem as %PTE_BASE_PATH% will then be expanded to whatever the drive letter and folder name is where my slideshow exists!

Thanks in advance

Johann van der Walt

Johann:

No need to worry about the path, PTE will look after it for you.

If you want to open a pdf (or any file) from PTE, create an OBJECT with the ACTION ON MOUSE CLICK on the COMMON tab set to "Open application or file". The using the drop down box below that point to the pdf file.

Include the pdf file in your folder that the other person will copy to their computer.

I assume the tutorial is a manual show

[nobeefstu]

Johann van der Walt,

First lets address your comment below :

(lets not digress by talking about the fact that certain people may not have acrobat installed).

There is no need to call Acroread32 if you dont care whether or not the user has Acrobat reader installed. Actually you may be limiting yourself whereas your users only with Acroread32 can open your PDF documents.

If you use just the relative file string "supportingdocs\detail1.pdf" ... this should be sufficient to open in any PDF Reader a user has installed on their PC. If the user does not have a PDF Reader then the file wont open anyway.

The only need I see to use Acroread32 is if your installing the PDF Reader (portable type) on the CD Disk. But, then you must use its own path string and not the systems.

The commands/strings you want to use if your still determined to do things your own way is :

Relative folder designation:

Acroread32 "supportingdocs\detail1.pdf"

If your working from the Root of a Drive you can also use/lead your filestring with \

[Lin Evans]

Hi Johann,

Keep it simple. Though there are other ways, perhaps the "easiest" way is to simply place all files at the root level on your CD. Make no "folders" and simply call the PDF file by identifying it under the "Run Application or Open File" by name and extension and let the user's operating system find its PDF reader on the computer being used. This works very much as when you use the "run" command in Windows then simply click on a PDF file. Windows "knows" by the extension that it needs to use whichever PDF reader has been installed and identified. For example, I use a "Nuance" reader rather than Acrobat and this works perfectly for me.

Best regards,

Lin

[Johannvdwalt]

Thanks for the quick responses. I was away from my computer for 2 days, so I only testing the suggestions this morning.

The first possible issue is now resolved. It works without specifying the acroread32. I was specifically worried about this as some people uses 64bit machines and then this will not work, and you all are right that there are always people out there who will use another pdf reader. By just specifying the pdf name works. Windows knows which executable is associated with the PDF extension and loads the file correctly.

But the path issue is not working correctly yet. Let me explain what I have tried up to now.

1. I browse to the file from the action of a button. This put the whole path in. I created the executable slideshow and run it. It works. If I then move the executable slide show and the PDF file to another drive and delete it on the original location, it does not work any more. The path stays hardcoded.

2. I change the path to be relative. Example "documents/trainingdoc.pdf" or "documents\trainingdoc.pdf". Does not work at all. Not in the original position or when moved.

3. Move the PDF to the root and change the path to "\trainingdoc.pdf". Works. Moved the executable and pdf to another drive (pdf in the root of the other drive), it still works.

So, seems like no 3 is the only way to do this (quite frustrating). The consequences: as long as the person keeps accessing it from the CD, it will work, but they will not be able to copy it to their harddrive, unless they put all the PDFs (about 20) in the root of their harddrive. Windows Vista is likely not to allow this, and most people will not like to put these files in their root folder in any case.

I tried playing with a batch file, but its a catch 22. Unless I put the batch file in the root, it still does not work, and putting the batch file in the root, is defeating the object.

Is there really no way to specify the path of the executable from the shell command as an environment variable. As a programmer myself it seems so logic!

[Johannvdwalt]

It Works!

The relative path suggestion works. Two things I did wrong: I did not have the quotes arround the pdf name and my last test I did from the PTE designer, which is obviously looking for a relative folder of the PTE executable path (c:\program files\....). I was busy experimenting with a batch file, and when I added the relative path for the batch file, and put quotes around the name, and then createded the executable slideshow it worked. I then did the same with the PDF files, and they also worked. I can now move the executable slide show together with the subfolders to another drive and even another deeper folder structure and it still works, as long as I use the syntax "documents\MyPDF.PDF"!

Thanks for everybody's help on this. Much appreciated

Johann

[Scorpion]

Hi Johann

This syntax offers a more flexible solution to your problem.

Use a "." to represent the folder containing the "program.exe" file and place all files you wish to run in sub folders.

e.g. ".\documents\mypdf.pdf"

You can vary the folder structure above the "program.exe" as you wish, as long as the sub folders containing the PDF files remain relative to it.

Regards, Ken

[Johannvdwalt]

Ken,

For the record, I tested your suggestion and it also works, so both the "relative folder" and "current folder" syntax works.

Thanks

Johann

[nobeefstu]

Just posting some of my notes to help users understand the use of dot{s} . or .. in the filestring.

Example filestring with 2 dots as documented in some .pte files:

E:\1_Mmb\..\Media\4_Music\3Waves\smooth.wav

Two dots ("..") are used for moving up in the hierarchy, to indicate the parent directory; one dot (".") represents the directory itself. Both can be components of a complex relative path (e.g., "../mark/./bobapples"), where "." alone or as the first component of such a relative path represents the working directory. (Using "./foo" to refer to a file "foo" in the current working directory can sometimes be useful to distinguish it from a resource "foo" to be found in a default directory or by other means; for example, to view a specific version of a man page instead of the one installed in the system.)

MS-DOS/Microsoft Windows style

Contrary to popular belief, the Windows system API accepts slash, and thus all the above Unix examples should work. But many applications on Windows interpret a slash for other purposes or treat it as an invalid character, and thus require you to enter backslash. One of the prime examples is the cmd.exe shell (often called the "terminal" as it is typically run in a terminal window). Note that many other shells available for Windows, such as tcsh and Windows PowerShell, allow the forward slash.

In addition "\" does not indicate a single root, but instead the root of the "current disk". Indicating a file on a disk other than the current one requires prefixing a drive letter and colon. This is not ambiguous because colon is not a valid character in an MS-DOS filename, and thus one cannot have a file called "A:" in the current directory.

[Laszlo K]

I have some similar problem to Johann.

I have created a multi page collage of around 80 PTE's. Works beautifully on my desktop and my laptop as well. Any other computer will not respond to a button or thumbnail click to go farther ( second and third page ). Came to the conclusion that on my both computer since the project was created on the Desktop oddly enough but my laptop has the same path to the folders and the EXE's. So it works.

On all others will not.

I have tried to delete part of the path, than using quotation marks than it might work on one out of the four computers but still not universaly like PTE's do.

I did the correction on an external drive and that plays on 3 machines from the drive but not off the copy.

How a project like this could be shared like a PTE.

Regards

Laszlo

[nobeefstu]

Laszlo,

Im a little unclear on some of your details.

I have tried to delete part of the path, than using quotation marks than it might work on one out of the four computers but still not universaly like PTE's do

Are you saying you removed the quotation marks ?

The quotation marks are a requirement esp when using on some other PCs when filename is long or contains spaces. Some PCs may interpret the filestring differently ... the quotation marks are basically instructions to identify properly. My PC will work without quotation marks as long as the file names and paths contain no spaces and are short and simple. Otherwise I need to use the quotation marks.

Also when sharing files among various other unknown users file and drive formats (Fat, Fat32, NTFS) ... its always best to keep your filenames and foldernames as short as possible with no spaces used in its entire path/filestring naming.

Just because it works on your PC ... it does not guarantee it will work someplace else when written to a differntly formated drive/disc. Keeping naming principles as short and simple is the only universal remedy.

Post your entire filestring information as entered in the PTE file. As long as the other users PCs have a PDF Reader we will sort this out.

[cjdnzl]

I found one previous thread in this regards, but it did not help me with my problem.

I have a slide show (turorial) that has several PDF documents associated with the tutorial. I want to have buttons that will automatically open the PDF document. What I've tried is to call and external program like this: "Acroread32 supportingdocs/detail1.pdf". "acroread32" is the acrobat reader. (lets not digress by talking about the fact that certain people may not have acrobat installed). "supportingdocs" is a sub folder under my PTE project. I use the normal syntax for specifying a relative folder. When I click on the menu option, acrobat reader is started but it cannot find the file specified. It tries to find it relative to acroread32.exe.

I dont think I can make use of a full path as I want to burn the slideshow as well as the supporting documents to a CD and I obviously do not know what the user's CD drive letter will be. How do I overcome a problem like this?

What I hope to find in response is that somebody (maybe the developers) will tell me to use the following environment variable which will contain the path to the executable PTE slideshow, and that I can therefore use that to specify the place for my supporting docs. Something like this:

Acroread32 "%PTE_BASE_PATH%/supportingdocs/detail1.pdf"

This will obviously solve the problem as %PTE_BASE_PATH% will then be expanded to whatever the drive letter and folder name is where my slideshow exists!

Thanks in advance

Johann van der Walt

With respect, you are doing it the hard way. You can open a pdf document directly into Photoshop, then immediately save it as a jpg or dng image, which you can then use in PTE directly as a slide. No need to track external documents from within PTE.

When you open a pdf in PS you will get a dialog box which inter alia asks for dpi (ppi), defaulting to 72. Since most pdf's are from a 300 ppi original, I set the PS dpi to 300, which results in an image about 2000*3000 pixels more or less, which you can then resize to your show requirements.

Colin