Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

Emailing a PDF with remote login


This topic is 6853 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies
Posted

I have written a script in our FM7 database so that the user can click a button and it will generate a PDF of a quote, and then open an email message with some text, an email address drawn from the database, and the PDF as an attachment.

It works great when we're working on the computer that hosts the database, but when we use "open remote" to access the DB from another computer it doesn't work at all. It seems to me that the PDF is being created on the host machine, but the email is being sent from the client machine, so the PDF can't get attached to the email. But I'm a novice at FM so I might be totally wrong about what's going on. Any advice?

Posted

When you create the PDF you are specifying it to print to a file somewhere. That location, such as relative to the database file, will only be available on the host machine (there is no database file on the client machine). Printing happens from/on the client machine.

You need to either use an AppleScript and PDF Services (which is kind of long to explain (search for user BruceR in the AppleScript forum, or search at Apple.com for PDF Services); or print it to a directory that is commonly available (search for fenton and PDF in the AppleScript forum).

"Macintosh HD:Users:Shared:" is one such directory (unless smart alecks have renamed their hard drive).

  • Newbies
Posted

That was exactly what I needed to know. I changed it to a full path that exists on all the machines and it works great! Thank you!

  • 6 months later...
Posted

>I have written a script in our FM7 database so

>that the user can click a button and it will

>generate a PDF of a quote, and then open an

>email message with some text, an email address

>drawn from the database, and the PDF as an

>attachment.

This is exactly what I am after. Are you able to share on how to put together such a script?

  • 4 weeks later...
Posted

When you create the PDF you are specifying it to print to a file somewhere. That location, such as relative to the database file, will only be available on the host machine (there is no database file on the client machine). Printing happens from/on the client machine.

It's actually a bit more than that. When I tried to do the same thing using relative paths while accessing the file from a server, the PDF actually was created, on my local machine, in the same directory as the application itself (in my case, /Applications/Filemaker Pro 8). However, when the email script step used the exact same relative path, it couldn't find the file... I have no idea where it would have been looking.

This is frustrating, because the absolute path solution *sucks* on the Mac! Whoever thought that including the volume name was a good idea?!! That means that any "smart alecks" that have the temerity to customize their hard drive names (if you know Mac users, you'll realize that it's more common than you might think) are unable to use the script. I simply can't believe that they didn't include the capability to provide unix-style paths. If they had actually implemented the file: URL properly instead of creating a look-alike, this wouldn't be an issue: just specify file:///Users/Shared/ and call it a day.

So, basically, I'm not guaranteed that any path exists on all my machines because I know that some of my users have renamed their hard drives. Am I relegated to an AppleScript solution? Anybody know why the "save to PDF" script step and the "send email" script step seem to have two different definitions of the current directory?

This topic is 6853 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.