dougr
asked on
Changing the MsgBox Buttons Captions
To detect errors in one of my programs I use an "On Error goto ErrTrap" statement in each Sub Procedure (of which there are about 500). Then I have an ErrTrap in each Sub Procedure which uses a MsgBox to direct the action to be taken.
Typically I want the user to select one of 3 options:
1 - "Continue" (Ignore the error and continue execution)
2 - "Main Menu" (close all windows and return to Main Menu)
3 - "End Program" (Stop execution of the program)
Unfortunately the standard MsgBox has certain preset MsgBox constants such as vbAbortRetryIgnore, or vbYesNoCancel which don't fit my 3 options. Is there any way to customize the Messages on the Buttons of a MsgBox to better fit my 3 options?
One possible solution is to create my own code to SIMULATE a MsgBox. I tried this by creating a form "frmErrMsg" with Message labels and 3 Command Buttons so that it looks like and behaves like a MsgBox. I works fine when I call it up from an ErrTrap. I load it modally to force the user to respond with a Button Click to deal with the error before it allows the program to resume.
However it bombs out when MULTIPLE errors occur before the original error is cleared. VB5 won't allow a form to be loaded modally more than once, if it is already loaded.
So I am forced to go back to the MsgBox once again with its inadequate buttons captions.
Any solutions to this problem?
dougr
Typically I want the user to select one of 3 options:
1 - "Continue" (Ignore the error and continue execution)
2 - "Main Menu" (close all windows and return to Main Menu)
3 - "End Program" (Stop execution of the program)
Unfortunately the standard MsgBox has certain preset MsgBox constants such as vbAbortRetryIgnore, or vbYesNoCancel which don't fit my 3 options. Is there any way to customize the Messages on the Buttons of a MsgBox to better fit my 3 options?
One possible solution is to create my own code to SIMULATE a MsgBox. I tried this by creating a form "frmErrMsg" with Message labels and 3 Command Buttons so that it looks like and behaves like a MsgBox. I works fine when I call it up from an ErrTrap. I load it modally to force the user to respond with a Button Click to deal with the error before it allows the program to resume.
However it bombs out when MULTIPLE errors occur before the original error is cleared. VB5 won't allow a form to be loaded modally more than once, if it is already loaded.
So I am forced to go back to the MsgBox once again with its inadequate buttons captions.
Any solutions to this problem?
dougr
Change the way you do things!
Handle errors in two different ways:
1. Errors at the "top level" - command clicks etc (Events)
Have your usual message box here
2. Errors in lower-level subs/functions
simply re-raise the error:
ErrTrap:
Err.Raise Err.number, Err.Source, Err.Description
This will cause the error to be raised in the calling routine (and so on until it reaches the top when you'll display the message box)
another tip is to append something the Err.Source everytime so that you get a call stack:
Err.Raise Err.Number, Err,Source & ":subroutinename", Err.Description
you can the either display this call stack or write it away somewhere (it will help if debug if you know have the code got to the failing routine).
Handle errors in two different ways:
1. Errors at the "top level" - command clicks etc (Events)
Have your usual message box here
2. Errors in lower-level subs/functions
simply re-raise the error:
ErrTrap:
Err.Raise Err.number, Err.Source, Err.Description
This will cause the error to be raised in the calling routine (and so on until it reaches the top when you'll display the message box)
another tip is to append something the Err.Source everytime so that you get a call stack:
Err.Raise Err.Number, Err,Source & ":subroutinename", Err.Description
you can the either display this call stack or write it away somewhere (it will help if debug if you know have the code got to the failing routine).
ASKER
To: a111a111a111 (Shay)
Thanks for your answer - sorry to reject it, but what you have submitted is exactly what I have done. It works, but my main objection is that I am stuck with the Captions "Yes", "No", and "Cancel" in the 3 MsgBox Command buttons.
I would like to be able to change those captions to read something like "Continue", "Menu", and "Exit". This would more closely reflect the actual function of these buttons.
The answer may be that VB5 cannot do this. I always have the naive hope that anything is possible and that someone has already travelled down this road before me.
Dougr
Thanks for your answer - sorry to reject it, but what you have submitted is exactly what I have done. It works, but my main objection is that I am stuck with the Captions "Yes", "No", and "Cancel" in the 3 MsgBox Command buttons.
I would like to be able to change those captions to read something like "Continue", "Menu", and "Exit". This would more closely reflect the actual function of these buttons.
The answer may be that VB5 cannot do this. I always have the naive hope that anything is possible and that someone has already travelled down this road before me.
Dougr
ASKER
TO: kdimmock
Your comment sounds very interesting, but unfortunately I am a relative novice and am not familiar with the concept of "raising" errors and "stacks". I guess I need to do more homework and reading to get a better understanding of these concepts.
My main concern is that my error handling routine be able to detect and display multiple errors in a systematic fashion so that the user can respond to them and take corrective action to either recover from the errors or end the program in a controlled manner.
Dougr
Your comment sounds very interesting, but unfortunately I am a relative novice and am not familiar with the concept of "raising" errors and "stacks". I guess I need to do more homework and reading to get a better understanding of these concepts.
My main concern is that my error handling routine be able to detect and display multiple errors in a systematic fashion so that the user can respond to them and take corrective action to either recover from the errors or end the program in a controlled manner.
Dougr
Hi again.
You can do:
1. Make a form that will look like a msgbox with your buttons and label and so.
I can make one for you if you like so.
2. I made an OCX that have the buttons and a label message but no frame.
I can Email it to you and I can show you how to make your own one.
3. I think that if you search the net you may find some OCX that do what you need.
if you need to contact me email to: shayplace@hotmail.com.
if this is an answer for you let me know and I'll post it again as an answer.
I hope it helps.
You can do:
1. Make a form that will look like a msgbox with your buttons and label and so.
I can make one for you if you like so.
2. I made an OCX that have the buttons and a label message but no frame.
I can Email it to you and I can show you how to make your own one.
3. I think that if you search the net you may find some OCX that do what you need.
if you need to contact me email to: shayplace@hotmail.com.
if this is an answer for you let me know and I'll post it again as an answer.
I hope it helps.
ASKER
To: a111a111a111 (Shay)
Thanks for the comment. What you are proposing sounds like what I have already tried. If you read the third and fourth paragraphs of my ORIGINAL question you will see that I have ALREADY designed a FORM that LOOKS like a MsgBox, with message labels and 3 Command Buttons so that it looks like and behaves like a MsgBox.
It works PERFECTLY on a SINGLE, simple error. I always call it up as MODAL because I do not want the user to exit from the error handling routine until the error has been properly dealt with. It is this that causes the problem. When the program has to deal with MULTIPLE errors at the same time (i.e. a second error occurs before the first is cleared by the error handling routine) it won't allow my "home made" MsgBox form to be displayed MODALLY when it is already displayed on the screen for the first error.
Unless I am misreading your comment, I do not believe it addresses this problem of trapping multiple errors. If a true MsgBox is used, this problem is succesfully dealt with as the multiple MsgBoxes simply pile up one on top of the other and they can be systematically cleared, one at time. Which, unfortunately brings us full circle to my original question about the inadequate button captions on MsgBoxes!
It is very late at night as I write this, so I hope it is making some sense! As I read the entire list of comments, I wonder if we are going around in circles!
Thanks again.
dougr
Thanks for the comment. What you are proposing sounds like what I have already tried. If you read the third and fourth paragraphs of my ORIGINAL question you will see that I have ALREADY designed a FORM that LOOKS like a MsgBox, with message labels and 3 Command Buttons so that it looks like and behaves like a MsgBox.
It works PERFECTLY on a SINGLE, simple error. I always call it up as MODAL because I do not want the user to exit from the error handling routine until the error has been properly dealt with. It is this that causes the problem. When the program has to deal with MULTIPLE errors at the same time (i.e. a second error occurs before the first is cleared by the error handling routine) it won't allow my "home made" MsgBox form to be displayed MODALLY when it is already displayed on the screen for the first error.
Unless I am misreading your comment, I do not believe it addresses this problem of trapping multiple errors. If a true MsgBox is used, this problem is succesfully dealt with as the multiple MsgBoxes simply pile up one on top of the other and they can be systematically cleared, one at time. Which, unfortunately brings us full circle to my original question about the inadequate button captions on MsgBoxes!
It is very late at night as I write this, so I hope it is making some sense! As I read the entire list of comments, I wonder if we are going around in circles!
Thanks again.
dougr
Hi, Here are some links about error trapping:
http://members.aol.com/asmincorp/errormaster.htm
http://www.gridlinx.com/errorfrm.htm
http://www.ozemail.com.au/~g3tech/snvb5rsn.htm
http://www.caslics.com/vberror.htm
I hope it will be helpful.
http://members.aol.com/asmincorp/errormaster.htm
http://www.gridlinx.com/errorfrm.htm
http://www.ozemail.com.au/~g3tech/snvb5rsn.htm
http://www.caslics.com/vberror.htm
I hope it will be helpful.
dougr,
There is a way to change the buttons on a standard msgbox function. I read it somewhere but, unfortunatly I can't remember where. But it is possible. I will try to find it and get back to you on it.
thanks Brad.
There is a way to change the buttons on a standard msgbox function. I read it somewhere but, unfortunatly I can't remember where. But it is possible. I will try to find it and get back to you on it.
thanks Brad.
ASKER
To: blwatkins (Brad)
Thanks I look forward to hearing from you!
Doug
Thanks I look forward to hearing from you!
Doug
Doug,
Just saw your problem. the only solution which seems practical to me would be that you donot show the modal form in the subroutines but show it at the top of the chain. Just pass the error back from one subroutine to the next until you reach the top level and display your modal form there. don't know if it is of much help since it is kind of similar to what kdimmock says at the top but i suggest you use your modal form at the top level instead of regular msgbox.
Manish77
Just saw your problem. the only solution which seems practical to me would be that you donot show the modal form in the subroutines but show it at the top of the chain. Just pass the error back from one subroutine to the next until you reach the top level and display your modal form there. don't know if it is of much help since it is kind of similar to what kdimmock says at the top but i suggest you use your modal form at the top level instead of regular msgbox.
Manish77
I might be going in circles too....
Could you use the 'custom form' as a MsgBox and make some code to store the errors in an array so that if multiple errors occur .. the msgbox displays them in order... from the one "form".......
just a suggestion....
Maverick
Could you use the 'custom form' as a MsgBox and make some code to store the errors in an array so that if multiple errors occur .. the msgbox displays them in order... from the one "form".......
just a suggestion....
Maverick
I don't understand how you could be getting multiple errors. If you're using on error goto, then it should go to the error handler on the first error. Then you display your homemade dialog, get input, and then continue processing. If you're showing it modally, how is the code continuing onward to try to display a second dialog? Are you cleaning up every error in ErrTrap? You could also store the error number before showing the dialog, then call err.clear after showing the dialog.
ASKER
To: Lycanthrope
I am not sure I can answer your question because I am way over my head on understanding this stuff. However here goes:
Suppose an error occurs in the Form_Activate event and its error handler kicks in. This triggers the loading of my MODAL Error Handling Form. However when my MODAL form is Loaded and Activated, the ORIGINAL form (where the error occurred) will be DeActivated. Suppose another error occurs in the code of the Form_Deactivate event of the ORIGINAL form. Then its error handler is triggered and tries to load a second copy of the MODAL error handler form before the first error has been cleared. VB does not allow 2 copies of the same MODAL for to be loaded simultaneously.
Does this make sense?
Another way to look at it is this:
If the process of transferring control to a MODAL error handler form triggers events in the ORIGINAL form (e.g. LostFocus, DeActivate, Unload events etc.) then these triggered events may generate a new error before the original error has been cleared and the MODAL form unloaded.
As I say I am somewhat over my head in this and may be way off base. I have noticed that VB does not always do things in the order that I would expect. For instance when deactivating or unloading one form and loading or activating new form sometimes the Activate, Deactivate, Load and Unload events OVERLAP between the two forms in unexpected ways.
dougr
I am not sure I can answer your question because I am way over my head on understanding this stuff. However here goes:
Suppose an error occurs in the Form_Activate event and its error handler kicks in. This triggers the loading of my MODAL Error Handling Form. However when my MODAL form is Loaded and Activated, the ORIGINAL form (where the error occurred) will be DeActivated. Suppose another error occurs in the code of the Form_Deactivate event of the ORIGINAL form. Then its error handler is triggered and tries to load a second copy of the MODAL error handler form before the first error has been cleared. VB does not allow 2 copies of the same MODAL for to be loaded simultaneously.
Does this make sense?
Another way to look at it is this:
If the process of transferring control to a MODAL error handler form triggers events in the ORIGINAL form (e.g. LostFocus, DeActivate, Unload events etc.) then these triggered events may generate a new error before the original error has been cleared and the MODAL form unloaded.
As I say I am somewhat over my head in this and may be way off base. I have noticed that VB does not always do things in the order that I would expect. For instance when deactivating or unloading one form and loading or activating new form sometimes the Activate, Deactivate, Load and Unload events OVERLAP between the two forms in unexpected ways.
dougr
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
To: sdbanks
Thanks for your suggestion, I like its simplicity. I havn't had a chance to try it yet, but it looks like it ought to work as it blocks out the additional errors that occur when loading the error trapping routine.
Thanks to all the experts that responded to this question. I have left the question open for long enough, so I will now close it and award the points.
dougr
Thanks for your suggestion, I like its simplicity. I havn't had a chance to try it yet, but it looks like it ought to work as it blocks out the additional errors that occur when loading the error trapping routine.
Thanks to all the experts that responded to this question. I have left the question open for long enough, so I will now close it and award the points.
dougr
Private Sub Form_Load()
Dim Response
Response = MsgBox("Press Yes to Continue, No to Go to Main Menu and Cancel To End Program.", 3, "Error ")
'Possible Response values: 6--YES, 7--NO, 2--CANCEL.
If Response = 6 Then
Resume Next
ElseIf Response = 7 Then
'Goto main menu
MsgBox "Goto main menu"
ElseIf Response = 2 Then
End
End If
End Su