当前位置：文江博客话题详情

带有“验证”和“取消”按钮的消息框

发布于 2024-11-17 19:43:08 字数 31 浏览 7 评论 0原文

如何拥有一个带有两个按钮（验证和取消）的消息框？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

牛↙奶布丁 2024-11-24 19:43:08

不幸的是，标准 Win32 MessageBox 函数确实不支持带有自定义标签的按钮。由于 VB.NET MsgBox 函数是该本机函数的薄包装器，因此它也不支持它们。您获得的只是预定义的值，这意味着您最多可以做的就是“确定”和“取消”之类的操作，并有文本解释“确定”意味着“继续验证”。

值得注意的是，多年来，这是 Windows 样式指南认可的推荐做法。事实上，它看起来仍然是它仍然是。具体来说，请注意以下一般规则的例外情况：

使用作为对主要指令的特定响应的肯定提交按钮，而不是诸如“确定”或“是/否”之类的通用标签。用户应该能够通过单独阅读按钮文本来理解选项。
例外：
对没有设置的对话框（例如信息对话框）使用“关闭”。切勿对具有设置的对话框使用“关闭”。
当“特定”响应仍然是通用的时，请使用“确定”，例如“保存”、“选择”或“选择”。
更改特定设置或一组设置时使用“确定”。
对于没有主要说明的旧版对话框，您可以使用“确定”等通用标签。此类对话框通常不是为执行特定任务而设计的，因此无法做出更具体的响应。
某些任务需要用户进行更多思考和仔细阅读才能做出明智的决定。这通常是确认的情况。 在这种情况下，您可以有目的地使用通用提交按钮标签来强制用户阅读主要说明并防止仓促做出决定。

Windows Vista 引入了一个新的 API，旨在取代老化且无法配置的 MessageBox，它称为 TaskDialog。如果您运行的是 Windows Vista 或 7，您无疑已经在整个 Windows shell 中看到过此对话框。事实上，它确实允许您为每个按钮指定自定义名称，并提供一系列其他自定义选项。但这种控制并不是免费的。 TaskDialog 函数有两个问题：

.NET Framework 不包含开箱即用的包装器。您需要编写自己的简单包装器，或者下载 Windows API 代码包，其中包括这样的包装纸。但这给您的代码增加了额外的依赖性，您必须决定这是否值得。
由于该API仅在Vista中引入，这意味着程序只能在Vista或更高版本上运行时才能使用它。如果您仍然需要以 Windows XP（或 2000）为目标，那么您就不走运了。显示 TaskDialog 的代码将失败，您需要包含一个后备例程来显示标准 MessageBox。当然，这会让您回到开始的地方，而无法在这些旧操作系统上自定义按钮标签。同样，只有您可以决定这是否是您的应用程序和/或部署方案的一个重要问题。

一代又一代 VB 程序员使用的另一个选项是创建您自己的 MessageBox 风格的小表单。布置一个简单的表单并放置一个图标/图像、一些标题文本和所有您想要的按钮并不难。由于您已经创建了整个表单，因此您可以根据自己的意愿自由地从代码中对其进行自定义。

如果您在 Vista 之前的 Windows 版本中绝对需要此功能，那么创建您自己的消息框表单是您唯一的选择。否则，我强烈建议您利用新的TaskDialog API。在应用程序中这样做可以提高与用户可能已安装在其计算机上的其他应用程序的一致性，甚至与 Windows 本身的一致性。很难确保您自己的自定义消息框表单得到正确的小细节，例如根据标签文本的长度和用户的屏幕尺寸自动换行。并在标题栏中显示/隐藏“X”关闭按钮，具体取决于您的对话框是否包含“取消”按钮。标准 Windows MessageBox/TaskDialog 还可以免费为您完成大量其他事情，而您无需费力。这只是对一般原则的重申：当你没有绝对必要时，永远不要重新发明轮子。

一个好的折衷方案可能是使用类似 this TaskDialog 包装器/模拟器。在 Vista 及更高版本中，本地 TaskDialog API 可用，它会自动调用该函数。否则，它使用标准形式并尝试模拟本机 TaskDialog API 的行为。我已经编写了一个类似的自定义类供自己使用，但我从未抽出时间将其发布到网上。

Unfortunately, the standard Win32 MessageBox function does not support buttons with custom labels. And since the VB.NET MsgBox function is a thin wrapper over that native function, it doesn't support them either. The pre-defined values are all you get, meaning that the best you can do is something like "OK" and "Cancel", with text explaining that "OK" means to "proceed with validation".

It's worth noting that for years, this was the recommended practice endorsed by the Windows style guides. In fact, it looks like it still is. Specifically, note the exceptions to the following general rule:

Use positive commit buttons that are specific responses to the main instruction, instead of generic labels such as OK or Yes/No. Users should be able to understand the options by reading the button text alone.
Exceptions:
Use Close for dialogs that don't have settings, such as informational dialogs. Never use Close for dialogs that have settings.
Use OK when the "specific" responses are still generic, such as Save, Select, or Choose.
Use OK when changing a specific setting or a collection of settings.
For legacy dialog boxes without a main instruction, you can use generic labels such as OK. Often such dialog boxes aren't designed to perform a specific task, preventing more specific responses.
Certain tasks require more thought and careful reading for users to make informed decisions. This is usually the case with confirmations. In such cases, you can purposely use generic commit button labels to force users to read the main instructions and prevent hasty decisions.

Windows Vista introduced a new API intended to replace the aging and impossible-to-configure MessageBox—it's called the TaskDialog. If you're running either Windows Vista or 7, you've undoubtedly seen this dialog used throughout the Windows shell. It does, in fact, allow you to specify custom names for each of the buttons, and provides an array of other customization options as well. But this kind of control doesn't come for free. There are two problems with the TaskDialog function:

The .NET Framework does not include a wrapper for it out of the box. You'll need to either write your own simple wrapper, or download the Windows API Code Pack that includes such a wrapper. But this adds an extra dependency to your code—you'll have to decide whether that's worth it or not.
Because the API was only introduced in Vista, that means programs can only use it when running on Vista or later. If you still need to target Windows XP (or 2000), you're out of luck. The code to show a TaskDialog will fail, and you'll need to include a fallback routine to show a standard MessageBox. Which of course puts you right back where you started, without the ability to customize the button labels, on those legacy operating systems. Again, only you can decide if this is a significant concern for your application and/or deployment scenario.

The other option, used by generations of VB programmers, is to bang up your own little MessageBox-style form. It's not that hard to lay out a simple form with a place for an icon/image, some caption text, and all the buttons you want. Since you've created the entire form, you'll be free to customize it from your code however you wish.

If you absolutely need this functionality in versions of Windows prior to Vista, then creating your own message box form is about your only option. Otherwise, I highly recommend that you take advantage of the new TaskDialog API. Doing so within your application promotes consistency with other applications the user is likely to have installed on their computer, and even with Windows itself. It's difficult to ensure that your own custom message box form gets the little touches right, like automatically wrapping the label text depending on its length and the user's screen size. And showing/hiding the "X" close button in the title bar depending on whether your dialog includes a "Cancel" button. And an unbelievable number of other things that the standard Windows MessageBox/TaskDialog does for you for free without your having to lift a finger. This is just a restatement of the general principle: never re-invent the wheel when you don't absolutely have to do so.

A good compromise might be to use something like this TaskDialog wrapper/emulator. On Vista and later, where the native TaskDialog API is available, it automatically calls that function. Otherwise, it uses a standard form and attempts to simulate the behavior of the native TaskDialog API. I've written a similar custom class for my own use, but I never got around to publishing it online.

回复收藏 0 原文

~没有更多了~