Can I use a Custom Dialog ?

[luciano_f]

Hello, I would like to know if it is possible for me to create my own Custom Error Form instead of the MadExcept Standard ?

  In that form I would put a "Problem Details" button when the user clicked on that button would open MadExcept on the "CallStack"

  If this is possible do you have any examples of how I could do this?

[madshi]

Yes, you can do that. However, there's a catch: The VCL is not thread safe, so if you build your custom dialog with the VCL, you need to be careful that you don't show it in a secondary thread. madExcept's own crash box is built using pure win32 APIs to make it thread safe.

Here's a little code example for replacing the dialog with a VCL window:

Code: Select all

uses ..., madExcept;

procedure YourOwnDialogCallback(const exceptIntf: IMEException; var handled: boolean);
begin
  YourOwnVclDialog.ShowModal;
  handled := true;
end;

initialization
  RegisterExceptionHandler(YourOwnDialogCallback, stTrySyncCallOnSuccess, epMainPhase);
end.

The key here is the "stTrySyncCallOnSuccess" flag. It tells madExcept that you would like your callback to be called within the context of the main thread. If madExcept succeeds on doing that, your callback will be called on your can show your own dialog. If madExcept is not able to call your callback in the context of the main thread (e.g. because the main thread is frozen), your callback will not be called and the default madExcept crash box will show instead.

[luciano_f]

I created a test project where
I noticed some details :::

 1st by clicking the "Error AccessViolation 1" button it triggers directly to MadExcept Dialog and does not show my Custom Dialog.

 2nd when clicking the "Error AccessViolation 2" button and closed the application instead of showing me the error.

3rd When to open MadExcept how to focus the Call Stack Page.

The Txt file that is saved as I can hide from this file information such as "computer name", "registered owner", "operating system", "system language"

Attached my test project ...

[madshi]

The "Error AccessViolation 1" shows your custom dialog on my PC.

The "Error AccessViolation 2" on my PC hides the main form of the application. It seems that the undefined "EButton" by random/chance gets the value of the main form somehow. At least that's the case on my PC.

Focusing the call stack page is currently not easily possible. I suppose you could call "madExcept.GetExceptBoxHandle()" to get the window handle of the madExcept exception box, then use FindWindowEx() to find the page control and send a win32 message to it to switch to the callstack tab. Should be possible somehow, but will require a bit of trial and error with the win32 APIs.

I'm not sure "The Txt file [...] as I can hide" means.

[luciano_f]

I did not want to save some information in the file "bugreport.txt"
because several information is currently saved that I consider unnecessary as
  "computer name", "registered owner", "operating system", "system language"

  Attached a Video for you to see what happens when I click on
  "Error AccessViolation 1"
https://mega.nz/#!RqpjQDha!PsCgebXCuA7TqdubornKHiGwLraVdB8d6uRYLZF2e3E

  My Delphi 2010 win32 windows 8.1 64 Bits.

[madshi]

See the bottom of this page for how to remove information from the bug report header:

http://help.madshi.net/HowToUseMadExcept.htm

I don't know why your Delphi 2010 behaves the way it is. I can't reproduce the problem on my PC, unfortunately. It's hard for me to fix things if I can't reproduce them. There's probably a good reason for why it behaves the way it behaves, but I can't guess what it is. Of course if you had the commercial madExcept edition, you could set breakpoints in madExcept.pas and debug it to see why calling your handler in the context of the main thread seems to fail.

[luciano_f]

Attached is the project and the executable.

I have a lot of interest in buying MadExcept
however first I would like to resolve this question of why does not show my Custom Dialog.

Test the executable in the attachment.
https://mega.nz/#!lz4AlCTR!LmX8TeXs8C8YigFc0KW7dvZ0pJ7PJLMB4xajrmD2RkM

Error in Button "Error AccessViolation 1"

If you have Delphi 2010 32Bits possibly the error will appear there for you

[madshi]

Sorry for the late reply.

Ok, I was able to reproduce the issue using Delphi 2010. And here's what happens:

Your "Error Access Violation 1" button does so much damage that the whole process gets unstable. Still, madExcept is able to actually call your "YourOwnDialogCallback" callback in the context of your main thread, but in the moment when you call "MessageDlg" in your callback, another crash occurs. madExcept is clever enough to "ignore" crashes that occur within your exception callback routines. So it seems like madExcept would have completely ignored your handler. But actually, the real problem is that your process has gone very unstable.

To be honest, I'm not fully sure what's so bad about your "Error Access Violation 1" button which makes your process so unstable. But it's clearly not madExcept's fault.

FWIW, I usually test access violations by doing "integer(nil)^ := 0". This is a very simple access violation which doesn't do any more damage than raising an AV.

[luciano_f]

the problem is that after giving the serious error of "Error Access Violation 1" if you click on another button with a simpler error, MadExcept can no longer show my Custom Dialog, that is, once the Serious Error has been triggered "Error Access Violation 1 "MadExcept no longer recovers.

[madshi]

There seems to be a misunderstanding. It is *not* madExcept which is showing your custom dialog. madExcept just calls your exception handler. And your exception handler then calls "MessageDlg". And the call to "MessageDlg" crashes internally. Which is *NOT* madExcept's fault. There's nothing for madExcept to recover from. It works perfectly. It's your MessageDlg call which fails/crashes, not madExcept. Try debugging your test project in the IDE debugger. Set a breakpoint on your "MessageDlg" call. Then press the buttons. Even after your clicked on "Error Access Violation 1" and afterwards on other buttons, every time the breakpoint should be reached. But every time when you continue program execution, you'll get a crash inside of MessageDlg.

madExcept is only there to report crashes. It's not madExcept's job to magically fix a crash inside of MessageDlg which occurs because an earlier Access Violation put the process into an unstable state.