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