自从 Windows Form 在 2018 年底开源并移植到 .NET Core 以来，团队和我们的外部贡献者都在忙于修复旧的漏洞和添加新功能。在这篇文章中，我们将讨论 .NET 5.0 中 Windows  Form 的新特性。

Windows控件的增加与增强

　　也许今天关于 Windows Form 最令人兴奋的事情是我们在 GitHub 上的充满活力和参与度的社区。许多新特性和增强是我们的社区成员建议的，甚至是完全实现的。在 .NET 5.0 的时间表内，我们已经接受并合并了 900 多个 pull-request，其中 70% 以上的 PRs 来自我们的社区。我们非常感谢 @hughbe， @gpetrou， @weltkante， @kpreisser 和许许多多帮助我们改进的开发者们。

　　以下是我们从社区收到的一些贡献的例子。

新TaskDialog控件

　　@kpreisser贡献

　　task dialog 是一种对话框，可用于显示信息和接收用户的简单输入，但具有比 message box 更多的功能。与 message box 类似，操作系统根据您设置的参数对其进行格式化。

改进ListView

　　@hughbe 和 @lonitra 贡献

　　ListView 控件对于 Windows 窗体开发人员来说是非常熟悉的，但是它缺少 API 来方便地访问 Windows Vista 中添加的一些特性，比如可折叠组、组任务、副标题和页脚。

　　在 .NET 5.0 中，我们弥补了 API 的差距，现在 Windows Form 的 ListView 更接近于本地的 Win32 控件。

改进FileDialog

　　@jnm2 贡献

　　FileDialog 收到了一个新的 API : FileDialog.ClientGuid。Windows file dialog 允许调用应用程序将 GUID 与对话框的持久化状态关联起来。对话框的状态可以包括诸如最近访问的文件夹、对话框的位置和大小等因素。通常，此状态是基于可执行文件的名称持久化的。通过指定 GUID，应用程序可以为同一应用程序中对话框的不同版本拥有不同的持久化状态(例如，import dialog 和 open dialog)。

性能改进

　　一直被认为是围绕 Win32 API 集的托管封装。因此，Windows Form 一直严重依赖互操作层来与非托管 Windows 组件通信。在 .NET Core 早期的首要任务就是优化我们的互操作层，使结构具有 blittable（blittable 是：在托管和非托管内存中都有公共的表示形式，而不需要 Interop 封送拆收器的特殊处理...），明确地选择更有效的“W”函数，并在可能的情况下使用“unsafe”代码。所有这些变化都是我们所说的“花生酱变化”，从某种意义上说，每一个变化都很小，很难观察到，但在应用程序的生命周期中，这些变化累积起来会带来实质性的性能提升。

　　在 .NET 5.0 中，我们提高了门槛，优化了几个绘制路径。历史的 Windows Form 依赖于 GDI+（和一些 GDI）来呈现操作。虽然 GDI+ 比 GDI 更容易使用，因为它通过 Graphics 对象抽象设备上下文（包含特定显示设备信息的结构，如显示器或打印机），但由于额外的开销，它的速度也很慢。在我们处理纯色和笔刷的一些情况下，我们选择使用 GDI。

　　我们还扩展了一些渲染相关 IDeviceContext 接口的 API，例如 PaintEventArgs，它可能不能直接提供给 Windows Form 开发者，允许我们绕过 GDI+ 图形对象，从而减少分配和获得速度。这些优化显示了重绘路径中内存消耗的显著减少，在某些情况下节省了 10 倍内存分配。

　　如果你想了解更多的技术细节，你可以观看 API 评论，或者观看。.NET Community Standup，Jeremy Kuhne在其中谈论了这些优化。

　　你可以在这里获取测试项目：https://github.com/JeremyKuhne/RedrawPerformance，并自己验证结果，就像我们的用户之一——Jeremy Sinclair：

　　最后重要一点，我们已经扩展了 TextRenderer API 来接受 ReadOnlySpan<char>重载，因为绘制和测量文本是一个非常常见的活动。当可以避免新的字符串分配时（分割其他输入，构建基于堆栈的字符数组，等等），这将允许显著更有效的文本渲染。

可访问性改进和修复

　　在过去的几年中，团队一直在更新已经有20多年的 Windows Forms SDK，以满足今天的可访问性需求和适用性。

　　在 .NET 5.0 中，我们做了很多改进，包括但不限于以下内容：

　　UI 自动化支持的许多控件，包括：

• • • Button

    • ListView

    • CheckBox

    • RadioButton, 等

　　LegacyIAccessible Control Pattern 支持使客户端能够更好地与UI控件交互，并允许开发人员为其控件设置自定义 AccessibleRole 属性。

　　Test 和 TextRange 控件模式支持客户端从基于文本的控件检索文本内容、文本属性和嵌入的对象。

　　我们还修复了一些在某些辅助工具下影响用户体验的问题。例如，我们重写了可访问性实现，以访问 AccessibleObject 不再导致过早创建控件句柄的方式，这反过来确保了更多可预测的控制行为，并避免了 UI 中的意外情况。

　　我们还改进和纠正了一些控件（如 PropertyGrid 和 MonthCalendar）中的行为，这些控件可能会阻止易用性工具正确导航 UI，或者在严重的情况下，导致应用程序崩溃。

VB支持

　　Visual Basic 及其应用程序框架在 .NET 5 和 Visual Studio 16.8 中得到了支持！Visual Studio 16.8 包含 Windows Form 设计器，因此 Visual Basic已经为迁移现有应用程序或创建新应用程序做好了准备。

　　更多信息参考《Visual Basic WinForms Apps in .NET 5 and Visual Studio 16.8 post.》

　　向@paul1956致敬，感谢他帮助我们解决Visual Basic相关问题。

破坏性变化

　　虽然我们打算尽可能地保持与 .NET Framework 和 .NET Core 的向后兼容性，但这并不总是谨慎的。你可以在这里找到破坏性变化的列表:

• • • .NET Framework to .NET Core 3.1

    • .NET Core 3.1 to .NET 5.0

　　已知问题列表请参考《.NET 5.0 Known Issues document》。

展望未来

　　我们意识到目前的高 DPI 支持还远远不够完美，这是我们计划在 .NET 6.0 时间框架内改进的地方。“高DPI支持”的含义有很多方面，所以我们很乐意了解更多它对你的意义。如果你有特别的问题想让我们解决，请在下面留下评论或直接在 dotnet/winforms 中提交问题。

　　我们计划继续进行“花生酱优化”、可访问性改进、可空引用类型注释和一般代码改进。

报告bug并提出建议

　　如果您有任何意见、建议或面临的问题，请让我们知道！通过 Visual Studio Feedback 提交 Visual Studio 和 Designer 相关的问题（在 Visual Studio 的右上角寻找一个按钮），以及在我们的 GitHub 仓库中提交 Windows 窗体运行时相关的问题。

　　我们还考虑 API 建议，进一步丰富 Windows 窗体 SDK，使构建 Windows 应用程序更容易（如任务对话框）。如果你拥护一个提案——你很有可能会在 Windows Forms SDK 中看到它。

　　你也可以成为 Windows 窗体代码库的贡献者！我们的存储库中有标记为“up for grabs”的项目，并批准了准备开发的 API，我们将非常感谢您帮助实现它们！

　　编码快乐！

原文链接

　　https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-runtime-in-net-5-0/