.Net 5中Windows Forms執行時的新功能(翻譯)
本文翻譯自Igor的文章，原文地址：https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-runtime-in-net-5-0/#listview-enhancements
自從2018年底 Windows Forms開源並移植到.net core之後，內外部的開發團隊就忙於修復舊的bug和增加新的特性。本文將討論一下.NET5.0中Windows Forms執行時的新增功能。
新增和加強的Windows控制元件
現在Windows Forms最令人興奮的事情可能是我們在GitHub上擁有的活躍的社群。許多新特性和增強功能都是由我們的社群成員建議的，甚至是完全由他們實現的。在.NET5.0執行框架內，我們已經接受併合並了900多個請求，其中70%以上的變更請求來自我們的社群。
向 @hughbe, @gpetrou, @weltkante, @kpreisser 和許多幫助我們改進Windows Forms執行時的人員表示感謝，併為之歡呼。
下面是我們從社群貢獻者收到的一些例子
新的任務進度對話方塊控制元件
任務對話方塊是一個用於顯示資訊並接收使用者簡單輸入的對話方塊，它比訊息框有更多的特性，與訊息框一樣，它由作業系統根據你設定的引數進行格式化。
該控制元件由 @kpreisser貢獻 | 控制元件說明文件 | 任務對話方塊使用例子
ListView控制元件的加強功能
Windows Forms開發人員對於ListView控制元件非常熟悉，但是對於在windows Vista新增的多個功能（如可摺疊組，組任務，字幕和頁尾等），ListView並沒有可供輕易呼叫的Api。
在.NET 5.0中，我們填補了這一塊API的空白，現在Windows Forms ListView與本機Win32控制元件更接近於等價。
新的API包括：
- ListView組摺疊/展開
- ListView組頁尾
- ListView組字幕
- ListView組任務
- ListView組標題影象
由@hughbe和@lonitra貢獻| 說明文件
FileDialog
FileDialog已收到新的API ：FileDialog.ClientGuid。
該api使得呼叫者能讓一個將一個GUID和Windows檔案對話方塊的持久狀態關聯起來。一個對話方塊的狀態可以包括諸如上次訪問的資料夾以及對話方塊的位置和大小之類的因素。一般來說，此狀態是通過可執行檔案的名稱進行持久化的。通過指定GUID，對於同一應用程式中不同版本的對話方塊，應用程式可以具有不同的持久狀態（例如，匯入對話方塊和開啟的對話方塊）。
由@ jnm2提供| 說明文件
效能提升
Windows Forms一直被認為圍繞Win32 API集的託管包裝。因此，Windows Forms始終嚴重依賴於互操作層與非託管Windows元件通訊。.NET Core早期的頭等大事是優化我們的互操作層，使結構更加穩定，顯式選擇更有效的“ W”功能，並儘量使用“不安全”程式碼。所有這些更改都是我們所謂的“花生醬更改”：從某種意義上說，每個更改都是很小的，幾乎是不可觀察的，但是在應用程式的整個生命週期中，這些更改加起來可帶來效能提升是可觀的。
在.NET 5.0中，我們提高了標準，並優化了一些繪製路徑。以前的Windows Forms依靠GDI +（和某些GDI）來進行渲染操作。儘管GDI +比GDI更易於使用，因為它通過Graphics物件抽象了裝置上下文（具有有關特定顯示裝置資訊的結構，例如監視器或印表機的資訊），但也因為額外的開銷導致很慢。因此在處理純色和畫筆的許多情況下，我們選擇使用GDI。
我們還使用了IDeviceContext介面擴充套件了一些與渲染相關的API（例如PaintEventArgs），儘管它們可能無法直接提供給Windows Forms開發人員使用，但它讓我們繞過GDI +Graphics物件，從而減少記憶體分配並提高速度。這些優化表明，在重繪路徑中顯著地減少了記憶體消耗，在某些情況下甚至節省了10倍的記憶體分配。
更多的技術細節就可以檢視的API Review 部分，或觀看 Jeremy Kuhne在 .NET Community Standup 裡討論的優化內容。
您也可以從這裡獲取測試專案：https://github.com/JeremyKuhne/RedrawPerformance，然後自己驗證結果
最後同時也比較重要的一點，我們已經擴充套件了TextRendererAPI以接受ReadOnlySpan的過載，因為繪製和測量文字是很常見的操作。
當避免給新的字串分配記憶體時(比如把字串按分割符分成一個字元陣列)， 這樣可以顯著地提高文字渲染的效率。
可訪問性的改進和修復
在過去的幾年中，該團隊一直在更新具有20年曆史的Windows Forms SDK，以滿足當今的可訪問性要求和規範。
在.NET 5.0中，我們進行了許多改進，包括但不限於以下方面
- UI 自動化對一些控制元件的支援，包括：Button，ListView，CheckBox，RadioButton等
- LegacyIAccessible控制元件模式支援使客戶端能夠更好地與UI控制元件進行互動，並允許開發人員為控制元件設定自定義“可訪問角色”屬性。
- Text和TextRange控制元件模式支援使客戶端能夠從文字控制元件的文字內容，文字屬性和嵌入式物件中進行文字檢索。
我們還修復了幾個由於工具導致影響使用者體驗的問題。例如，我們重新設計訪問性，使得訪問一個可訪問的物件時，不再過早地建立控制代碼，以保證控制元件操作的可預測性，避免在介面上出現意外情況。
我們還改進和糾正了多個控制元件（例如PropertyGrid和MonthCalendar）中的操作，避免操作這些工具時無法正常導航到UI，甚至嚴重情況下導致應用程式崩潰。
Visual Basic支援
.NET 5和Visual Studio 16.8也支援基於.Net Framework的Visual Basic！Visual Studio 16.8包括Windows Forms設計器，因此Visual Basic也已準備就緒，可以遷移現有應用程式或建立新應用程式。
有關更多資訊，請參考 Visual Basic WinForms Apps in .NET 5 and Visual Studio 16.8 post.。
同時感謝對@ paul1956幫助我們處理使用Visual Basic相關問題。
重大變化
儘管我們打算儘可能保持與.NET Framework和.NET Core的向後相容性，但並不是總是有效的。您可以在此處找到重大更改的列表：
- .NET Framework到.NET Core 3.1
- .NET Core 3.1到.NET 5.0
有關已知問題的列表，請參考 .NET 5.0 Known Issues document.。
展望未來
我們知道，當前對高DPI的支援還遠遠不夠，這是我們計劃在.NET 6.0的時間範圍內進行改進。“高DPI支援”意味著很多方面的內容。 我們計劃繼續進行“花生醬”優化、可訪問性改進、可空引用型別註釋和常規程式碼改