hollyheadhunter

The Insert File step works ok for letting users on WebDirec on a mobile device to take a photo and capture it.

If a user accesses a file via WebDirect on a mobile device, what is the easiest way to let them take a photo and capture it in the system? Do they have to take a photo outside of the file and then upload it, or there a faster/better way to take the photo and capture it in fewer steps?

Oh, great! Thank you. It sounds like both of these options would work. I used the EmailReadAttachment and it worked from the server in a snap.

Hello, we've been using Email 1.99 for years. Our system is set up so a FileMaker Server script fetches mail. And then when a FileMaker user first opens the message, the attachments are downloaded and inserted in to a container field using the step "Insert File". To improve performance, it would be nice if the server could get those attachments but the step Insert File is not compatible for the server. What options are there for this? If a new version handles this, I'm open to upgrading.

This is now resolved -- the plugin looks for either "html" or "plain" when using EmailSetBody. We were incorrectly using the word "text" instead of "plain".

An update -- when sending an original message (versus forwarding a message) to a couple of test non-Gmail accounts, the attachments go through! The problem remains -- when sending "original messages" to any Gmail accounts (and possibly others), attachments seem to be detected but do not arrive.

We've been using the plugin 360Works Email 1.99 for years and have a new bug. When sending any message from our FileMaker database: the attachments download to temporary place, $attachmentFilepath when calling this function, EmailAttachFile ( $attachmentFilepath ), the result is 1 but the recipient does not receive the attachments (if we BCC ourselves and look at the sent message outside of FileMaker, the attachments are not there) when viewing the sent message in Gmail, in list view Gmail displays a paperclip icon like there is an attachment but there is no attachment If we then go back into the same message in FileMaker and FORWARD it, the attachment sends. Any suggestions on where to begin troubleshooting?

What are some favorite places to read about best practices in navigation for a FileMaker file? In considering the task of rebuilding a file, I'm guessing we need to rebuild in a specific order (1, import tables; 2, re-draw relationships; 3- value lists; 4... import scripts or layouts -- that's where we get stuck). It seems like the ideal situation would be to only have a few scripts that reference any layout. Almost no layouts would use steps "go to layout" or "go to related record" --- only a navigation script would. Do you agree? Before go down that path, I'd like to learn more about it.

Every now and then, upon going into Layout Mode and back to Browse Mode, all layout objects revert to the Default Style of the Layout Theme. The overall theme and other layouts remain unaffected. What might be causing this? I have never had this issue when using FileMaker 13 Advanced on a Mac. It happened consistently when using FileMaker 12 Advanced on a PC, so I assumed the issue was with using Filemaker 12 on layouts that were mostly made in 13... but today it happened a few times when using FileMaker 13 Advanced on a PC. The database is using a custom theme, similar to the built-theme called Enlightened. Its happened on a variety of layouts.

How can the default PDF viewer that a container field uses be changed? For instance, we have a user with the following specs who needs the container fields to use her preferred PDF viewer, NitroPDF but it uses Adobe. Her system specs: - Windows 8 - Filemaker Pro 13 - system's default browser, Firefox - computer's default PDF viewer, Nitro - disabled Acrobat plugin in Firefox How can we get her FileMaker container fields to use Nitro, her preferred PDF viewer?

We've been using the "Email Plugin 1" for some time and we are trying to switch how attachment files are stored -- to FileMaker's remote storage container. When we attach a PDF that has been stored in a container field, the email recipient cannot open the PDF -- it seems to not be a valid format -- they can't be opened. Same with Word docs. However, sending an Excel file worked. We've experimented with PDFs we've made and PDFs made elsewhere. When we download files from the container (versus emailing it), the file format is valid and opens ok. When we attach the file, we are calling the plugin's function: EmailAttachFile ( ATTACH::Attachment ) Any ideas on what we can look into? Update: I found a workaround. Exporting field contents to temporary folder and attaching it from there results in usable files. I wonder why we can't use the step with the remote container field.

Thank you! How would the record ID be used as part of the path name? In the container's FIeld Options, we've selected: Store container data externally Relative to: [hosted location]/Files/MyDatabase Secure Storage On the server, the files are stored in this location: D:FMDataRC_Data_FMSMyDatabaseFilesMyDatabaseSecure Everything appears to be working -- but I'm concerned we may be missing some important part of this and I would like to understand it before proceeding.

When storing files in Container fields, and using the option "Store container data externally", and using Secure Storage (vs Open Storage), and storing the files on a server, is necessary to give the uploaded files unique names? Or is it ok if users happen to upload a lot of files with similar names -- for example if you had a table of People, a field for HeadShot, and a bunch of files are named "Image.jpg" -- would that cause issues? I thought I remembered seeing someone say files needed to be renamed before using this remote storage feature...

I wish I could delete this -- I accidentally posted the same thing twice.

Using the Email plugin (we're using Version 1.972), what is the best way to reply to an HTML message with the original content displayed at the bottom of the new message? Currently, the way we have it set up, when we reply to an HTML message, the original message is truncated/lost/not included in the reply.