SendBugReport in 4.0.13
Re: SendBugReport in 4.0.13
4.0.12 was released 2015-04-21, so yes, that's likely the version you were using. Of course I can't know for sure. You might have downloaded before April.
Re: SendBugReport in 4.0.13
It was 4.0.12 but that makes no difference, here are my findings:madshi wrote:4.0.12 was released 2015-04-21, so yes, that's likely the version you were using. Of course I can't know for sure. You might have downloaded before April.
On Windows 7:
32bit: Works via SendBugReport and Mad Dialog "Send Mail"
64bit: Does not work via SendBugReport but still works via Mad Dialog "Send Mail"
On Windows 10:
Both do not work via SendBugReport but still works via Mad Dialog "Send Mail"
Looks like when I did that work I did it in Win32.
That still leaves the Q, how come Mad Dialog Works while SendBugReport fails?
Re: SendBugReport in 4.0.13
That's a good question, I'm not sure myself. In the moment when you call "exceptIntf.SendBugReport", is the madExcept exception box visible? I've checked my code and when the user presses the "send bug report" button I'm also simply calling "exceptIntf.SendBugReport". However, I'm passing the window handle of the exception box to "SendBugReport", while you're sending the handle of the VCL main form. That's the only obvious difference I can see. Try passing "0". Does that make any difference? Also how did you register your exception handler? Did you do it with code (which code?) or by using the TMadExceptionHandler VCL component?
Re: SendBugReport in 4.0.13
What's happening is that SendBugReport is using mailto while "Send Mail" is using MAPI. If I uncheck mailto all works.
There is one more strange thing when mailto is unchecked. If I also uncheck "Send Bug Report in Background" I get an error on both methods
Also if I uncheck MAPI and only check mailto both methods dump the report into the mail body.
So it appears as if SendBugReport is favoring mailto while "Send Mail" is favoring MAPI..
There is one more strange thing when mailto is unchecked. If I also uncheck "Send Bug Report in Background" I get an error on both methods
Also if I uncheck MAPI and only check mailto both methods dump the report into the mail body.
So it appears as if SendBugReport is favoring mailto while "Send Mail" is favoring MAPI..
Re: SendBugReport in 4.0.13
I'm sorry to be blunt, but looking at my source code what you're saying cannot be true - unless checking those options in the madExcept exception dialog results in the wrong settings being set!
Check out "IMEException.SendBugReport" in madExcept.pas. It internally calls madExcept.SendBugReportEx(). And if you search for "mailto" and "mapi" in that function you will see that all the "mapi" stuff is done before "mailto" is even checked. So unless there's some voodoo stuff going on, there's no way that the "mailto" option can have any effect on "mapi".
Furthermore, if you look search for WM_COMMAND in madExcept.pas, you'll find what madExcept does when the user presses the "send bug report" button in the madExcept exception dialog: It calls "IMEException.SendBugReport", which is the same function you're calling. So again, unless some occult stuff is going on, both SendBugReport and "Send Mail" will end up in the very same function called "madExcept.SendBugReportEx()" which does all the work.
I would love to do the debuggin on my PC, but I simply cannot reproduce the problem here. Maybe you can set a breakpoint in madExcept.SendBugReportEx() to check why it uses mailto instead of mapi? Doesn't make any sense to me.
Check out "IMEException.SendBugReport" in madExcept.pas. It internally calls madExcept.SendBugReportEx(). And if you search for "mailto" and "mapi" in that function you will see that all the "mapi" stuff is done before "mailto" is even checked. So unless there's some voodoo stuff going on, there's no way that the "mailto" option can have any effect on "mapi".
Furthermore, if you look search for WM_COMMAND in madExcept.pas, you'll find what madExcept does when the user presses the "send bug report" button in the madExcept exception dialog: It calls "IMEException.SendBugReport", which is the same function you're calling. So again, unless some occult stuff is going on, both SendBugReport and "Send Mail" will end up in the very same function called "madExcept.SendBugReportEx()" which does all the work.
I would love to do the debuggin on my PC, but I simply cannot reproduce the problem here. Maybe you can set a breakpoint in madExcept.SendBugReportEx() to check why it uses mailto instead of mapi? Doesn't make any sense to me.
Re: SendBugReport in 4.0.13
P.S: One thing we could still try is this: Look at the "RCData\TMADEXCEPT" resource of your compiled EXE files. It contains the full madExcept settings. Look for "MailViaMapi = True". Is it set to True or False? You can check this with the freeware "Resource Hacker" or "PEBrowse Pro". If it's set to "False" that would explain why mapi isn't working. But then it shouldn't be working if the user presses the "send mail" button, either...
Re: SendBugReport in 4.0.13
Set to True, will recompile with Mad Source next.madshi wrote:P.S: One thing we could still try is this: Look at the "RCData\TMADEXCEPT" resource of your compiled EXE files. It contains the full madExcept settings. Look for "MailViaMapi = True". Is it set to True or False?
Re: SendBugReport in 4.0.13
Never count that outmadshi wrote: So again, unless some occult stuff is going on..
Anyhow line 10572 SendMapiMailEx returns 'NO'
rcptTo, subject, body look fine
das1 and das2 exist
parentWindow = 0
hidden = false
Will trace into SendMapiMailEx next..
Re: SendBugReport in 4.0.13
The MAPISendMail call fails.FredS wrote:Will trace into SendMapiMailEx next..madshi wrote: So again, unless some occult stuff is going on..
from: https://msdn.microsoft.com/en-us/librar ... s.85).aspx
[MAPISendMail is available for use in the operating systems specified in the Requirements section. It may be altered or unavailable in subsequent versions. Instead, use MAPISendMailW. ]
Sends an ANSI message.
On Windows 8 and later: Call MAPISendMailW to send a message.
On Windows 7 and earlier: Use MAPISendMailHelper to send a message.
Re: SendBugReport in 4.0.13
MAPISendMail failing would make sense - if it *always* did that. But why does it sometimes seem to work? It always seems to work fine on my Windows 8.1 x64 PC. Could it have to do with elevation again? Maybe your mail client doesn't like to be called via Mapi in elevated (or non-elevated) state, or something?
I think the biggest problem right now is that it sometimes seems to work and sometimes seems to fail. Unless you can find out under which circumstances it fails and works this might be a hard nut to crack. I doubt using MAPISendMailW would change that works/fails pattern.
I think the biggest problem right now is that it sometimes seems to work and sometimes seems to fail. Unless you can find out under which circumstances it fails and works this might be a hard nut to crack. I doubt using MAPISendMailW would change that works/fails pattern.
Re: SendBugReport in 4.0.13
Will switch to Windows Mail and reboot, that's easy enough to rule out.madshi wrote:Maybe your mail client doesn't like to be called via Mapi in elevated (or non-elevated) state, or something?
Re: SendBugReport in 4.0.13
Looks like Windows Mail doesn't support MAPI and simply opens Thunderbird.FredS wrote: Will switch to Windows Mail and reboot, that's easy enough to rule out.
But for a quick test all works until I use another Desktop, something finally added in Windows 10.
Now MAPI fails.
So with my MAPI client open on Desktop 1 and my app calling MAPISendMail from Desktop 2 I get this failure.
If there is no running MAPI client then the client is opened into the active Desktop and all works.
Will test if MAPISendMailW solves this issue.
Re: SendBugReport in 4.0.13
Ok, that sounds like a good explanation: Different desktops making problems. I don't think MAPISendMailW will make a difference, but it may be worth a try.