Runtime Users Guide

[mporter]

I have created a users guide as a pdf file that I want to distribute along with my runtime database. My plan is to put it in the same folder with the other runtime files and have an item in my custom help menu open the pdf.

What's the best way to do this? I've tried using the script step Open URL but I'm having trouble getting it to work with a relative file path.

Open URL works fine with an absolute file path like this:

"file:///Users/mporter/Documents/BirdBrain/myfile.pdf"

However, I can't get it to work with a relative file path. Perhaps I'm not formatting my relative file path correctly. Or maybe Open URL doesn't work with relative file paths.

Maybe there is a better way to accomplish this? I want to use a relative file path so no matter where the customer moves the runtime folder, the help file will still open.

My goal is to just to have a menu item open a pdf file in the same folder as my runtime database. That should be easy.

Thanks for your suggestions.

[Ocean West]

Host the pdf on your site and just have the user goto a layout with web viewer to download the file - this way if you make changes to the document you have one source - you could even create a method to notify the user that the support document has been updated.

[TheTominator]

Create a global container field.

Insert the PDF file as a reference.

User can then view the PDF using the platform's normal PDF reader application by double-clicking on the PDF file icon in the container field.

You can open the PDF document in the container via a script using Go to Field [select/perform; YourContainerField].

Edited October 24, 2009 by Guest

[mporter]

Create a global container field.

Insert the PDF file as a reference.

User can then view the PDF using the platform's normal PDF reader application by double-clicking on the PDF file icon in the container field.

You can open the PDF document in the container via a script using Go to Field [select/perform; YourContainerField].

Thanks. This suggestion works beautifully.

[bcooney]

Did it? Did you copy the runtime folder to a different workstation and confirm the pdf opens? I'm wondering if the path info will hold up when you move.

Stephen's suggestion is the most elegant, but requires a website. You could simply embed the pdf rather than ref it. (Runtimes are huge, anyway, lol!).

[TheTominator]

I'm wondering if the path info will hold up when you move.

It should be fine as long as the referenced PDF is inside the runtime's project folder (or a nested subfolder).

Referencing a file outside the database file's folder will break as you describe since it will generate an absolute filepath.

[mporter]

Thanks again.

Just to confirm that I'm putting the referenced PDF in the runtime project folder and the link from the container field continues to work fine even when the folder is moved.

And thanks, bcooney, for your question. Now I know when when an absolute rather than a relative filepath gets created. Knowing that will keep me out of trouble down the road.

This forum is incredibly useful to intermediate FM users like me.

[TheTominator]

Now I know when when an absolute rather than a relative filepath gets created. Knowing that will keep me out of trouble down the road.

In my recent testing with FileMaker 10 on Macintosh, I found that when you insert something by reference into a container field, FileMaker creates both an absolute and a relative reference for the contents. This redundancy gives you a little leeway in relocating your FileMaker file. The relative reference comes first in the priority list. Note that on a Mac, the absolute reference starts with "imagemac:" or "filemac:" as appropriate. I presume on Windows it would start with "imagewin:" or "filewin:".

If the file is located outside of the current folder or its subfolders, the relative path uses ".." to go up a folder ("../.." goes up two folders.) so when the file is first referenced, both methods work to refer to the file. You don't have to have the referenced file in the same folder or its subfolders for the relative path to be used.

Depending on how you subsequently move the FileMaker database file and how the image is located relative to the FileMaker file, these two forms of reference may or may not break.

[mporter]

In my recent testing with FileMaker 10 on Macintosh, I found that when you insert something by reference into a container field, FileMaker creates both an absolute and a relative reference for the contents. This redundancy gives you a little leeway in relocating your FileMaker file. The relative reference comes first in the priority list. Note that on a Mac, the absolute reference starts with "imagemac:" or "filemac:" as appropriate. I presume on Windows it would start with "imagewin:" or "filewin:".

If the file is located outside of the current folder or its subfolders, the relative path uses ".." to go up a folder ("../.." goes up two folders.) so when the file is first referenced, both methods work to refer to the file. You don't have to have the referenced file in the same folder or its subfolders for the relative path to be used.

Depending on how you subsequently move the FileMaker database file and how the image is located relative to the FileMaker file, these two forms of reference may or may not break.

Let's see if I understand.

When FileMaker looks for a referenced file in a container field, it first tries the relative filepath. Then, if it's not found, it tries the absolute filepath.

In the simplest case, the file being in the same folder as the runtime, the relative filepath should never fail. No matter where that folder goes, the relative filepath won't change and the reference should never break.

So I'm not sure about your last sentence. Are you referring to cases where the file is located outside the runtime folder and its subfolders?

[TheTominator]

When FileMaker looks for a referenced file in a container field, it first tries the relative filepath. Then, if it's not found, it tries the absolute filepath.

Correct.

In the simplest case, the file being in the same folder as the runtime, the relative filepath should never fail. No matter where that folder goes, the relative filepath won't change and the reference should never break.

Correct. That is the solution I recommend.

In my FileMaker runtime solutions, I keep referenced images and files in dedicated subfolders of the runtime folder.

So I'm not sure about your last sentence. Are you referring to cases where the file is located outside the runtime folder and its subfolders?

Yes. References are fragile when they are to files outside of the FileMaker file's present folder (or subfolders).

Because of the redundancy built into the FileMaker container references, there is sometimes a pitfall if you've been moving your runtime around on the same computer and forgot to move one of the corresponding referenced files. The absolute reference may still work and the mistake could go unnoticed until the project is moved to another machine (or worse shipped to a customer).

[mporter]

Thanks. Got it.