Using the latest release, it forces to upgrade the PDFX driver and it creates the PDF-X standard, but the //PDFX,Email.To and //PDFX,Email.Subject are printed in the PDF itself instead of processed as commands. Can you reproduce this there?
What kind of sample you need? I haven't done any change to programs, and after upgrade the PDFX from Printer 2012 to Standard, instead of launch the email client (outlook), it prints the PDFX commands in the PDF, like in the attached picture.
I have been able to reproduce a problem in which all of the //PDFX,Email.xxx directives appear in the generated PDF file, but only when using Methods 0-2. At this point I'm not sure if it's as simple as that (i.e. we've moved away from the built-in Methods 0-2 and may have overlooked a new problem with them), or if it's a combination of factors. I guess what I'd really like to see is the set of //PDFX directives in your file. You can blank out any login info; I'm really just interested in which directives, which Method, etc.
Previously, I have the "//PDFX,Email.Method,6" after the other PDFX commands, now I moved it up, to be the first one, what I think it's irrelevant, but something changed. 1. The PDFX statements are not printed on the PDF file anymore; 2. An authorization message pop up to allow an external program to access Outlook (or Thunderbird); 3. After click Allow, the A-Shell debug message open with a MAPI error 2 4. The email window do not open
This started after install the PDF driver on the image and that, after update A-Shell because the PDFX Printer 2012 is not supported anymore. I don't remember since when that PDFX update got mandatory, but I moved back to 6.5.1699.0c, re-installed the PDFX 2012, but still has the same problem. But I didn't remove the new PDFX Standard and now I don't know if it's some mix of things running here.
Version 9 of the PDF-XChange driver API ("PDF-XChange Standard" driver, current version I have is 9.2.359) was adopted in 6.5.1710 (last December). Unfortunately, since it uses the same ActiveX Interface Object as the prior version, it was impossible to simultaneously support them both. And to be honest, I'm not quite sure how the two driver versions share the same interface. I do have them both installed, and can print to them separately from two versions of A-Shell (one prior to 1710, and the one current), but the behavior is the same (I suspect because the interface is the same).
The fact that changing the order of //PDFX commands is disturbing but not completely surprising, since the commands are effectively passed to the interface as they are scanned, and it's essentially impossible to see the logic on the other side of the interface. Which is all the more reason why we should try to use the same set of commands so that I can then experiment with permutations here.
Here's the exact file I'm printing (email1.txt) ...
Code
//;PDFX Email test
//PDFX,Email.Method,6
//PDFX,Email.Subject,"Test Message"
//PDFX,Email.To,jack@microsabio.com
//PDFX,Email.From,admin@microsabio.com
//PDFX,Email.Content,"This is a simple PDFX email test using Method 6"
//PDFX,Email.Content,"Attached is a Hello World PDF"
//;AttachFile only works with 4+
//PDFX,Email.AttachFile,email1.txt
//PDFX,Save.ShowSaveDialog,false
//PDFX,Save.WhenExists,Overwrite
//PDFX,Save.RunApp,false
//;And this is the document attached to the email.
Hello world!
It pops up this message...
And then sends the message. I'm using Thunderbird rather than Outlook, so it's possible that there is some difference in the way the two clients handle the message. The one oddity I note is that even though there is only one "From" in the file, Thunderbird sends the message twice, once using the From listed above, and once using my default email configuration identify. (Which makes me wonder whether it is possible that other email clients might react differently to a mismatch between the from address in the MAPI request and its own default from address?) The message(s) show up in my Sent folder immediately, with the two attachments, and the PDF correctly contains only the line "Hello world!". (It doesn't always show up in my inbox right away, but I think that's a separate issue with gmail deciding I'm sending too many messages to myself.)
It seems that we have multiple discrepancies, making it harder to focus on what is going on. One set of problems relates to the PDF generation, in which under some conditions, the //PDFX directives appear in the PDF document as if they were text (i.e. as if they were not recognized as directives). Another set of problems relates to failure to send the email. Because there are so many permutations, I usually think the best approach is to try to start with a set that works for both of us, and then figure out what breaks it. Since Method 6 involves a component that is difficult to standardize, do you think we can start with Method 4 (requiring you to plug in your SMTP info)? If we can't even get that to work, then we're going to be running around in circles.
Good afternoon, Regarding versions, we are ok, both using the last available for PDFX and A-Shell. I copied your code above to create the same email1.txt and print it. The message pop-up but after nothing happens. I tried in my laptop with Outllook and got the MAPI error2 message, but in a customer, using Thunderbird, the error 2 doesn't occur and no message is sent.
Anyway, I think that with the previous driver, the message wasn't send immediately, it was opening the email "new message" dialog on the email client allowing the user to do any adjustment before send it.
Considering that, in both cases (Outlook and Thunderbird), the email is reaching the email client, because the "Confirm" message pop up, where can it be the problem? Any incompatibility with the new PDF driver, maybe regarding security or the internal structure of the generated message?
Well I'll keep trying, don't know exactly where to from here, but I'm in the fight Thanks
Wait, I've just changed to Method 5 and it worked as expected. The new message window opened with the PDF attached and all data (email addresses, subject, body) correctly filled in, and it was delivered after click SEND.
Let me first confirm that using Method 5 here it doesn't pop up any message but it does open a new email message (addressed according to the //PDFX directives) waiting for the user to complete and send it. (That's with Thunderbird here.)
Method 6 should pop up the confirmation message (assuming it hasn't been disabled by unchecking the option to keep asking for confirmation) and then send the message. Did you check the Sent folder? (As noted previously, my messages appear twice in my Sent folder, but don't always get delivered, although I believe the delivery problem is outside the scope of our control here.) As you noted, clearly if the confirmation messagebox appears, then the driver is communicating with the email client, but unless the message shows up in the Sent folder, we can't be sure that the email client actually "accepted" it.
The MAPI 2 error message is the one that has scared me away from trying to use Method 6. Every Windows update seems to throw an additional wrench into the MAPI communication channel (used by apps like A-Shell to communicate with the email client). The reasoning may be good (trying to foil spammers who gain access to your computer and contact list to send messages that appear to be coming from you). But it makes it hard to support remote users who are subjected to new variations of the restrictions outside your control.
Maybe we should focus on why you aren't just bypassing the email client and using Method 4 to talk directly to the SMTP service? The main problem there is getting the information from the end user (who often doesn't even know because someone else set up their email for them). There's also a security concern in having the password in the source document, but you can use encryption on it. Here's what that email1.txt document looks like when I use Method 4 ...
Code
//;PDFX Email test
//PDFX,Email.Method,4
//PDFX,Email.Subject,"Test Message (method 4)"
//PDFX,Email.To,jack@microsabio.com
//PDFX,Email.From,admin@microsabio.com
//PDFX,Email.SMTP.Address,mail.microsabio.com
//PDFX,Email.SMTP.Port,465
//PDFX,Email.SMTP.UserName,admin@microsabio.com
//PDFX,Email.SMTP.Password,C0/Lmm4dEXNJXRjAfLk/CvCELLNNehyMISVM...
//PDFX,Email.SMTP.UseSSL,1
//PDFX,Email.Content,"This is a simple PDFX email test using Method 4"
//PDFX,Email.Content,"Attached is a Hello World PDF"
//PDFX,Email.Content,"And also a copy of this source doc"
//;AttachFile only works with 4+
//PDFX,Email.AttachFile,email1.txt
//PDFX,Save.ShowSaveDialog,false
//PDFX,Save.WhenExists,Overwrite
//PDFX,Save.RunApp,false
//;And this is the document attached to the email.
Hello world!
It's not a nightmare to change that, but something changed with this new driver. But I'm still trying to understand what's going on here because, reading the documentation, it seems that Method 5 always open the "new message" dialog and Method 6 will do it only when some information is missing that do not allow the message to be delivered unattended (e.g. missing TO).
But the truth is that, I was using Method 6 and now it doesn't work neither silently nor with user intervention.
1. Yes, I've checked the sent folder and nothing new get there 2. I also use Method 4, where the process is fully automated and even handle the log file, but there other cases (e.g. orders for suppliers) where the users want to check the message before sending it and also organize the messages so, the email client is the best option
I think I'm fine by now switching to Method 5 and, by the way, will check if Method 4 is still running fine.
One probably important detail that I should have clarified earlier: Method 5 and 6 do not use the PDFX driver for the email operation. Instead A-Shell has it's own code to call the MAPI functions necessary an external app to get the email client to either open a new message or send one unattended. So in theory it should have nothing to do with which version of the PDFX driver you were using. However, it's possible that somewhere around the same time A-Shell may have have gotten recompiled with updated libraries, or the Windows systems in question may have gotten updated, either of which could have affected the MAPI setup.
A couple of other other details of possible interest:
1) If the MAPI call to pass the message to your email client fails, an error will be logged to the ashlog.log file. (Search for "MAPISendMail error")'
2) Communicating over MAPI between a 32 bit app (A-Shell) and a 64 version of Outlook or other email client requires considerable jumping through hoops. In theory it should still work, but if you're having inconsistent results, that would be a detail of interest. (I'm going to try experimenting here with a 64 version on another computer.)
Regarding this problem, I've adjusted to Method 5 but it only work with Thunderbird, with Outlook it always triggers MAPI Error 2. It's not a problem because all my customers are on VMs online where I can choose the email client because they only use it there for the purpose of sending emails from A-Shell.
Jack, just reporting here to let you know because, definitely, there is a problem with this update that can become a problem to others.
There a lot of complaints on Internet message boards about MAPI Error 2 with one application trying to send a message via Outlook. One response which seems to have help some people is:
Quote
The application initiating the MAPI request needs to have the same user context as Outlook. Often it is the case that one will be running as Admin and the other as User.
Does that seem like a possibility?
Another possibility appears to relate to whether the requesting app and the email app can share a MAPI session or should try to start a new one. Traditionally we have always used the share option, but if you want to try the new session option, add +2 to the Email.Method (i.e. Method,7 or Method,8). The main concern about starting a new session is that if the email client requires a special login, the request will fail unless we add some additional parameters. I doubt that many A-Shell environments where emailing from the app would need that, but there may be some other complications (like ending up with too many MAPI sessions?) that I don't yet understand. In any case, the new option is enabled in ...
Ugh. I haven't been able to get a proper Outlook client configured, but I have reproduced the error using Microsoft Mail. But for me, it's identical whether I use an older A-Shell with PDFX5 (Printer 2012) or the latest 6.5.1720.1 with PDFX Standard. And it makes no difference whether Method,5 or 7. But, all configurations work fine with Thunderbird.
So at least in my environment, the issue seems to be that the Microsoft-based email clients are blocking the MAPI interface. I guess it's back to the Internet to search for how to let down that barrier.
I've done some further testing, on one computer with 32 bit Outlook and another with 64 bit Outlook, but both get the same MapiSendMail error 2. (Something I get error 3, which is a login error.) So far all of the suggested causes for this error have to do with mismatches between the security level of the caller (A-Shell) and the email client, but that doesn't seem to be the case here, as I've even tried running both as Administrator. Unfortunately it's difficult to debug, because the Error 2 doesn't tell us very much, and it's kind of black box interface. The interface routine is in MAPI32.DLL, which there are several versions of floating around, so it's possible that if it worker earlier it was due to some difference there, but I haven't seen any suggestions that there was a bad version and a fixed version.
Hi Jack, I've been around this topic all day because more users than I thought were using Outlook so I'm installing Thunderbird concurrently and it's doing fine that way. I've also done some research and, curiously, I found more about MAPI problems using Thunderbird than with Outlook. So, I'm on the field about this and, because of me, you can relax by now considering that I have an work around.
Well, it seems the new driver is less tolerant with incorrect PDFX commands. I found that was always sending the command: //PDFX,Email.ZIP,0 With the new driver, that command is printed in the upper left corner of the PDF and it was aborting the send of the email. After remove that command from the print file, even the Outlook started to work in my computer(*).
So, the most important is that email is now fully functional. Anyway, regarding the //PDFX,Email.ZIP seems that it's not working, it's almost irrelevant, just if you want to check.
I think this topic is closed, many thanks for all the support.
(*) I've installed this patch in a customer that was switched from Outlook to Thunderbird and reverted to Outlook, but there, it didn't work, still getting the MAPI Error 2, but we know how difficult and environment dependent this is so, I'm checking
This is a mysterious one. I don't see how it ever could have worked except with Methods 0-2 (which are handled internally by the PDFX driver). The other methods are handled by A-Shell, and I don't see any logic that ever checked for that directive. When I insert that directive, I get these log messages:
It may be that if you want to use the local email client (e.g. Outlook) to complete the emailing operation for a PDFX-generated document that the original Email.Methods 0 or 1 (in which the driver communicates directly with the client via inscrutable channels) work better than Methods 5-6 (in which A-Shell tries to use the standard MAPI interface). That's especially true if you want to use the ZIP option, but as you'll see from the ash65notes, there are pros and cons to each approach.
Good morning, This was the perfect week start, yesterday, I just didn't found the moment to come here and report, after a successful test. Switching from method 5 to 0 completely solved the problem and, also, confirmed that ZIP works. Before switching, I tried method 5 with the new release and got an MAPI error 11, meaning attachment file not found, much different from the previous error 2, meaning nothing. Anyway, that was not true because the file exist with the correct name and folder, but I believe it could be some problem with Acrobat Reader locking the file considering that I open for preview. I'm checking that but I've distributed my module adjusted to method 0 and solved the problem on the field.
Many thanks
Last edited by Jorge Tavares - UmZero; 27 Sep 2207:04 AM.
Glad to hear that the restored functionality of Methods 0-1 solved the issue for you. I wish I knew what the PDFX driver is doing differently than A-Shell is (the internet is full of problem reports with MAPI without much resolution), but it's nice to have options. (Although you have to watch out for the fact that support for some of the other Email options differs between Methods 0-2 and Methods 4-6)
![[Linked Image]](https://www.microsabio.net/ForumImages/email1.png)
