自從 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/
