项目的迭代中加快C#的速度。 很多时候，我搜索的概念与我预期的答案不同，但它最终教会了我更多关于Windows API及其结构的一些原因。
我最近搜索了"C# 控件大小和消息框的位置"，结果之一是 2 年前的线程：
如何在 c# 中更改消息框的大小？
这也引用了一个较旧的线程。
好的，我得到的答案是"不可能，您应该为此创建自己的表单"，然后是一些示例和/或指导。
在这种特殊情况下，我不同意并且看不到类设计者的意图。
我搜索的另一个自然结果是 MessageBox 类的 Show（） 方法。 这让我回到了我发现 Show（） 方法有 19 个重载的类。 这些都与几何学无关;我觉得这可能很简单。
我的观点是各种 Show（） 方法的功能允许程序员选择图标、标题文本、内容文本以及按钮。 我看到它甚至与帮助导航器集成在一起。 对于小部件来说，这是一个令人难以置信的内置灵活性，但同时我无法控制该小部件的大小和位置？ 这实际上是 4 个数字：X、Y、x 深度、y 深度。
我完全理解我可以创建一个新表单，或者类（？）为我做这件事。 实际上，这带有简化问题。 确定。。。我可以创建一个完整的表单。 这意味着我必须管理它并处理它，并通过我自己的仪式为它提供方法。 如果我要使用 MessageBox 类作为基础创建一个类，该怎么办？ 我不得不说，我必须稍微徘徊一下，看看我是否可以制作一个新的 Show（） 方法，该方法具有 X/Y/x 深度/y 深度的重载。
恕我直言，这些整体功能是非常自然的事情。 弹出通知。 标题该框以显示错误或警告，添加了框中包含的说明文本。 能够在该框中显示"确定"和/或"取消"。 因此，我想知道为什么设计师选择限制功能并不允许弹出窗口的大小和位置？ 因为默认结果是盒子被放置在系统决定的任何位置，并且根据内容的不同，它是丑陋/小或大。
我最后想知道的是，主流观点是我应该制作自己的自定义表单，或者我是否真的成功地制作了一个继承 MessageBox 的类并制作了一个支持几何的自定义 Show（） 方法。
也许甚至不止于此：我弄错了吗？ 这门课是否已经更新以满足我的需求，而我还不知道这一点？
不，MessageBox不允许指定大小，因为底层 Win32 API 也不允许指定大小。
不可能，您应该为此创建自己的表单"，然后是一些示例和/或指南。
这是正确的，无论您是否同意这是一个好主意，都不会改变消息框不支持位置和大小的事实。它们应该是快速、简单、原始的东西，它们几乎没有作用，但可能会完成工作。任何超过这个需要表格。我想虽然你可能想要大小，但其他人可能想要透明度，甚至能够更改按钮上的文本（你只能从选择中选择） - 它不能让每个人都满意。在这一点上，你几乎已经需要一种形式了。