We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


Changing the MsgBox Buttons Captions

dougr asked
Medium Priority
Last Modified: 2010-04-30
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?

Watch Question

Hi, if you want to use the msgbox here is my answer :

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 If
End Su

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:

    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).


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.



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.

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.


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.


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.


To: blwatkins (Brad)

Thanks I look forward to hearing from you!


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.


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....

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.


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.


Unlock this solution with a free trial preview.
(No credit card required)
Get Preview


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.

Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.