Hey

We just updated a client to FM16 and got the latest plugin version downloaded. The client sends an email to customers with multiple PDFs attached. These PDFs are held in container fields (local not external), so the code is this:

If ( not IsEmpty ( COR_CustomerOrders::PDF_DeliveryOrder ) ; EmailAttachFile( COR_CustomerOrders::PDF_DeliveryOrder ) ; "" )

and

If ( not IsEmpty ( COR_CustomerOrders::PDF_PickUpSlip ) ; EmailAttachFile( COR_CustomerOrders::PDF_PickUpSlip ) ; "" )

and

If ( not IsEmpty ( COR_CustomerOrders::PDF_AWB ) ; EmailAttachFile( COR_CustomerOrders::PDF_AWB ) ; "" )

 

They reported this morning that when the email dispatched, one of the PDFs attached was named as per the file name with .pdf on the end, but the other two ended up being named "Mail Attachment[2]" and "Mail Attachment[3]" without extensions to the filenames.

For full disclosure, I check the container attributes for the 3 files being sent: 
The two unnamed ones are like this:
Filename: Untitled.pdf
Storage Type: Embedded
MD5: E2F43468863A77CECA78D14746AC45D3
File Size: 102344
Internal Size: 247104
External Size: 0
External Files: 0

The one that was correct is like this (note the filename)
Filename: 201711172305 (dragged).pdf
Storage Type: Embedded
MD5: C91D7D63A73F514F926E0C4FC08AF49D
File Size: 108174
Internal Size: 528790
External Size: 0
External Files: 0

Is there any reason for files named Untitled.pdf to be handled differently? Is it because they are the same name and getting attached to the same email that this happens?

Thanks

Edited November 20, 20178 yr by soundsessential

Hi SoundEssential,

Does this happen consistently? If you change the names of the pdfs in the container fields so that they are unique (ex. change one to untitled1.pdf) do you see the same results?

Thanks Ryan. Turns out the answer is no, it's not happening consistently! I just set up a test record and tried it and it's now working fine. I had the user try it and it worked fine. Let's put that one down to a little gremlin that has gone away.

However, they are now reporting that if one of the container fields is empty that they get an error, despite the code above trying to say if the field is not empty then attach the contents else do nothing. Is there a different way of handling this in one script step? All this does happen in one Set Variable step, from EmailConnectSMTP through Create, Set Body, AttachFile (x3 as above), Send and Disconnect. Do I need to trim the result or anything?

Thanks

Is the error they are seeing a plugin error or FileMaker error? If it is a plugin error, what is the error that they are getting?

It's a plugin error but it's not capturing the EmailLastError. The $result = 0 but EmailLastError is empty. I think I've seen this before when it's all bundled into one Set Variable rather than each step broken out. Do I just need to set each step one by one?

Hey Ryan - don't worry, I set the attach steps as separate set variable steps and it works ok now. That's fine for my purposes.

Thanks for you help. 

I always recommend that users do not call all the functions in one script step because it is hard to trap for errors, amongst other things. The error will be prevalent in the plugin log file but it will be easier to troubleshoot in the future if you change it over to separate function calls and then check for "ERROR" as the value of the variable and then if it equals "ERROR" call EmailLastError and display it in a dialog or set it to a field