С тех пор как Windows Forms был «Open Soursed» в конце 2018 года и в целом интерфейс был перенесен на .NET Core, и команда, и наши внешние участники были заняты исправлением старых ошибок и добавлением новых функций. В этом посте мы поговорим о новых возможностях среды выполнения Windows Forms в .NET 5.0. Заглядывайте под кат!
Пожалуй, самое крутое в Windows Forms сегодня — это живое и заинтересованное сообщество на GitHub. Многие из новых функций и улучшений были либо предложены, либо даже полностью реализованы членами нашего сообщества. В рамках разработки .NET 5.0 мы приняли и смерджили более 900 запросов, причем более чем 70% этих запросов исходило от нашего сообщества. Огромный привет всем его участникам, которые помогли нам улучшить Windows Forms runtime.
Вот несколько примеров того, что мы получили от сообщества.
Task dialog — это диалоговое окно, которое может использоваться для отображения информации и получения простого ввода от пользователя, но имеет больше функций, чем окно сообщения. Как и окно сообщения, оно форматируется операционной системой в соответствии с заданными вами параметрами.
Элемент управления ListView хорошо знаком разработчикам Windows Forms, однако в нем отсутствовал API для легкого доступа к некоторым функциям, добавленным в Windows Vista, таким как сворачиваемые группы, групповые задачи, субтитры и нижние колонтитулы.
В .NET 5.0 мы преодолели разрыв API, и теперь Windows Forms ListView намного ближе к паритету с нативным элементом управления Win32.
Новый API включает: * свертывание/развертывание группы ListView * нижние колонтитулы группы ListView * субтитры групп ListView * задачи группы ListView * изображение заголовка группы ListView
FileDialog получил новый API: FileDialog.ClientGuid. Диалоговое окно файла Windows позволяет вызывающему приложению связать идентификатор GUID с постоянным состоянием диалогового окна. Состояние диалогового окна может включать такие факторы, как последняя посещенная папка, а также положение и размер диалогового окна. Обычно это состояние сохраняется в зависимости от имени исполняемого файла. При указании GUID приложение может иметь разные сохраняемые состояния для разных версий диалогового окна в одном приложении (например, диалогового окна импорта и открытого диалогового окна).
Windows Forms всегда была известна как управляемая оболочка для Win32 API. Таким образом, Windows Forms всегда сильно зависела от уровня взаимодействия с неуправляемыми компонентами Windows. Главным приоритетом с первых дней существования .NET Core была оптимизация нашего уровня взаимодействия, создание непреобразуемых структур, явный выбор более эффективных «W»-функций и использование «unsafe» кода там, где это возможно. Все эти изменения — это то, что мы называем «изменениями арахисового масла», в том смысле, что каждое из них является крошечным и вряд ли заметным, но за время жизни приложения эти изменения в сумме приводят к существенному увеличению производительности.
В .NET 5.0 мы подняли планку выше и оптимизировали несколько путей. Исторически Windows Forms полагалась на GDI+ (и некоторые GDI) для операций отрисовки. Хотя GDI+ проще в использовании, чем GDI, поскольку он абстрагирует контекст устройства (структуру с информацией о конкретном устройстве отображения, таком как монитор или принтер) через объект Graphics, он также работает медленно из-за дополнительных накладных расходов. В ряде ситуаций, когда мы имеем дело со сплошными цветами и кистями, мы решили использовать GDI.
Мы также расширили ряд API-интерфейсов, связанных с рендерингом (например, PaintEventArgs), с помощью интерфейса IDeviceContext, который, хотя и может быть недоступен напрямую разработчикам Windows Forms, позволяет нам обойти объект GDI+ Graphics и, таким образом, уменьшить выделение и увеличить скорость. Эти оптимизации показали значительное сокращение потребления памяти в путях перерисовки, в некоторых случаях экономия x10 при распределении памяти.
Для более подробного технического погружения вы можете посмотреть сегмент обзора API или сегмент .NET Community Standup, где Джереми Кун рассказывает об этих оптимизациях.
Вы можете взять тестовый проект здесь и самостоятельно проверить результаты, как и один из наших пользователей — Джереми Синклер:
И последнее, но не менее важное: мы расширили API TextRenderer, чтобы принимать перегрузки ReadOnlySpan char, потому что рисование и измерение текста — довольно распространенное действие. Это позволит значительно более эффективно отрисовывать текст, когда можно избежать выделения новых строк (нарезка другого ввода, построение массива символов на основе стека и т.д.).
В течение последних нескольких лет команда обновляла Windows Forms SDK 20-летней давности, чтобы он соответствовал сегодняшним требованиям доступности и соответствию.
В .NET 5.0 мы внесли много улучшений, включая, помимо прочего, следующие:
Мы также исправили несколько проблем, которые влияли на UX при использовании некоторых инструментов доступности. Например, мы переработали реализации специальных возможностей таким образом, чтобы доступ к AccessibleObject больше не приводил к преждевременному созданию элемента управления Handle, что, в свою очередь, обеспечивает более предсказуемое поведение элементов управления и позволяет избежать неожиданных сюрпризов в пользовательском интерфейсе.
Мы также улучшили и исправили поведение в нескольких элементах управления (таких как PropertyGrid и MonthCalendar), которые могли помешать инструментам специальных возможностей правильно перемещаться по пользовательскому интерфейсу или, в тяжелых случаях, вызывать сбой приложений.
Visual Basic вместе с его Application Framework поддерживается в .NET 5 и Visual Studio 16.8! Visual Studio 16.8 включает конструктор Windows Forms Designer, поэтому Visual Basic готов для миграции существующих приложений или создания новых приложений.
Для получения дополнительной информации обратитесь к публикации Visual Basic WinForms Apps в .NET 5 и Visual Studio 16.8.
Хотя мы намерены максимально поддерживать обратную совместимость с .NET Framework и .NET Core, это не всегда разумно. Вы можете найти список критических изменений здесь:
Список известных проблем см. в документе «Известные проблемы .NET 5.0».
Улучшения и дополнения элементов управления Windows
Пожалуй, самое крутое в Windows Forms сегодня — это живое и заинтересованное сообщество на GitHub. Многие из новых функций и улучшений были либо предложены, либо даже полностью реализованы членами нашего сообщества. В рамках разработки .NET 5.0 мы приняли и смерджили более 900 запросов, причем более чем 70% этих запросов исходило от нашего сообщества. Огромный привет всем его участникам, которые помогли нам улучшить Windows Forms runtime.
Вот несколько примеров того, что мы получили от сообщества.
Новый элемент управления TaskDialog
Task dialog — это диалоговое окно, которое может использоваться для отображения информации и получения простого ввода от пользователя, но имеет больше функций, чем окно сообщения. Как и окно сообщения, оно форматируется операционной системой в соответствии с заданными вами параметрами.
Улучшения ListView
Элемент управления ListView хорошо знаком разработчикам Windows Forms, однако в нем отсутствовал API для легкого доступа к некоторым функциям, добавленным в Windows Vista, таким как сворачиваемые группы, групповые задачи, субтитры и нижние колонтитулы.
В .NET 5.0 мы преодолели разрыв API, и теперь Windows Forms ListView намного ближе к паритету с нативным элементом управления Win32.
Новый API включает: * свертывание/развертывание группы ListView * нижние колонтитулы группы ListView * субтитры групп ListView * задачи группы ListView * изображение заголовка группы ListView
Улучшения FileDialog
FileDialog получил новый API: FileDialog.ClientGuid. Диалоговое окно файла Windows позволяет вызывающему приложению связать идентификатор GUID с постоянным состоянием диалогового окна. Состояние диалогового окна может включать такие факторы, как последняя посещенная папка, а также положение и размер диалогового окна. Обычно это состояние сохраняется в зависимости от имени исполняемого файла. При указании GUID приложение может иметь разные сохраняемые состояния для разных версий диалогового окна в одном приложении (например, диалогового окна импорта и открытого диалогового окна).
Улучшения производительности
Windows Forms всегда была известна как управляемая оболочка для Win32 API. Таким образом, Windows Forms всегда сильно зависела от уровня взаимодействия с неуправляемыми компонентами Windows. Главным приоритетом с первых дней существования .NET Core была оптимизация нашего уровня взаимодействия, создание непреобразуемых структур, явный выбор более эффективных «W»-функций и использование «unsafe» кода там, где это возможно. Все эти изменения — это то, что мы называем «изменениями арахисового масла», в том смысле, что каждое из них является крошечным и вряд ли заметным, но за время жизни приложения эти изменения в сумме приводят к существенному увеличению производительности.
В .NET 5.0 мы подняли планку выше и оптимизировали несколько путей. Исторически Windows Forms полагалась на GDI+ (и некоторые GDI) для операций отрисовки. Хотя GDI+ проще в использовании, чем GDI, поскольку он абстрагирует контекст устройства (структуру с информацией о конкретном устройстве отображения, таком как монитор или принтер) через объект Graphics, он также работает медленно из-за дополнительных накладных расходов. В ряде ситуаций, когда мы имеем дело со сплошными цветами и кистями, мы решили использовать GDI.
Мы также расширили ряд API-интерфейсов, связанных с рендерингом (например, PaintEventArgs), с помощью интерфейса IDeviceContext, который, хотя и может быть недоступен напрямую разработчикам Windows Forms, позволяет нам обойти объект GDI+ Graphics и, таким образом, уменьшить выделение и увеличить скорость. Эти оптимизации показали значительное сокращение потребления памяти в путях перерисовки, в некоторых случаях экономия x10 при распределении памяти.
Для более подробного технического погружения вы можете посмотреть сегмент обзора API или сегмент .NET Community Standup, где Джереми Кун рассказывает об этих оптимизациях.
Вы можете взять тестовый проект здесь и самостоятельно проверить результаты, как и один из наших пользователей — Джереми Синклер:
И последнее, но не менее важное: мы расширили API TextRenderer, чтобы принимать перегрузки ReadOnlySpan char, потому что рисование и измерение текста — довольно распространенное действие. Это позволит значительно более эффективно отрисовывать текст, когда можно избежать выделения новых строк (нарезка другого ввода, построение массива символов на основе стека и т.д.).
Улучшения и исправления специальных возможностей
В течение последних нескольких лет команда обновляла Windows Forms SDK 20-летней давности, чтобы он соответствовал сегодняшним требованиям доступности и соответствию.
В .NET 5.0 мы внесли много улучшений, включая, помимо прочего, следующие:
- Поддержка автоматизации пользовательского интерфейса для ряда элементов управления, включая:
- Button,
- ListView,
- CheckBox,
- RadioButton и др.
- Поддержка LegacyIAccessible Control Pattern позволяет пользователям лучше взаимодействовать с элементами управления UI и позволяет разработчикам устанавливать настраиваемые свойства AccessibleRole для своих элементов управления.
- Шаблоны элементов управления Text и TextRange позволяют пользователям извлекать текстовое содержимое, текстовые атрибуты и внедренные объекты из текстовых элементов управления.
Мы также исправили несколько проблем, которые влияли на UX при использовании некоторых инструментов доступности. Например, мы переработали реализации специальных возможностей таким образом, чтобы доступ к AccessibleObject больше не приводил к преждевременному созданию элемента управления Handle, что, в свою очередь, обеспечивает более предсказуемое поведение элементов управления и позволяет избежать неожиданных сюрпризов в пользовательском интерфейсе.
Мы также улучшили и исправили поведение в нескольких элементах управления (таких как PropertyGrid и MonthCalendar), которые могли помешать инструментам специальных возможностей правильно перемещаться по пользовательскому интерфейсу или, в тяжелых случаях, вызывать сбой приложений.
Поддержка Visual Basic
Visual Basic вместе с его Application Framework поддерживается в .NET 5 и Visual Studio 16.8! Visual Studio 16.8 включает конструктор Windows Forms Designer, поэтому Visual Basic готов для миграции существующих приложений или создания новых приложений.
Для получения дополнительной информации обратитесь к публикации Visual Basic WinForms Apps в .NET 5 и Visual Studio 16.8.
Критические изменения
Хотя мы намерены максимально поддерживать обратную совместимость с .NET Framework и .NET Core, это не всегда разумно. Вы можете найти список критических изменений здесь:
Список известных проблем см. в документе «Известные проблемы .NET 5.0».
