TopMost and Save Bug Report Issues
TopMost and Save Bug Report Issues
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.
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.
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.
Your "save" wish was already posted by 2 or 3 other people, so it's one of the things I'll work on next.
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.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.
Many thanks! I look forward to that!Your "save" wish was already posted by 2 or 3 other people, so it's one of the things I'll work on next.
Incidentally, the sources are missing a unit called by MailTest (madScreenShot).
Mark
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.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.
Thanks, I've changed MailTest to use the new madNVBitmap unit instead now.Incidentally, the sources are missing a unit called by MailTest (madScreenShot).
Fair enough.madshi wrote:That would add footprint to madExcept for all my users.
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.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.
Thanks!
Mark
Not sure what you mean.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.
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...
Mathias,
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.
Mark
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).You can e.g. use SetWindowLong(GWL_WNDPROC) to subclass the exception box. That way you can catch messages like WM_ACTIVATE etc.
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.
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.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.
Mark
The latest beta build contains this:
You can register a callback there to be notified when the form got created (directly before it's shown).
Code: Select all
var OnExceptBoxCreate : procedure (exceptBox : dword;
simpleMsgBox : boolean) = nil;
Oh sorry, forgot the link. The latest beta is *always* available here:
http://madshi.net/madCollectionBeta.exe
http://madshi.net/madCollectionBeta.exe