.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支持」意味着不少方面的內容。 咱們計劃繼續進行「花生醬」優化、可訪問性改進、可空引用類型註釋和常規代碼改進。