TopMost and Save Bug Report Issues

delphi package - automated exception handling
Post Reply
Markham
Posts: 26
Joined: Wed Nov 02, 2005 11:46 am

TopMost and Save Bug Report Issues

Post by Markham »

I have two problems with this otherwise excellent series of classes. The first has to do with window TopMost and Z-Order.

I have a program that can be run as a child process of a much larger application but the author of that application does not want my program to have its own TaskBar button. Therefore, all my program's windows must have the FormStyle fsTopMost set so that they do not become hidden. That's fine until madExcept handles an exception and pops-up its dialog box. If the user then selects an option that closes the exception box ("close", "restart" or "continue"), then no problem. But if the user clicks on "Send bug report", madExcept's dialog loses focus and goes behind my program's window. I suspect this might be cleared by handling the WM_ACTIVATE message with a SetWindowPos call.

That situation is worsened if the Send Bug Report fails because the small message box that is supposed to tell the user of the failure is not displayed on top - but rather behind my window.

Secondly, it would be really nice if madExcept saves a bug report - through its inability to send it or if the user selects "Save", for it to be saved with the same settings that are used to send the report. I need my bug reports to be zipped-up with a screenshot and a copy of the program's logfile. Unfortunately it seems that only the bug report is saved (in text format). I would much prefer that the zipfile be created and saved so that the user can send it at a later time (eg: when he next connects to his mail service).


Mark.
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

The on top stuff is really difficult. Usually madExcept's exception box is on top, but sometimes the on top state makes problems (e.g. when using MAPI or mailto mailing or when the end user wants to edit the screenshot). So in some specific situations I'm removing the on top state. I'm not sure how to fully solve this problem.

Your "save" wish was already posted by 2 or 3 other people, so it's one of the things I'll work on next.
Markham
Posts: 26
Joined: Wed Nov 02, 2005 11:46 am

Post by Markham »

The on top stuff is really difficult. Usually madExcept's exception box is on top, but sometimes the on top state makes problems (e.g. when using MAPI or mailto mailing or when the end user wants to edit the screenshot). So in some specific situations I'm removing the on top state. I'm not sure how to fully solve this problem.
I know that OnTop causes problems, unfortunately I'm stuck with having to set this for my program's forms. How about an option which will instruct the exception box to detect if its window is no longer on top or visible (I think WM_ACTIVATE will do that) and simply attempts to reposition it (left, right, up or down) so that the exception box becomes visible.
Your "save" wish was already posted by 2 or 3 other people, so it's one of the things I'll work on next.
Many thanks! I look forward to that!

Incidentally, the sources are missing a unit called by MailTest (madScreenShot).

Mark
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

Markham wrote:I know that OnTop causes problems, unfortunately I'm stuck with having to set this for my program's forms. How about an option which will instruct the exception box to detect if its window is no longer on top or visible (I think WM_ACTIVATE will do that) and simply attempts to reposition it (left, right, up or down) so that the exception box becomes visible.
That would add footprint to madExcept for all my users. How about this: You can use "FindWindow('madExceptWndClass', nil)" to get the handle of the exception box. Then you can do to it whatever you need.
Incidentally, the sources are missing a unit called by MailTest (madScreenShot).
Thanks, I've changed MailTest to use the new madNVBitmap unit instead now.
Markham
Posts: 26
Joined: Wed Nov 02, 2005 11:46 am

Post by Markham »

madshi wrote:That would add footprint to madExcept for all my users.
Fair enough.
How about this: You can use "FindWindow('madExceptWndClass', nil)" to get the handle of the exception box. Then you can do to it whatever you need.
I can certainly do this - but I'm a bit unclear about how a procedure would be called - can you be a bit more specific, please.

Thanks!

Mark
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

Markham wrote:I can certainly do this - but I'm a bit unclear about how a procedure would be called - can you be a bit more specific, please.
Not sure what you mean.

You can e.g. use SetWindowLong(GWL_WNDPROC) to subclass the exception box. That way you can catch messages like WM_ACTIVATE etc. Basically subclassing the window should give you the power to do exactly what you asked me for, I think. The only problem I see is at what point in time you should subclass the window. I mean you'd need to be notified about that the exception window was created somehow. But I think you can use RegisterExceptActionHandler for that. The exception box is created with on top state, so in that moment everything should be fine for you. When the first button is pressed, RegisterExceptActionHandler is called, in that moment you could subclass the box to add further processing which makes sure that in your special situation the exception box will always be visible somehow...
Markham
Posts: 26
Joined: Wed Nov 02, 2005 11:46 am

Post by Markham »

Mathias,
You can e.g. use SetWindowLong(GWL_WNDPROC) to subclass the exception box. That way you can catch messages like WM_ACTIVATE etc.
Actually all I need is an indication that the exception box is visible. When it first becomes visible, there's no problem because it sits on top of the application (it is only when an action button - such as "send" - is pressed that the exception box loses focus and that happens, I think, because you're showing a progress box).

I've got around the problem by using RegisterExceptionActionHandler, as you suggest, to point to a short routine that simply gets the window position of my window and then moves the exception box accordingly. Fortunately my window is a fixed size - and can not be maximised - otherwise this strategy wouldn't work. But the disadvantage is that the except box is only moved after the first action rather than when it is first shown.
The only problem I see is at what point in time you should subclass the window. I mean you'd need to be notified about that the exception window was created somehow.
That would be ideal. I wonder whether adding another phase to TExceptPhase would help here, eg: epExceptBoxMadeVisible. Then I could use RegisterExceptionHandler to point to a routine that "listens" for that phase and immediately moves the exception box.

Mark
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

The latest beta build contains this:

Code: Select all

var OnExceptBoxCreate : procedure (exceptBox    : dword;
                                   simpleMsgBox : boolean) = nil;
You can register a callback there to be notified when the form got created (directly before it's shown).
Markham
Posts: 26
Joined: Wed Nov 02, 2005 11:46 am

Post by Markham »

Many thanks, Mathias. Is the new beta available now?

Mark
madshi
Site Admin
Posts: 10753
Joined: Sun Mar 21, 2004 5:25 pm

Post by madshi »

Oh sorry, forgot the link. The latest beta is *always* available here:

http://madshi.net/madCollectionBeta.exe
Post Reply