Sending report by using default email client

rbuser

I need to send reports trough the default email client installed at the
customer machine (mostly Outlook, Oulook Express or Thunderbird). In the
past, the default SimpleMAPI plugin of ReportBuilder has done the work
very well, but with most recent versions of Windows, the SimpleMAPI
seems to be completely unstable. Sometimes it works, sometimes doesn't.

I searched the internet and found several people complaining about this
problem, but could not find a real solution.

Does anyone knows how to solve this problem?

Thanks,
Carlos

nicocizik

Hi Carlos,

There are two issues to be aware of when using MAPI with the latest
versions of Windows/Office.

1. Both the application and the email client (Outlook) need to use the
same CPU architecture (x86 or x64). If your Delphi app is built for x86
and your customer installed the x64 version of Outlook, MAPI will no
longer function correctly. See the MAPI section of the following article.

http://msdn.microsoft.com/en-us/library/office/dd941355.aspx

2. If Outlook is open on the machine while MAPI is trying to access it,
both applications need to have the same security context. If, for
instance, your app is running with Administrator privileges and Outlook
is running with User privileges, an error will occur. See the following
article for more info.

http://www.digital-metaphors.com/rbWiki/Output/Email/Troubleshooting..._Cannot_Preview_Email

rbuser

Em 25/10/2012 11:33, Nico Cizik (Digital Metaphors) escreveu:

Hi Nico! Thanks for answering.


My app is 32bits, and customer is using Thunderbird and OpenOffice, both
32bits, so I think this is not the case


The tech guy who gives support for my customer told me that UAC is
disabled in the machines, so I think user privileges would not apply in
this case.

Any more ideas?

Carlos

nicocizik

Hi Carlos,

Thunderbird/Mozilla claims to offer minimal support for MAPI however in
our experience, it is very unreliable. See the following article on
things you can do to troubleshoot using Thunderbird and MAPI.

http://kb.mozillazine.org/MAPI_Support

rbuser

Em 29/10/2012 15:11, Nico Cizik (Digital Metaphors) escreveu:

Yes, the MAPI support for Thunderbird was always listed as "partial",
but it worked fine in the past, and it works fine in my machine. I wasnt
able to find why things doesnt work (or stopped to work) in several of
my customers machines

Carlos

rbuser

Answering myself, it seems that I found out what the problem was.

Seems that in some machines, with specific Windows versions and
different environments, the email function from RB will not work (the
email client will not "respond") if you leave the Subject field of the
email empty in the EmailSettings of TppReport.

I could not find what causes this behavior, since even with the Email
Subject empty, it worked in some machines (including my development
machine) and didnt work in others.

HTH,
Carlos

Em 25/10/2012 11:17, Carlos escreveu:

nicocizik

Hi Carlos,

Thank you for the update. I will keep this in mind if this issue every
arises again.

rbuser

I'm still having problems with some customers machines, when clicking in
the email button does not call the email client app (MAPI).

Using debugging technics from the "paleozoic" era (since the problem is
not reproduceable in my development machine), I was able to trace it to
the following line in ProcessAndSend in ppEmail.pas:

if (lReport.Initialized) then
lReport.PrintWithSameParameters;

The execution is silently aborted after the PrintWithSameParameters is
called.

Playing with the Filename property of the EmailSettings, I was able to
find out that when I specified a file name in the root of drive C,
everything works fine. For reasons that I do not understand, RB is not
being able to generate the report file (PDF) in the temporary folder
(%temp%). I confirmed this trying to export the report to that dir, and
got a "permission" error when file was being created. Even more weird,
other reports in other forms of the same executable seems to be able to
export the reports to the temporary folder with no problem.

The machine was running Windows 7 Pro 32bits, with UAC disabled. RB 10.09

Those weird "send email" problems are driving me crazy... already spent
so many hours trying to detects and fix it and weird stuff is still
poping out. I count not continue my debbuging since customer internet is
now down.

Any ideas of what is going on?

Carlos



Em 08/11/2012 12:09, Nico Cizik (Digital Metaphors) escreveu:

nicocizik

Hi Carlos,

I'm a bit unclear about the issue. I appears you are unable to write to
a file from RB within your application. This would imply that you do
not have access to write to the location defined. You might check your
user's machine to be sure any file can be written to the temp directory
from an application.

ReportBuilder does not do anything special when exporting to file. It
simply opens a file stream and writes to it. You can see the
TppFileDevice class for how this is done.

Note that for RB 14, we added a feature that allows you to export
directly to a memory stream, then attach that to an email and send.
This avoids the need to write to file before emailing.

rbuser

Em 26/11/2012 17:31, Nico Cizik (Digital Metaphors) escreveu:

The weird thing is that other reports created in other forms (in the
same application) are working fine.

The customer internet is still down, so I could not continue the
debugging, but I never heard about file writing permission problems
behaving differently in the same executable.

Carlos

rbuser

Here is the final conclusion about this case:

I found that there was a READONLY file in the temporary directory of the
customer, with the same name of the file specified in the FileName
property of the TppReport.EmailSettings.

This raises an exception when FileDevice tries to create the fileStream,
but the expcetion is never shown to the user, due to the

try
...
except
end;

of the TppEmail.Send method! The Send method is hiding any kind of
expections that may occur during the email sending proccess! This made
me spend several hours accessing the customer machine for debugging,
trying to figure out what was going on. If I could see the exception
message, it would not take more than 1 minute to figure out and solve
the problem!

Now the question is: why DM decided to hide the exceptions?

Carlos

Em 26/11/2012 17:31, Nico Cizik (Digital Metaphors) escreveu:

nicocizik

I believe the exception was suppressed in this case for older versions
to avoid common but non-harmful exceptions related to sending emails. I
will re-add code to raise an exception for the next release of
ReportBuilder in this case and see if perhaps the updated Email feature
can function with it in place.

rbuser

For now, I just changed the Send method to something like:

try
...
except
on e:exception
messagedlg(e.message,mterror,[mbok],0);
end;

So, a exception will still not be raised, but at last a message with the
error will be displayed to the user.

Carlos

Em 27/11/2012 15:30, Nico Cizik (Digital Metaphors) escreveu: