mobilecomposemail tAttachment["type"] for a pdf SOLVED ?

[jmburnod]

Hi All
I played with mobilecomposemail with attachment.
I tested for .txt and .jpg files and it works well
I'm wondering what is the correct keyword tAttachment["type"] for a pdf
(if that is possible for a pdf)
Best regards
Jean-Marc

[Simon]

Hi Jean-Marc,
The mime type is
application/pdf

Simon

[jmburnod]

Hi Simon,
Thanks again.
I haven't seen that is not possible to use openprinting for create pdf file on IOS
I can live with only jpeg for a moment
All the best
Jean-Marc

[trags3]

I know this conversation ended 7 months ago but I have just:
1. successfully print a card to a pdf file
2.Not successfully figure out how to send the file in an email.

I am able to send a jpg screen shot using a connection to a server to email it with lc server but using the same code the server side arrayDecode fails when I attempt a pdf. I have been directed to try to send it usin JSON but that is even a bigger challenge for me right now.
When I try to utilize the mobileComposeMail method the PDF that gets sent is blank. I know that the file is saved correctly as It works in the simulator.(the save but not the send)
I would be content to use jpg but there is some small print on the card that a screen shot using an iPhone 4s just doesn't have an acceptable resolution. The pdf looks great!
the code related to the attachment is:

put "mypdf.pdf" into tattch["name"]
put specialFolderPath("documents") & "/" & "mypdf.pdf" into tattch["data"] -- this is where the pdf file is saved
put "application/pdf into tattch["type"]
mobileComposeMail tsubject, temail, , , tBody, tattch

I have tries several iterations looking at the dictionary but nothing seems to work.
By the way, I am using LC 7.0.5 on a MacBook Air with OS X Version 10.10.3 and xcode version 6.3.2.

Help Please?

Tom

[Simon]

Hi Tom,
I'm not sure if this is related to the problems you are seeing but there has been a change to arrayEncode/Decode.
http://forums.livecode.com/viewtopic.ph ... de#p119934

Simon

[trags3]

Thanks, Simon. I am using the:
put "data=" & URLEncode(base64Encode(array,"6.7"))) into tdata
form of encode. the 6.7 refers to the method used pre 7.0. Apparently 7.0 and later can accommodate both methods.
This works fine for JPG files but does not for PDF.
The guys at Hostm told me that there are inconsistencies in how Encode and Decode perform with different file types.
They suggested the JSON solution claiming that it is a much more robust solution for passing data.
They had a suggestion that I havent had the time to digest yet.
Instead I thought that I would try the mobileComposeMail solution but I dont have any experience with that approach. So far I havent been able to make that work either.

Thanks again.
Tom

[jacque]

I haven't ever had to use this command on mobile, but the docs indicate you'd want to do this:

Code: Select all

put "mypdf.pdf" into tattch["name"]
put specialFolderPath("documents") & "/" & "mypdf.pdf" into tattch["file"] -- note the change here
put "application/pdf into tattch["type"]
mobileComposeMail tsubject, temail, , , tBody, tattch

Note the change from "data" to "file" in the attachment. The dictionary says you only need one or the other, and if you are passing a file path you don't need the binary data. If you do want to use the actual binary data instead, then use "data" as the array key but do not urlEncode, base64Encode, or arrayEncode it; leave it as binary. The script can get the binary data by putting url ("binfile:" & path/to/file) into the data element of the array.

Worth a try, anyway.

[FourthWorld]

Thanks, Simon. I am using the:
put "data=" & URLEncode(base64Encode(array,"6.7"))) into tdata
form of encode. the 6.7 refers to the method used pre 7.0. Apparently 7.0 and later can accommodate both methods.

If that code runs without error it may be a case of incomplete error checking, as base64 is a common standard unaffected by any changes in LiveCode. The optional second argument for a version-specific format is used only by the arrayEncode function, and only needed if you're encoding arrays in v7 that will later be decoded in v6.7.

The guys at Hostm told me that there are inconsistencies in how Encode and Decode perform with different file types.
They suggested the JSON solution claiming that it is a much more robust solution for passing data.
They had a suggestion that I havent had the time to digest yet.

I've been impressed with HostM in my correspondence with them. What was their suggestion you haven't had time to digest?

[jacque]

Thanks, Simon. I am using the:
put "data=" & URLEncode(base64Encode(array,"6.7"))) into tdata
form of encode. the 6.7 refers to the method used pre 7.0. Apparently 7.0 and later can accommodate both methods.

If that code runs without error it may be a case of incomplete error checking, as base64 is a common standard unaffected by any changes in LiveCode. The optional second argument for a version-specific format is used only by the arrayEncode function, and only needed if you're encoding arrays in v7 that will later be decoded in v6.7.

There are a number of problems with the statement that would cause failure:

1. "data=" is a format used by GET and POST commands, but not for sending email.
2. "base64Encode(array)" will always be empty because you can only encode array elements, not the array as a whole. That's why the PDF is blank. I suspect, given the extra parameter, the OP meant to use "arrayEncode" instead.
3. ArrayEncoding the data will fail on the receiving end because it no longer contains the binary data of the PDF file.
4. Base64Encoding the data may also fail for the same reason, depending on how the receiver reacts.

The base64Encode(arrayEncode(whatever)) syntax is good for sending data to a server, where it can be deconstructed by a LiveCode script at the other end. But the result isn't decipherable by any other apps.

[trags3]

Thanks Jacque, Simon and Richard.
I hope to try all of this over the weekend.
Here is what the HOSTM people told me: (by the way they are extremely responsive when asked a question)

"Both JPG and PDF are binary files.
Although, whether or not an array contains binary data shouldn't (isn't intended by LiveCode Ltd) to make any difference when it comes to transmitting arrays via arrayEncode and arrayDecode.
On the other hand, we have on some occasions encountered unexpected/unexplained issues with arrayEncode and arrayDecode, and this could be one of those.
On the client side, try doing a base64Encode() on the array element containing the PDF before transmitting the array using your usual (unmodified) arrayEncode statement.
Then, after receiving it at the server side using your usual (unmodified) arrayDecode statement, do a base64Decode() on the same array element."


They also offered the following after not hearing back from me quickly:


"Just checking in to see if you've resolved the issue regarding sending PDF files.
If not, we have a new general-purpose LiveCode API demo that we can place in your account if you like, so you can perhaps extract some code or ideas from it for your specific usage.
This 100% free API demo is meant to provide LiveCode users with examples of how to communicate between a LiveCode desktop/mobile app and a LiveCode server script.
The current examples are mostly about connecting to MariaDB/MySQL, but one of it also shows how you can transmit files over. It does work with PDF, PNG, and JPG (and likely pretty much any other file type).
The API demo relies on JSON rather than arrayEncode/arrayDecode, and therefore appears to be more robust.
It also works with both LiveCode 6 and 7, both on the server side and on the client side. arrayEncode/arrayDecode seems to be more finicky when different LiveCode versions are involved, even when a specific version is specified for arrayEncode.
Another benefit of using JSON is that the LiveCode-based server-side API can (if desired) be used by client apps written in any other programming language.
If you'd be interested in having a look at the new API demo, feel free to let us know."


This has led me to try easyJSON found here:
https://github.com/luxlogica/easyjson
There is also an external that requires a license for the app I am working on called MergJSON.

I will let you know what I find out.

Thanks again for all the help I get on this forum.

Tom

[jacque]

Tom,

Their advice is valid for files sent to a server, and is the preferred method. They've also apparently built an API to do some of that work for you so that the server can receive and operate on files sent in that format. But that's a different thing from sending files as attachments to email, which uses different syntax and has different expectations.

[trags3]

Thanks Jacque,
I do understand. I have a server account with HOSTM and have an app that I needed to control who gets sent the emails. If you use the mobileComposeMail method the user can delete and add addresses. By using the server to send the emails that can be controlled. The app I'm working on now doesn't require that restriction so mobileComposeMail is a viable alternative.
HOSTM originally helped me set up the server code required to send emails with the server. BTW the LC lesson regarding that has some errors in it and doesn't work. I pointed this out but I haven't checked to see if they have corrected it.

Tom

[FourthWorld]

Here is what the HOSTM people told me: (by the way they are extremely responsive when asked a question)

Glad to hear it, but not surprised. They seem like good folks there, very earnest about what they do.

"Both JPG and PDF are binary files.
Although, whether or not an array contains binary data shouldn't (isn't intended by LiveCode Ltd) to make any difference when it comes to transmitting arrays via arrayEncode and arrayDecode.
On the other hand, we have on some occasions encountered unexpected/unexplained issues with arrayEncode and arrayDecode, and this could be one of those.
On the client side, try doing a base64Encode() on the array element containing the PDF before transmitting the array using your usual (unmodified) arrayEncode statement.
Then, after receiving it at the server side using your usual (unmodified) arrayDecode statement, do a base64Decode() on the same array element."

I also use base64 to transmit encoded arrays, as a way of avoiding possible issues with binary elements being mistaken for control characters. As others here have pointed out, if I manage my HTTP headers correctly to identify that I'm sending binary data I shouldn't need to do that, but I'm lazy and base64 gives me a good confidence across a wide range of use-cases so I keep doing it.

I would be interested in learning more about the "unexplained/unexpected issues" they've had with arrayEncode/arrayDecode. I use encoded arrays almost exclusively in apps where the client is also made in LiveCode, and I'd be happy to lend a hand with their work if they're interested. Feel free to pass along the email address hostmven AT fourthworld.com which I've already whitelisted for them to use; they're welcome to contact me anytime, as I very much appreciate their support of LiveCode.

Their preference for JSON is excellent for systems where the client may be LiveCode or a browser, since JSON libs are widely available for both LC and JavaScript but of course LSON (my pet name for LiveCode encoded array <g>) is only supported by LiveCode.

The EasyJSON library you found is a very good one, generously donated to the world under Public Domain (the author should get a medal or at least a beer for his generosity). It's well written and is indeed easy to use.

I still prefer sticking with encoded arrays when I know the client will be LiveCode, as it saved the intermediary steps and translating to and from JSON. If HostM is interested in learning the few small tricks needed to use them robustly I'd be very glad to help if they have a moment to write to describe what they've encountered.

[trags3]

Thanks Richard, I will let them know after I get everything working. I will certainly let them know of your offer. By the way I'm not quite sure where their support staff is located but their servers are in Germany.

Tom

[quailcreek]

Hello,
I've run into a similar situation. Trying to attach a pdf to an email. The user is allowed to choose either a hard copy or email the pdf. The hard copy part works fine. But I've tried a number of different combinations of ["file"], ["type"] and ["name"] but still no-joy. What am I doing wrong? I'm running LC 6.7.6

Code: Select all

 put specialFolderPath("Documents") & "/Quote.pdf" into tPDFFile
   if there is a file tPDFFile then
      delete file tPDFFile
   end if
   
   set the printmargins to 27,27,27,27-- L, T, R, B
   set the printpapersize to 612,792 -- 8.5x11 inches, US Letter size 612,792
   
   open printing to pdf tPDFFile
   if there is a stack tPrintQuotePath then
      
      print cd 1 of stack tPrintQuotePath
      
      close printing
      close stack tPrintQuotePath
      
      if tAnswer is "Hard Copy" then
         rreHardcopyPrintPDF tPDFFile, "Test PDF Print"
         answer "Print" && the result
      else
         put "Here is the quote for your" && pEventType & "." into tBody

         put specialFolderPath("Documents") & "/Quote.pdf" into tAttachment["file"]
         put "Quote.pdf" into tAttachment["name"]
         put "pdf" into tAttachment["type"]
         -- put "application/pdf" into tAttachment["type"]

         mobileComposeMail "Quote"&& date(),pContactEmail,,tBody,tAttachment
         answer "Email" && the result
      end if
   else
      answer "Print stack missing"
   end if