MadExcept not blocking message queue when displaying message

delphi package - automated exception handling

MadExcept not blocking message queue when displaying message

Postby duncan » Thu Aug 02, 2018 6:35 am

We have what appears to be a significant issue with mad except exception handling, timing, and the processing of the windows message queue.

In our application, if a control/component throws an exception (DevExpress throwing a EcxEditValidationError for example) the exception gets trapped by vcl code and passed to Application.HandleException (refer TWinControl.MainWndProc).
It appears that MadExcept then jumps in and passes control over to a seperate thread which then displays a message box.

It seems that there is a fatal flaw (at least of our application) in that between control being passed to the madexcept thread and the message box being displayed by the madexcept thread the windows message loop is processed on the main thread. This means that user input is accepted between the exception being thrown and the message being displayed. This causes all sorts of grief (eg message box appearing behind a modal dialog).

The question we have is: can the message loop not be processed (or at least user input etc accepted) in this scenario and/or can the message box be displayed by the main window thread?
duncan
 
Posts: 2
Joined: Thu Aug 02, 2018 5:14 am

Re: MadExcept not blocking message queue when displaying mes

Postby madshi » Thu Aug 09, 2018 1:45 pm

If the exception box were to be displayed by the main thread, the message loop would still run, so I'm not sure how that would help?

You can set "madExcept.HandleMessagesInMainThread := false" in your initialization somewhere. Of course this will result in your GUI seemingly being non-responsive.
madshi
Site Admin
 
Posts: 9774
Joined: Sun Mar 21, 2004 5:25 pm

Re: MadExcept not blocking message queue when displaying mes

Postby duncan » Mon Aug 20, 2018 11:44 pm

Thanks, we will look at this.

This should help because it will prevent the main message loop processing before the dialog being displayed. The problem is the message processing occurring in the main thread between the exception processing being passed over to the background thread and the dialog being displayed. This 'gap' means the use is able to take additional actions in the application (potentially causing the issue to repeat, or triggering a modal message box) before the dialog is displayed to explain there has been an issue. If a modal message box has been displayed this can result in a windowing deadlock (madexcept dialog is not enabled but it is display over the modal dialog displayed due to user action between issue and exception dialog being displayed).
A pause in UI responsiveness is better than the use being able to do additional 'bad' things.
duncan
 
Posts: 2
Joined: Thu Aug 02, 2018 5:14 am


Return to madExcept

Who is online

Users browsing this forum: No registered users and 3 guests