Re: IMEException.MailBody
Posted: Thu Dec 08, 2016 12:19 pm
I've already changed my code so that the mailto/shellmail body is only replaced if your madExcept settings define attachments. So in the next build, if you remove all attachments, things will work as you expected.
You might not like attachments, but I think you're pretty much in the minority there. It's so much more convenient to double click a bug report file attachment in an email, and then have the madExcept Bug Report Viewer open up automatically (if you use the "mbr" file extension which is assigned to the viewer) than trying to read a bug report text in an email program, which probably doesn't even use mono-space fonts.
If my exception box were VCL, it could not be used in situations where the main thread is "frozen" (e.g. in an endless loop without message handling, or in a deadlock). In these situations madExcept would not be able to show any exception box at all, when using the VCL. That would be a catastrophe.
You're right that my exception box is not DPI aware, that's on my to-do-list to look at. The "too many buttons" problem can be easily fixed. Just hide the buttons you don't like. There's also a checkbox in the madExcept settings named "show standard buttons instead of fading owner draw buttons". You seem to prefer that.
If you think that madExcept is not high quality, why are you using it? You can use Jedi Debug or EurekaLog instead, if you think they are higher quality. But you should be aware of that EurekaLog also creates its own non-VCL window. Why? Because it's necessary for a good exception catching tool, because the VCL is not thread safe. But it seems a win32 standard "look" is more important to you than a reliable exception catching functionality.
You might not like attachments, but I think you're pretty much in the minority there. It's so much more convenient to double click a bug report file attachment in an email, and then have the madExcept Bug Report Viewer open up automatically (if you use the "mbr" file extension which is assigned to the viewer) than trying to read a bug report text in an email program, which probably doesn't even use mono-space fonts.
If my exception box were VCL, it could not be used in situations where the main thread is "frozen" (e.g. in an endless loop without message handling, or in a deadlock). In these situations madExcept would not be able to show any exception box at all, when using the VCL. That would be a catastrophe.
You're right that my exception box is not DPI aware, that's on my to-do-list to look at. The "too many buttons" problem can be easily fixed. Just hide the buttons you don't like. There's also a checkbox in the madExcept settings named "show standard buttons instead of fading owner draw buttons". You seem to prefer that.
If you think that madExcept is not high quality, why are you using it? You can use Jedi Debug or EurekaLog instead, if you think they are higher quality. But you should be aware of that EurekaLog also creates its own non-VCL window. Why? Because it's necessary for a good exception catching tool, because the VCL is not thread safe. But it seems a win32 standard "look" is more important to you than a reliable exception catching functionality.