Solving Application Problems with Structured Error Handling

I've seen the announcement for the WebEx in a couple of weeks about structured error handling.

http://communities.progress.com/pcom/docs/DOC-16378#cf

This reminds me of the following topic: Using structured error handling it is still not fully possible (turning it into impossible for generic functions) to implement a custom error message dialog in a CATCH block. Anybody aware of the .NET error message dialog? I shows the error message and allows the user to "enlarge" the dialog and display additional detail (like stack information). The dialog has a number of buttons as options for the (already disturbed) user:

Quit

Ignore

Help

I'd love to be able to implement this in the ABL as well! I'd like to display the stack trace, have some options (the above + RE-Throw) depending on the type of user etc.

Due to the limitation of not being able to have WAIT-FOR statements in non VOID methods it is not predictable if you can run the required WAIT-FOR oForm:ShowDialog() . And even worse there is absolutely no way to detect if you are able to run the WAIT-FOR statement; the call stack won't tell you and you can't handle the situation (like first try WAIT-FOR oForm:ShowDialog and when it fails use the MESSAGE as an alternative).

So finally in commonly used methods (framework routines) you end up showing the message using a boring MESSAGE statement, disallowing the display of structured message details!

I ended up implementing the custom message dialog in a .NET assembly and having a custom C# routine that runs the ShowDialog method with has been implemented in C# code. I'd prefer to be able to implement this without writing custom C# code.

Sarah, is that something you could come up with an alternative solution during the WebEx?