Unfortunately, the standard Win32 MessageBox function does not support custom label buttons. And since the VB.NET MsgBox function is a thin shell over this native function, it also does not support them. Predefined values are all that you get, which means that the best you can do is something like “OK” and “Cancel” with text explaining that “OK” means “continue checking”.
It is worth noting that for many years it was a recommended practice, approved by the Windows style guide. In fact, it looks like it still is . In particular, note the exceptions to the following general rule:
Use positive commit buttons, which are specific answers to the main instruction, instead of common shortcuts like OK or Yes / No. Users should be able to understand the parameters by reading only the button text.
Exceptions:
- Use Close for dialogs that do not have settings, such as dialog boxes. Never use Close for settings dialogs.
- Use "OK" if the "specific" answers are still common , such as Save, Select, or Select.
- Use OK when changing a specific parameter or setting.
- For obsolete dialog boxes without basic instructions, you can use common shortcuts such as OK. Often, these dialog boxes are not designed to perform a specific task, preventing more specific answers.
- Certain tasks require more attention and careful reading for users to make informed decisions. This usually happens with confirmation. In such cases, you can intentionally use common commit button labels to get users to read basic instructions and prevent hasty decisions.
Windows Vista introduced a new API designed to replace aging and the inability to configure MessageBox - it is called TaskDialog . If you are using Windows Vista or 7, you have undoubtedly seen this dialog used throughout the Windows shell. In fact, it allows you to specify custom names for each of the buttons and also provides many other settings. But such control does not come for free. There are two problems with the TaskDialog function:
The .NET Framework does not include a wrapper for this out of the box. You will need to either write your own simple shell, or load the Windows API Code Code , which includes such a shell. But this adds an extra dependency to your code and you need to decide if it is worth it or not.
Since the API was introduced only in Vista, this means that programs can only use it when running in Vista or later. If you still need to target Windows XP (or 2000), you're out of luck. The code to show the TaskDialog will not be executed, and you will need to enable the backup procedure to display the standard MessageBox . Which, of course, will return you to where you started, without the ability to customize button shortcuts in these legacy operating systems. Again, only you can decide if this is a serious problem for your application and / or deployment scenario.
Another option used by generations of VB programmers is to hack your own small MessageBox form. It’s not so difficult to lay out a simple form with a place for the icon / image, the text of the signature and all the buttons you want. Since you created the whole form, you can customize it for free from your code.
If you absolutely need this functionality in versions of Windows prior to Vista, then creating your own message box form is your only option. Otherwise, I highly recommend that you use the new TaskDialog API. Doing this as part of your application promotes consistency with other applications that the user is likely to install on their computer and even Windows itself. It is difficult to make sure that your own form of the message box receives small touches, like automatically wrapping the text of a label depending on its length and size of the user's screen. And showing / hiding the close button "X" in the title bar, depending on whether your dialog box includes the "Cancel" button. And the incredible amount of other things that the standard Windows MessageBox / TaskDialog does for you for free, without having to lift your finger. This is just a repeat of the general principle: never reinvent the wheel when you do not need it.
A good compromise might be to use this TaskDialog shell / emulator . In Vista and later, where the native TaskDialog API is TaskDialog , it automatically calls this function. Otherwise, it uses the standard form and tries to simulate the behavior of the native TaskDialog API. I wrote a similar custom class for my own use, but I never intended to publish it on the Internet.