Больше режимов просмотра. Взгляните на проводник и его значки. DataGrid должен иметь возможность отображать значки / элементы в сетке с группировкой, а также заголовки строк и столбцов.

Я знаю, что это может быть невозможно или выходит за рамки, но это аспект WinUI против Win32, который не так прост, как 1: 1 - и современная версия проводника или общие диалоговые окна файлов - может потребоваться такого контроля. Это может быть тот элемент управления, а не внутренний настраиваемый элемент управления.

Мой список желаний: для меня хорошая сетка данных по умолчанию включает в себя все следующие функции. Я позаимствовал скриншоты из мира html.

Легко отфильтруйте всю страницу с предпочтительным количеством строк.

Выбрать / отменить выбор видимых столбцов, сортировка столбцов, копирование, печать

Экспорт данных в определенный формат.

Изменение порядка столбца путем перетаскивания столбца.

Фильтрация столбца

Фиксированный заголовок - заголовок остается наверху даже при прокрутке

Подробные сведения о строке с шаблоном XAML.

Группировка строк

Порядок строк при перетаскивании

По моему мнению, вышеперечисленные функции должны быть стандартными для всех датагридов.

Если вы хотите выделить datagrid в мире html, я бы также добавил следующее. Я обнаружил, что много раз смотрю на сетку данных, а затем останавливаюсь на просмотре списка, поскольку сетке данных не хватает этих функций.

Проведите по строке, чтобы включить такие функции, как редактирование, удаление, отметка и т. Д.

Вышеупомянутые функции обрабатывают в основном «представление данных», чего по-прежнему не хватает в WinUI, так это того, что, по моему мнению, должно быть встроенной функцией (элементом управления) WinUI, такой как Microsoft Pivot Control. чтобы дополнить сетку данных.

У MS уже есть исходный код для этого, и в те времена это был отличный контроль.

https://www.youtube.com/watch?v=ZJIkQ9nebKY

Теперь вы охватите представление и визуализацию данных, которые должны быть минимумом, чтобы выделить WinUI отдельно от всех основных функций.

Что наиболее важно, он действительно демонстрирует мощь «нативных приложений», которые должны включать в себя потрясающую анимацию и визуально привлекательные элементы управления, мощные и действительно крутые.

Я могу сделать еще один шаг и сказать, что после вышеупомянутых функций (визуализаций) мы можем включить 2D / 3D-анимацию, которая создает концепцию глубины в данных и перенесет нас в другую стратосферу, но я думаю, что это в другой день; ))

Хорошей отправной точкой является изучение вашего партнера Telerik с его RadDataGrid (UWP с открытым исходным кодом). Я использовал его с одним из моих клиентов, и он действительно хорошо работает. Он сверхбыстрый и универсальный. Единственное, что является сложным, это их код, нет возможности что-либо изменить из их движка без хорошего понимания архитектуры.

Я ожидал, что новый DataGrid будет таким же производительным, как и Telerik.

Я очень рад видеть, что команда WinUI рассматривает элемент управления DataGrid.

Наиболее существенные улучшения, которые я хотел бы увидеть от нового элемента управления, заменяющего Toolkit DataGrid:

• Возможность получить DataGridRow по индексу
• События, специфичные для самих DataGridRows. Например, DoubleTapped и RightTapped.
• Плавная прокрутка
• Проверка ввода для переименования ячеек
• DataGridColumn, разработанный специально для значков строк.
• Легкая настройка цветов и т. Д.

Возможность иметь кнопку редактирования, которая помещает перетаскиваемые значки рядом с каждой строкой для перемещения порядка, была бы полезной функцией. Также было бы здорово увидеть, как какие-то тени за строкой поднимаются и перемещаются (поскольку одним из основных атрибутов Fluent является глубина). Маленькие стрелки вверх и вниз могут быть полезны рядом со значком перетаскивания, чтобы упростить перемещение строк с помощью мыши. Если строка перемещается с помощью стрелок, приятным дополнением будет легкая скользящая анимация. При сенсорном вводе также может работать возможность удерживать строку и просто перемещать ее, даже не нажимая кнопку редактирования. Я не уверен, поддерживается ли это уже, но я мог видеть флажки выбора, такие как в проводнике, чтобы было очевидно, какие DataGrids поддерживают выбор строк и просто улучшают общий UX. Приложение для напоминаний iOS содержит некоторые из этих идей (примеры на картинке ниже). Приложение iOS Stocks также имеет аналогичную работу с подвижными строками. Большинство из этих идей также отлично подойдут для столбцов.

@NoahFeller Этот тип действий имеет больше смысла для представления списка. В представлении сетки вы не меняете порядок, должны быть параметры сортировки, но пользователь не перетаскивает вещи.

*Редактировать
Поразмыслив еще немного, я понимаю, чем может быть полезна такая опция. Однако я определенно не думаю, что это должно быть поведение по умолчанию.

@NoahFeller Этот тип действий имеет больше смысла для представления списка. В представлении сетки вы не меняете порядок, должны быть параметры сортировки, но пользователь не перетаскивает вещи.

*Редактировать
Поразмыслив еще немного, я понимаю, чем может быть полезна такая опция. Однако я определенно не думаю, что это должно быть поведение по умолчанию.

Да ты наверное прав @yaichenbaum. Я представлял себе эти предложения как возможность выполнять произвольную сортировку, и подумал, что перетаскивание может быть полезно для этого. Так что я согласен, определенно не по умолчанию, но это может быть очень полезно в качестве опции. Спасибо за ответ!

Простота функции WPF datatable to datagrid. Я фактически боролся в течение прошлой недели или около того, пытаясь заставить datagrid UWP работать так, как у меня это было в WPF, где я мог просто привязать Datagrid к Dataview, а затем заполнить Dataview из SQL с помощью datatable.defaultview. Затем сетка просто отображала таблицу данных. Это было удивительно просто, и UWP до сих пор усложнял это до смехотворного.

сделай это кроссплатформенным

Я хотел бы запросить режим выбора одной ячейки, стиль excel.
Конечной целью является режим с точным поведением, как у WinForms DataGridView.

Наличие набора вариантов виртуализации, которые могут поддерживать различные варианты использования (от вариантов виртуализации с простой прокруткой, таких как повторное использование, до других концепций, таких как разбиение на страницы данных)
Часто (в аналогичных настольных элементах управления, поддерживающих это) некоторые из этих параметров начинают давать сбой при использовании с настраиваемыми шаблонами для столбцов с уникальными данными. Чем больше они могут поддержать в таких случаях, тем лучше.

Если это вообще возможно, предложение Paging Control # 268 должно быть синхронизировано, а все необходимые перехватчики должны быть добавлены в элемент управления DataGrid.

Это хорошие новости! Я ждал чего-нибудь официального от DataGrid с тех пор, как оно появилось в инструментарии сообщества. Это действительно последний элемент управления, отсутствующий в WinUI 3.0, для которого инструментарий сообщества не имеет хорошей альтернативы.

Во-первых, пожалуйста, не изобретайте велосипед. В качестве основы начните с реализации DataGrid в WPF (я знаю, что вы не можете использовать код, но, пожалуйста, используйте 100% API), а НЕ Silverlight. WPF DataGrid был намного более полнофункциональным и имел меньше ошибок в моем тестировании.

Используя набор инструментов сообщества DataGrid, я также запросил следующие дополнения API, которые подходят для различных вариантов использования, которые обсуждаются здесь :

• RowPressed: как обсуждалось выше. Указывает, что строка была нажата, поэтому может произойти дальнейшая обработка или контекстное меню.
• RowDoublePressed: то же, что и RowPressed, только версия с двойным щелчком.
• ColumnHeaderPressed: возникает при нажатии заголовка столбца. Должен иметь приоритет над любыми внутренними обновлениями направления сортировки. Это позволит настраивать меню фильтрации или параметры щелчка правой кнопкой мыши для включения / выключения столбцов.
• ColumnHeaderDoublePressed: то же самое, что ColumnHeaderPressed, только версия с двойным щелчком.
• ColumnHeaderWidthChanged: возникает всякий раз, когда пользователь изменяет размер ширины заголовка столбца. Это позволит сохранить эту информацию в чистом виде. Обычно это требуется при восстановлении состояния пользовательского интерфейса.

У меня также по-прежнему много проблем с тем, что сообщество takeit DataGrid сбрасывает позицию прокрутки вверх после изменения ItemsSource. Это нужно исправить, чтобы смещение сохранялось, как в WPF; однако мы также должны иметь возможность контролировать это, поэтому я бы также предложил следующий API:

• FirstRowInView (): возвращает первую строку, видимую в DataGrid, используемую для восстановления состояния.
• VerticalOffset: снова получить / установить, чтобы восстановить состояние полосы прокрутки.
• HorizontalOffset: Get / Set для восстановления состояния полосы прокрутки.

@RBrid Также помог с некоторым анализом здесь :

Предлагаемые новые события и некоторые улучшения уже существующих событий:

| Событие | Комментарии |
| : --- | : --- |
| ContextRequestedForColumnHeader | Для поддержки отображения контекстного меню (или другого всплывающего окна) при щелчке правой кнопкой мыши заголовка столбца. То же, что и Windows.UI.Xaml.UIElement.ContextRequested но для заголовков столбцов вместо всего DataGrid. |
| ContextCanceledForColumnHeader | То же, что и Windows.UI.Xaml.UIElement.ContextCanceled но для заголовков столбцов, а не для всей DataGrid. |
| ContextRequestedForRow | Для поддержки отображения контекстного меню (или другого всплывающего меню) при щелчке правой кнопкой мыши по строке. То же, что и Windows.UI.Xaml.UIElement.ContextRequested но для строк, а не для всей DataGrid. |
| ContextCanceledForRow | То же, что и Windows.UI.Xaml.UIElement.ContextCanceled но для строк, а не для всей DataGrid. |
| RowTapped | Обратите внимание также на случай нажатия на уже выделенную строку. |
| RowDoubleTapped | То же, что и Windows.UI.Xaml.UIElement.DoubleTapped но для строк, а не для всей DataGrid. |
| RowRightTapped | То же, что и Windows.UI.Xaml.UIElement.RightTapped но для строк, а не для всей DataGrid. См. Также ContextRequestedForRow . |
| PointerPressedInRow | То же, что и Windows.UI.Xaml.UIElement.PointerPressed но для строк, а не для всей DataGrid. |
| PointerReleasedInRow | То же, что и Windows.UI.Xaml.UIElement.PointerReleased но для строк, а не для всей DataGrid. |
| PointerMovedInRow | То же, что и Windows.UI.Xaml.UIElement.PointerMoved но для строк, а не для всей DataGrid. Возможно, PointerMovedInRow будет срабатывать только при захвате указателя. |
| ColumnHeaderTapped | Также обратите внимание на случай касания заголовка столбца, который уже выбран. |
| ColumnHeaderDoubleTapped | То же, что и Windows.UI.Xaml.UIElement.DoubleTapped но для заголовков столбцов, а не для всей DataGrid. |
| ColumnHeaderRightTapped | То же, что и Windows.UI.Xaml.UIElement.RightTapped но для заголовков столбцов вместо всего DataGrid. См. Также ContextRequestedForColumnHeader . |
| ColumnHeaderWidthChanged | В качестве альтернативы можно назвать ColumnHeaderResized . В аргументы события включите логическое свойство, которое указывает, было ли оно изменено пользователем или изменено программно. Очевидно, что аргументы событий также должны указывать, какой заголовок столбца был изменен / изменен. |
| SortOrderChanged | Должен срабатывать при изменении списка выбранных заголовков столбцов. Также срабатывает, когда любой из выбранных столбцов переключается между возрастающим и убывающим порядком. В аргументы события включите логическое свойство, которое указывает, был ли порядок сортировки изменен пользователем или изменен программно. См. Также предыдущее событие Sorting . Я думаю, что новое событие SortOrderChanged будет запущено после Sorting события
| Sorting | Уже существует, но рассмотрите возможность добавления настраиваемого логического свойства в аргументы событий, которое позволяет отменить запрос сортировки. Например, сортировка может быть недействительной или не может быть выполнена, и ее необходимо отменить. Также добавьте логическое свойство, чтобы указать, была ли сортировка запрошена пользователем или программно. |
| ColumnSortDirectionChanged | Это событие может быть создано, но оно может быть ненужным, если создается вышеупомянутое событие SortOrderChanged , если SortOrderChanged также запускается при изменении направления сортировки. |
| ColumnDisplayIndexChanged | Уже существует, но рассмотрите возможность добавления логического свойства (в аргументах события), которое указывает, было ли оно изменено пользователем или изменено программно. Кроме того, укажите, почему необходимо иметь оба события - ColumnDisplayIndexChanged и ColumnReordered . Как вариант, исключите одно из этих событий. |
| ColumnReordered | Уже существует, но рассмотрите возможность добавления логического свойства, которое указывает, было ли оно изменено пользователем или изменено программно. |
| SelectionChanged | Уже существует, но рассмотрите возможность добавления логического свойства (в аргументах события), которое указывает, было ли оно изменено пользователем или изменено программно. |
| CopyingRowClipboardContent | Уже существует, но рассмотрите возможность добавления логического свойства к аргументам события, которое указывает, будет ли операция вырезана вместо копирования. Как вариант, сделайте отдельное событие для вырезки. |
| CuttingRowClipboardContent | Не существует. Рассмотрите возможность создания события, которое запускается, когда пользователь пытается вырезать строки (с помощью горячей клавиши Control-X, контекстного меню или иным образом). В качестве альтернативы создайте вышеупомянутое логическое свойство, которое позволит запускать CopyingRowClipboardContent как для операций копирования, так и для операций вырезания |
| PastingRowClipboardContent | Не существует. Рассмотрите возможность создания события, которое запускается, когда пользователь пытается вставить (с помощью горячей клавиши Control-V, контекстного меню или иным образом). |

Я думаю, что наиболее важной функцией для меня была бы возможность легко обрабатывать миллион строк и более без необходимости загружать миллионы строк в память. Интерфейс ISupportIncrementalLoading для этого недостаточно хорош, потому что полоса прокрутки отражает только то, сколько строк вы загрузили на данный момент (а не общее количество), и чтобы добраться до строки 1 миллиона, вам придется прокручивать до конца. и загружать все больше и больше данных, и надеюсь, что у меня не закончится память. Но если я знаю, что у меня 1 миллион записей данных, позвольте мне сообщить об этом datagrid, и если я быстро прокручу или перейду к концу, меня могут попросить просто предоставить последние несколько строк.
Подумайте о прокрутке списка строк в базе данных, которые я буду динамически извлекать.

Я думаю, что наиболее важной функцией для меня была бы возможность легко обрабатывать миллион строк и более без необходимости загружать миллионы строк в память. Интерфейс ISupportIncrementalLoading для этого недостаточно хорош, потому что полоса прокрутки отражает только то, сколько строк вы загрузили на данный момент (а не общее количество), и чтобы добраться до строки 1 миллиона, вам придется прокручивать до конца. и загружать все больше и больше данных, и надеюсь, что у меня не закончится память. Но если я знаю, что у меня 1 миллион записей данных, позвольте мне сообщить об этом datagrid, и если я быстро прокручу или перейду к концу, меня могут попросить просто предоставить последние несколько строк.
Подумайте о прокрутке списка строк в базе данных, которые я буду динамически извлекать.

Этот.

«Современный» означает легкий и быстрый, а корпоративные приложения обычно сортируют тонны внутренних данных, чтобы найти и изучить соответствующие записи. Пейджинг, сортировка, асинхронная инкрементная загрузка, бесконечная прокрутка - все это основные компоненты настольных приложений, использующих сетки данных.

MS должна создать образец приложения, которое выделяет эти функции в новой сетке, и с течением времени собирать отзывы корпоративных разработчиков, чтобы улучшить эти возможности. Попросите его запустить большой набор данных, такой как World Wide Importers, чтобы продемонстрировать его эффективность.

@dotMorten

Я думаю, что наиболее важной функцией для меня была бы возможность легко обрабатывать миллион строк и более без необходимости загружать миллионы строк в память.

Я тоже этого желаю. Чтобы помочь с поддержкой миллиона строк (и я имею в виду помощь, а не обязательно полное решение), я предлагаю DataGrid сделать свой текущий метод привязки данных необязательным. Я считаю, что в настоящее время привязка данных является обязательной (если мои знания больше не актуальны для последней версии DataGrid). DataGrid не должен требовать использования Windows.UI.Xaml.Data.Binding в качестве единственного поддерживаемого способа получения значений для каждой ячейки / столбца в каждой видимой строке.

Я предлагаю, чтобы DataGrid позволяла приложениям предоставлять DataGrid экземпляр делегата или интерфейса, который DataGrid будет вызывать всякий раз, когда DataGrid необходимо получить значение ячейки / столбца в строке (альтернативно, этот делегат или интерфейс могут получить всю строку - все значения столбца для указанной строки).

В идеале (если возможно) DataGrid позволит этому делегату или интерфейсу работать асинхронно . Например, делегат или интерфейс могут вернуть Task или IAsyncOperation<TResult> вместо немедленного возврата запрошенного значения.

В качестве альтернативы, асинхронная поддержка также возможна без Task и IAsyncOperation<TResult> , если DataGrid работает аналогично следующей процедуре:

1. DataGrid решает, что ему необходимо получить значение ячейки / столбца 5 в строке с идентификатором 50001. В качестве альтернативы DataGrid решает получить все значения столбца для строки с идентификатором 50001.
2. DataGrid вызывает делегат, экземпляр интерфейса или обработчик событий, который уведомляет приложение о том, что DataGrid запросил загрузку значений данных указанного столбца / строки или всей строки.
3. Приложение получает данные запрошенной строки асинхронно. Например, он может асинхронно выполнять запрос к базе данных SQL.
4. Приложение завершает получение запрошенных данных строки. Приложение вызывает метод в DataGrid, который передает данные строки в DataGrid.
5. DataGrid отображает данные строки или делает с ними все, что нужно.

Во-первых, вау !! Большое спасибо всем, кто вносит свои идеи. У меня есть несколько конкретных ответов ниже, но в целом я хотел сказать, что я сохраняю массу этих комментариев и мне действительно нравится слышать, как мы можем создать потрясающий современный DataGrid. Продолжайте!

@Pinox большое спасибо за подробный ответ и скриншоты. Ваш список желаний потрясающий (особенно эти классные анимации!) - Я согласен с тем, что те функции, которые есть в html, являются хорошим источником вдохновения и просты, но значительно улучшат качество жизни. Обязательно сохраню этот комментарий для использования в будущем!

@verelpode , @robloo , @ duke7553 ДА для событий,

@dotMorten , @jkewley , @verelpode Производительность определенно является одной из основных мотиваций этого проекта и одним из основных улучшений, которые мы хотим реализовать с помощью новой истории виртуализации данных и использования современных элементов управления, таких как ItemsRepeater. Будем держать вас в курсе, как только у нас будет больше подробностей - но еще раз спасибо за эти подробности, которые вы предложили.

@ Laz3rPanth3r , @robloo , @keeganatorr Мы четко и ясно слышим, что вам нравятся DataGrids, которые принадлежат WPF и другим фреймворкам пользовательского интерфейса - мы определенно учтем это в этом обновлении!

Спасибо за отличную работу над DataGrid и за просьбу оставить отзыв! Вот еще несколько предлагаемых улучшений.

Требуется больше подклассов DataGridColumn

Текущих подклассов / реализаций DataGridColumn недостаточно. Я предлагаю создать следующие новые подклассы DataGridColumn :

| Предлагаемый подкласс | Описание |
| : --- | : --- |
| DataGridIconColumn | Распространенным требованием является отображение значка в каждой строке списка, поэтому я предлагаю создать подкласс DataGridColumn именем DataGridIconColumn который преобразует полученное значение ячейки в Windows.UI.Xaml.Controls.IconSource и отображает Экземпляр IconSource (в каждой ячейке отображается другой экземпляр IconSource ). |
| DataGridImageColumn | DataGridImageColumn должен работать так же, как предложенный DataGridIconColumn за исключением того, что он должен отображать Windows.UI.Xaml.Media.ImageSource вместо Windows.UI.Xaml.Controls.IconSource . |
| DataGridDateTimeColumn | Отображает дату и / или время, в зависимости от настроек. Приводит тип значения ячейки к System.DateTimeOffset или System.DateTime (оба поддерживаются) и преобразует его в текст, который будет отображаться в ячейке. Преобразование в текст должно контролироваться настройками / свойствами форматирования в классе DataGridDateTimeColumn . Очевидно, также должна поддерживаться сортировка по дате / времени. |
| DataGridTimeSpanColumn | Приводит значение ячейки к System.TimeSpan и преобразует его в текст, который будет отображаться в ячейке. Преобразование в текст должно контролироваться настройками / свойствами форматирования в классе DataGridTimeSpanColumn . Очевидно, также должна поддерживаться сортировка, и она должна сортировать экземпляры TimeSpan не отображаемый текст. |
| DataGridDataSizeColumn | Приводит тип значения ячейки к System.Int64 , UInt64 , Int32 или UInt32 (все поддерживается) и преобразует его в размер в байтах (как текст ) для отображения. Например, 1572864 будет отображаться как «1,5 МБ», потому что 1572864/1024/1024 = 1,5. Преобразование в текст должно контролироваться настройками / свойствами в классе DataGridDataSizeColumn . Сортировка должна выполняться по исходному целочисленному значению, а не по отображаемому тексту. |
| DataGridCustomColumn | Это должно работать аналогично предыдущему DataGridTemplateColumn за исключением Windows.UI.Xaml.DataTemplate . Он должен вызывать делегат / обратный вызов или событие для генерации и / или обновления отображаемого поддерева элемента графического интерфейса. |
| DataGridTextColumn | Уже существует, но рассмотрите возможность добавления свойств или событий, которые позволяют приложениям переопределять преобразование объекта в текст и функцию сравнения для сортировки. Я объясню это более подробно позже в своем сообщении. |

DataGridCustomColumn будет таким:

public class DataGridCustomColumn : DataGridColumn
{
    public event EventHandler<DataGridDisplayingCellEventArgs> DisplayingCell;
}

public class DataGridDisplayingCellEventArgs : EventArgs
{
    public DataGridColumn Column { get; }
    public object CellValue { get; }
    public Windows.UI.Xaml.UIElement CellUIElement { get; set; } // settable
}

Когда запускается событие DataGridCustomColumn.DisplayingCell , обработчик события должен сгенерировать или обновить собственное поддерево UIElement для отображения DataGridDisplayingCellEventArgs.CellValue и установить для этого свойство DataGridDisplayingCellEventArgs.CellUIElement UIElement поддерево, а затем DataGrid отобразит его.

В следующий раз, когда DataGrid инициирует это событие, DataGrid должен установить свойство DataGridDisplayingCellEventArgs.CellUIElement на экземпляр UIElement который ранее был сгенерирован обработчиком событий, чтобы обработчик событий мог повторно использовать / перерабатывать и обновлять то же поддерево UIElement (возможно, с другим значением в DataGridDisplayingCellEventArgs.CellValue ). Обработчику событий разрешено либо переработать одно и то же поддерево UIElement ЛИБО установить свойство DataGridDisplayingCellEventArgs.CellUIElement на вновь созданное поддерево UIElement .

Также рассмотрите возможность создания нового события DisplayingCell непосредственно в базовом классе DataGridColumn вместо создания подкласса DataGridCustomColumn . Таким образом, событие DataGridColumn.DisplayingCell может разрешить настройку или переопределение сгенерированного UIElement для каждого подкласса DataGridColumn .

В ранее существовавшем DataGridTextColumn настоящее время значение / объект ячейки преобразуется в текст для отображения путем вызова System.Object.ToString . Рассмотрите возможность создания делегата / обратного вызова или события, которое позволяет приложениям переопределять это преобразование значения в текст. Также обратите внимание на свойство, которое позволяет приложениям указывать экземпляр System.Collections.IComparer для переопределения поведения сортировки.

public class DataGridTextColumn : DataGridColumn
{
    public System.Collections.IComparer Comparer { get; set; }
    public DataGridCellValueToToStringConverter CellValueToToStringConverter { get; set; }
}

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

В качестве альтернативы, вместо того, чтобы создавать свойство Comparer в DataGridTextColumn , рассмотрите возможность создания свойства Comparer непосредственно в базовом классе DataGridColumn , чтобы разрешить приложения для управления поведением сортировки для всех подклассов DataGridColumn .

Аналогичным образом свойство CellValueToToStringConverter также может быть создано в базовом классе DataGridColumn потому что было бы полезно иметь возможность преобразовывать любое значение ячейки в текст независимо от того, какой подкласс DataGridColumn используется. Например, при копировании строки в буфер обмена каждое значение ячейки может быть преобразовано в текст. (Как текстовые, так и нетекстовые форматы могут быть одновременно помещены в буфер обмена - приложения обычно делают это для повышения совместимости с другими приложениями.)

Повторная сортировка при выборе DataGridIconColumn или DataGridImageColumn : очевидно, что DataGrid не может сортировать значки или изображения, поэтому он может использовать любое из этих решений:

• Просто запретите конечным пользователям выбирать (сортировать по) заголовок столбца типа DataGridIconColumn или DataGridImageColumn .
• Создайте свойство AlternativeText в классе IconSource . Когда DataGridIconColumn сортирует строки или когда он преобразует ячейку в текст для буфера обмена / копии, он будет использовать свойство AlternativeText .
• Сделайте настраиваемое свойство Comparer (типа System.Collections.IComparer ) в DataGridColumn или DataGridIconColumn .

Доступ к выбранным строкам / элементам

Пожалуйста, подумайте об улучшении функциональности для получения и настройки выбранных строк / элементов, потому что текущая функциональность недостаточна. В настоящее время эти свойства существуют:

public int SelectedIndex { get; set; }
public object SelectedItem { get; set; }
public System.Collections.IList SelectedItems { get; }

Я обнаружил, что иногда мне нужен доступ к экземплярам DataGridRow выбранных строк, поэтому я надеюсь, что в DataGrid можно добавить следующие свойства:

public DataGridRow SelectedRow { get; set; }
public IList<DataGridRow> SelectedRows { get; }

В качестве альтернативы, если описанное выше слишком сложно реализовать, следующий вариант только для чтения менее эффективен, но все же полезен:

public DataGridRow SelectedRow { get; }
public IReadOnlyCollection<DataGridRow> SelectedRows { get; }

Если экземпляры DataGridRow могут быть переработаны , тогда документация по указанным выше свойствам должна предупреждать, что возвращенная информация действительна только временно, поэтому ее следует читать / использовать немедленно и не хранить в течение длительного времени.

Кроме того, уже существующее свойство SelectedIndex дает доступ к одному выбранному индексу, но как насчет получения доступа ко всем выбранным элементам? Поэтому я предлагаю создать следующее свойство SelectedIndexes :

public IList<int> SelectedIndexes { get; } // Suggestion.
public int SelectedIndex { get; set; } // Already exists.

Лично я нахожу имя «SelectedIndex» сбивающим с толку, потому что DataGrid часто используется в сочетании с базой данных, а термин «индекс» имеет совершенно другое значение в базе данных, поэтому я предлагаю переименовать свойства следующим образом, но я ожидаю, что мое предложение по именованию будут отклонены:

public IList<int> SelectedOrdinals { get; }
public int SelectedOrdinal { get; set; }

Я также хочу иметь возможность прокручивать указанные DataGridRow и / или DataGridColumn в поле зрения. В настоящее время существует такой метод:

public void ScrollIntoView(object item, DataGridColumn column);

Я предлагаю заменить существующий ранее метод ScrollIntoView этими двумя методами:

public void ScrollIntoView(DataGridRow row, DataGridColumn column);
public void ScrollItemIntoView(object item, DataGridColumn column);

Получить и установить порядок сортировки одним нажатием

Когда приложения открываются и закрываются, им требуется возможность сохранять и восстанавливать конфигурацию DataGrid конечного пользователя, включая порядок сортировки и другие параметры. Порядок сортировки - это список столбцов, выбранных пользователем. Обратите внимание, что это список, а не отдельный столбец. Одновременно можно выбрать более одного столбца, то есть основной столбец для сортировки, дополнительный столбец для сортировки и третичный столбец для сортировки и т. Д.

Поэтому в DataGrid можно было бы сделать следующее свойство, но на самом деле это только первая идея и она не идеальна:

public IReadOnlyList<DataGridColumn> SortOrder { get; set; }

Вышеупомянутое неидеально, потому что не поддерживает сохранение и восстановление DataGridColumn.SortDirection каждого столбца за одно обращение. Я понимаю, что приложения могут делать это в несколько этапов:

1. Установите предлагаемое свойство SortOrder в список выбранных столбцов.
2. Установите свойство SortDirection каждого из выбранных столбцов (повторите этот шаг для каждого столбца).

Это по-прежнему проблематично, потому что это несколько совпадений, то есть вызывает несколько трудоемких обращений к DataGrid. Конечные пользователи могут заметить и ощутить значительную задержку в DataGrid, содержащем большое количество строк, когда DataGrid повторно используется несколько раз без необходимости. Чтобы устранить эту проблему, я предлагаю следующее решение, которое позволяет приложениям восстанавливать полный порядок сортировки за одно обращение и вызывать не более одного обращения.

public class DataGrid
{
    public IReadOnlyList<DataGridColumnAndDirection> SortOrder { get; set; }
    ...
}

public struct DataGridColumnAndDirection
{
    public readonly DataGridColumn Column;
    public readonly DataGridSortDirection SortDirection;
    public DataGridColumnAndDirection(DataGridColumn, DataGridSortDirection) { ... }
}

Примечание. Я намеренно написал выше IReadOnlyList<DataGridColumnAndDirection> not IList<DataGridColumnAndDirection> потому что приложения не должны иметь возможность изменять список, возвращаемый свойством SortOrder . Вместо того, чтобы изменять список, приложения должны установить свойство SortOrder в список, который DataGrid будет копировать и использовать для полной замены всего списка порядка сортировки. Таким образом, он будет работать в один прием и избежать нескольких дорогих курортов.

Когда DataGrid.SortOrder установлен в новый список, DataGrid также установит соответствующее свойство DataGridColumn.SortDirection в каждом столбце в новом списке SortOrder , но без создания нескольких resorts. Таким образом, DataGrid.SortOrder[i].SortDirection эквивалентно DataGridColumn.SortDirection .

Получить и установить порядок отображаемых столбцов одним нажатием

Когда приложения открываются и закрываются, им нужна возможность сохранять и восстанавливать порядок столбцов конечного пользователя, желательно за одно нажатие. Я знаю, что уже существующее свойство DataGridColumn.DisplayIndex можно установить, поэтому теоретически приложения могут восстанавливать конфигурацию конечного пользователя, перебирая все столбцы в DataGrid.Columns и устанавливая DisplayIndex для каждого, но это может вызвать ошибки. Например, DisplayIndex может выйти из строя или вести себя неожиданным образом, когда приложению необходимо временно установить DisplayIndex одного столбца на тот же DisplayIndex другого столбца. Кроме того, если это не выполняется за один удар, это может вызвать несколько дорогостоящих перерисовок и / или пересчетов.

Поэтому я предлагаю создать свойство ColumnDisplayOrder в DataGrid:

public IReadOnlyList<DataGridColumn> ColumnDisplayOrder { get; set; }

То же, что я упоминал ранее для SortOrder , ColumnDisplayOrder намеренно означает IReadOnlyList<DataGridColumn> не IList<DataGridColumn> потому что он должен работать за одно обращение.
Когда DataGrid.ColumnDisplayOrder установлен на новый список, DataGrid обновит DataGridColumn.DisplayIndex каждого столбца для соответствия.

Разрешить конечным пользователям скрывать / показывать столбцы

В соответствии с уже существующими свойствами DataGridColumn.CanUserReorder т. Д. Я предлагаю создать свойство CanUserChangeVisibility в DataGridColumn . Когда DataGridColumn.CanUserChangeVisibility истинно, конечный пользователь сможет внести изменения в свойство DataGridColumn.Visibility .

Поддержка элементов графического интерфейса, динамически генерируемых во время выполнения.

Разрешить создание графического интерфейса со сведениями о строках без необходимости использования DataGrid.RowDetailsTemplate ( Windows.UI.Xaml.DataTemplate ). Чтобы добиться этого, нужно подумать об API, но вот моя первая идея, как это сделать: возможно, сделать это через уже существующее событие DataGrid.LoadingRow , изменив свойство DataGridRowDetailsEventArgs.DetailsElement быть настраиваемым, чтобы обработчик событий мог сам генерировать (или обновлять) UIElement и передавать его DataGrid, задав свойство DetailsElement .

Причина, по которой обязательное использование Windows.UI.Xaml.DataTemplate является проблемой: хотя шаблоны являются хорошей функцией, концепция шаблона предполагает заранее созданный неизменный фрагмент / документ XAML, который был написан разработчиком заранее. Таким образом, шаблоны являются проблемой, когда приложению необходимо динамически генерировать графический интерфейс во время выполнения. Таким образом, я желаю вышеупомянутых альтернатив DataTemplate .

Перетаскивание строк внутрь и наружу

Я предлагаю сделать возможность опционально разрешать исходящее перетаскивание строк. DataGrid реализует перетаскивание, но не перетаскивание. Когда происходит отбрасывание, DataGrid инициирует событие, и приложение реагирует на событие, чтобы выполнить желаемое действие, когда строка удаляется за пределами DataGrid.

Также возможность дополнительно разрешить входящее перетаскивание строк или элементов / объектов. DataGrid принимает входящее перетаскивание, но не реализует перетаскивание. DataGrid инициирует событие, когда строка / элемент / объект отбрасывается, и приложение реагирует на событие, чтобы выполнить желаемое действие, когда строка удаляется внутри DataGrid.

Индивидуальные фоны ячеек

У нас есть запрос функции от клиента, который хочет, чтобы отдельные ячейки были активированы (путем изменения цвета фона ячейки / кисти) в определенное время (например, когда наше приложение обнаруживает изменения или важные значения или опасные значения, превышающие пределы безопасности и т. Д.).

Таким образом, я мог бы предложить свойство DataGridCell.Background (типа Brush ), но я думаю, что этот способ сделать это, вероятно, неисправен, потому что DataGrid перерабатывает экземпляры DataGridCell , не так ли? Поэтому я предполагаю, что ослабление отдельных ячеек путем установки свойства DataGridCell.Background было бы ненадежным решением.

Лучше всего было бы использовать событие DataGridColumn.DisplayingCell которое я предложил в моем предыдущем сообщении. Обработчик событий может установить свойство CellBackgroundBrush в DataGridDisplayingCellEventArgs .

Простое извлечение данных (значений ячеек) DataGrid

Я знаю, что «тупой» звучит очень плохо, но на самом деле мне бы очень понравилось, если бы DataGrid был «тупым» в области извлечения данных (извлечения значений ячеек, отображаемых DataGrid).

В настоящее время DataGrid пытается выполнять извлечение данных удобным автоматическим способом через свое свойство DataGrid.ItemsSource плюс методы привязки данных (свойство DataGridBoundColumn.Binding ) и интерфейсы, такие как System.ComponentModel.INotifyPropertyChanged .

Да, привязка данных - удобная функция, но на самом деле я бы предпочел, чтобы DataGrid не выполняла никаких задач в этом отделе! Некоторые компоненты Microsoft на самом деле вызывают у меня большие трудности из-за того, что они стараются быть умными, но в итоге оказываются слишком умными . В целом, я бы столкнулся с меньшими трудностями и меньшим объемом работы, если бы эти компоненты перестали быть такими умными / автоматическими / удобными. При разработке автоматического поведения я считаю целесообразным иметь в виду, что автоматический режим звучит великолепно, но может иметь неприятные последствия.

_ "Просто позволь мне сделать это самому." _
Иногда лучшее решение - просто позволить приложениям выполнять задачу самостоятельно, вместо того, чтобы пытаться делать это «автоматически» внутри такого компонента, как DataGrid, но безуспешно. Я хочу, чтобы DataGrid позволил мне полностью выполнить извлечение данных самостоятельно, вместо того, чтобы пытаться автоматически извлекать данные через свойства DataGridBoundColumn.Binding и DataGrid.ItemsSource .

В идеале я бы хотел избавиться от требования использовать свойство DataGrid.ItemsSource для предоставления элементов. @dotMorten упомянул миллион строк. В настоящее время DataGrid обязывает приложения устанавливать DataGrid.ItemsSource , но создавать объект списка, содержащий миллион элементов, нецелесообразно. Поэтому я хочу, чтобы DataGrid перестала быть умной в отделе поиска данных и вместо этого позволила мне полностью выполнять поиск данных самостоятельно, без использования DataGridBoundColumn.Binding и DataGrid.ItemsSource .

@anawishnoff написал:

Производительность, безусловно, является одним из основных мотивов этого проекта и одним из основных улучшений, которые мы хотим реализовать с помощью новой истории виртуализации данных и использования современных элементов управления, таких как ItemsRepeater.

Я вижу, вы сказали, что новая история виртуализации данных улучшит производительность, и это хорошая новость, но устранит ли она также необходимость использования свойства DataGridBoundColumn.Binding для предоставления значений ячеек, отображаемых DataGrid?

Если вся работа по извлечению данных передана на реализовать множество различных сценариев извлечения данных, включая миллион строк, упомянутых

Несколько ненужных функций в WPF DataGrid?

Версия DataGrid для WPF имеет несколько функций, которые кажутся ненужными или непрактичными, и эти функции могут быть пропущены в WinUI DataGrid, но я ожидаю, что некоторые люди, вероятно, имеют другое мнение об этих функциях.

Сколько людей возразят, если WinUI DataGrid откажется от функции, позволяющей конечным пользователям редактировать значения ячеек прямо или непосредственно внутри DataGrid? В нашем случае везде, где мы используем DataGrid, мы всегда устанавливаем для DataGrid.IsReadOnly значение true, чтобы отключить функцию встроенного / прямого редактирования. Мы позволяем пользователям редактировать выбранную строку на отдельной панели или панели или в RowDetails ( DataGrid.RowDetailsTemplate ), но не непосредственно внутри самой DataGrid.

Похоже, что WinUI DataGrid уже продвинулся в направлении отказа от поддержки встроенного / прямого редактирования, потому что в WPF DataGrid были CanUserAddRows и CanUserDeleteRows но эти свойства больше не существуют в WinUI DataGrid. Почему бы не полностью отказаться от функции встроенного / прямого редактирования? Сколько людей возражают против этой идеи?

Индивидуальный выбор ячеек: WPF DataGrid имеет свойство SelectionUnit которому можно присвоить значение Cell , FullRow или CellOrRowHeader . В нашем случае мы всегда устанавливаем его на FullRow и никогда не обнаруживали необходимости устанавливать его на Cell . Однако я вижу, что один человек здесь уже запросил режим выбора одной ячейки. Мой вопрос в том, является ли режим выбора ячейки обычным или редким запросом.

С другой стороны, выбор отдельных ячеек может быть полезен, когда пользователь копирует строки / ячейки в буфер обмена. Это позволит пользователям копировать отдельную ячейку (или несколько смежных ячеек) в буфер обмена вместо копирования всей строки. Однако я не уверен, действительно ли эта функция ценна или нет.

| Сомнительная особенность в WPF | Комментарии |
| : --- | : --- |
| DataGrid.IsReadOnly | Может быть, нет реальной необходимости когда-либо устанавливать IsReadOnly на false? |
| DataGrid.CanUserAddRows | Не существует в WinUI DataGrid. Уже заброшены или, может быть, еще не реализованы (план не знаю). |
| DataGrid.CanUserDeleteRows | Не существует в WinUI DataGrid. Уже заброшены или, может быть, еще не реализованы (план не знаю). |
| DataGrid.SelectionUnit | Не существует в WinUI DataGrid. |

Вау, невероятная дискуссия здесь. ❤️

Я также согласен с API WPF DataGrid. WPF DataGrid - это действительно тот DataGrid, который мне нужен для WinUI 3.0.

Но даже в WPF DataGrid отсутствуют некоторые функции. В прошлом большинство моих клиентов использовали более мощные сторонние DataGrid для получения следующих функций:

• Фильтры в заголовках столбцов
• Полная строка фильтра в верхней части DataGrid
• Мощное отображение иерархических данных. Некоторые сторонние DataGrids действительно работают как мощный TreeView с вложенными DataGrids. Хотя WPF DataGrid позволяет создавать что-то подобное, он не поддерживает это из коробки.
• Поддержка разных типов данных. Например, столбец DateTime. В WPF DataGrid вы должны использовать DataGridTemplateColumn

Но в любом случае, что бы вы ни делали, я думаю, что создание DataGrid - это мощное заявление и приверженность WinUI 3.0. Для бизнес-приложений нельзя серьезно относиться к инфраструктуре пользовательского интерфейса, которая не содержит встроенного DataGrid. И приятно видеть, что это вложение сделано в WinUI!

@thomasclaudiushuber

Для бизнес-приложений нельзя серьезно относиться к инфраструктуре пользовательского интерфейса, которая не содержит встроенного DataGrid. И приятно видеть, что это вложение сделано в WinUI!

Согласовано! В нашем случае DataGrid - это критически важный компонент, который мы используем во многих местах и ​​без которого жить не можем.

Мощное отображение иерархических данных. Некоторые сторонние DataGrids действительно работают как мощный TreeView с вложенными DataGrids.

Я разрываюсь на эту тему, потому что - как и вы - я бы нашел иерархический DataGrid полезным в некоторых ситуациях, но меня беспокоит то, что если DataGrid действительно реализует иерархические функции, тогда он может стать чрезмерно сложным и трудным, и выпуск DataGrid, скорее всего, будет значительно задержан. Новые функции будет трудно добавить из-за сложности создания новых функций, совместимых как с иерархической, так и с неиерархической функциональностью.

Чтобы устранить вышеупомянутую проблему сложности / задержек, я предлагаю следующее решение: создать отдельный класс с именем HierarchicalDataGrid который внутренне использует / обертывает экземпляр DataGrid . В качестве альтернативы HierarchicalDataGrid может публично наследовать DataGrid но я подозреваю, что это наследование непрактично, поэтому я предпочитаю предлагать HierarchicalDataGrid наследовать Control и внутренне иметь закрытое поле введите DataGrid . Таким образом, иерархическая функциональность будет реализована на уровне HierarchicalDataGrid который управляет внутренним неиерархическим экземпляром DataGrid .

Ключевым преимуществом вышеупомянутого решения является то, что оно будет предоставлять желаемые иерархические функции _ без_ увязки в DataGrid , не делая DataGrid настолько сложным, что оно становится неуправляемым и медленным в развитии.

Поддержка разных типов данных. Например, столбец DateTime.

Я согласен. Обратите внимание на DataGridDateTimeColumn и DataGridTimeSpanColumn которые я предложил в предыдущем сообщении.

@Pinox

Легко фильтровать всю страницу

@thomasclaudiushuber

Фильтры в заголовках столбцов; Полная строка фильтра вверху DataGrid;

Фильтры были бы полезны для помощи конечным пользователям быстро найти строку или строки, вместо текущей ситуации, когда им приходится вручную просматривать большое количество строк, чтобы найти то, что они ищут.

Но как насчет проблемы сопоставления текста фильтра пользователя с нетекстовыми столбцами? Что означают столбцы, отличные от DataGridTextColumn , например фильтрация с помощью DataGridTemplateColumn т. Д.? Я предлагаю решить эту проблему примерно с помощью следующего решения, которое дает DataGridColumn (и подклассам) возможность преобразовывать значение ячейки в ключевые слова для использования при поиске / фильтрации / сопоставлении.

public delegate void DataGridCellValueToKeywordsConverter(object cellValue, ICollection<string> outputKeywords);

public class DataGridColumn
{
    ...
    public DataGridCellValueToKeywordsConverter CellValueToKeywordsConverter { get; set; }

    /// <param name="cellValue">The input/source value of the cell, to be converted to keywords.</param>
    /// <param name="outputKeywords">A collection that the method will add the keywords to.  The method invokes ICollection.Add for each keyword.</param>
    public virtual void ConvertCellValueToKeywords(object cellValue, ICollection<string> outputKeywords)
    {
        // Subclasses can override this method.  The default behavior is to invoke the delegate to do the job.
        DataGridCellValueToKeywordsConverter d = this.CellValueToKeywordsConverter;
        if (!(d is null)) d(cellValue, outputKeywords);
    }
}

Вот пример использования метода ConvertCellValueToKeywords :

void TestKeywords(DataGridColumn column)
{
    var keywords = new System.Collections.Generic.HashSet<string>();
    foreach (object cellValue in someCellValueList)
    {
        keywords.Clear();
        column.ConvertCellValueToKeywords(cellValue, keywords);
        CheckIfFilterTextMatchesAnyKeyword(keywords);
    }
}

В качестве альтернативы значение ячейки можно преобразовать в одну строку вместо набора ключевых слов, но причина, по которой я предложил коллекцию ключевых слов, заключается в том, что ключевые слова позволяют использовать алгоритмы поиска, которые работают с высокой скоростью, даже когда количество строк очень большой.

Легкое копирование прошлого из Excel
Теперь нет возможности использовать ctrl + v для копирования содержимого ячеек Excel в datagrid. Теперь он копирует все содержимое ячеек в одну ячейку сетки данных.

Обеспечьте надлежащую поддержку нескольких выбранных элементов, сделав SelectedItems свойством зависимости, позволяющим использовать привязку данных при управлении выбранными строками.

@verelpode Я вижу, что выбор отдельных ячеек полезен для любого приложения типа электронной таблицы, не так ли? Я думаю, что это имеет большее значение в сценариях редактирования, чем в сценариях просмотра. При просмотре данных в сетке данных без редактирования я согласен, что не увижу использования для выбора отдельных ячеек и всегда буду иметь полный выбор строк.

@anawishnoff Я думаю, что @ Laz3rPanth3r согласится, и пара вопросов здесь и здесь из набора инструментов, что возможность легко и просто принимать данные в DataGrid является важной функцией. Вы должны иметь возможность загружать сетку путем привязки к коллекции объектов или расширять объекты в списке. Было бы здорово, если бы он мог разумно выбирать столбцы для чисел, строк и основных типов данных. После этого разработчик всегда может проделать дополнительную работу, чтобы настроить отдельные столбцы сверх этого.

Я вижу, что выбор отдельных ячеек полезен для любого приложения типа электронных таблиц, не так ли?

В электронной таблице заголовки столбцов именуются восходящими буквами алфавита A, B, C, D,… и тип каждого столбца такой же, как если бы каждый столбец использовал DataGridTextColumn и никакой другой столбец type необходим, и имена столбцов на самом деле не нужны, потому что они автоматически генерируются из алфавита.
Еще одно различие между DataGrid и электронной таблицей заключается в том, что в электронной таблице не сортируются строки, когда вы щелкаете заголовки столбцов.

Я хочу сказать, что между DataGrid и электронной таблицей существует только внешнее сходство (в основном визуальное). DataGrid на самом деле не работает как электронная таблица. Метод извлечения данных из ячеек DataGrid также плохо подходит для электронных таблиц.

Мне нравится DataGrid, но он бы плохо работал, если бы я попытался использовать его для реализации электронной таблицы. Я не думаю, что DataGrid - правильный выбор для тех, кто хочет реализовать электронную таблицу.

Существующий дизайн DataGrid намного лучше согласуется с базой данных SQL, чем с электронной таблицей, и разработчики баз данных SQL громко кричали бы, если бы кто-то попытался заявить, что база данных - это «просто электронная таблица».

@verelpode Ваш вклад настолько подробный и продуманный, большое вам спасибо за все это! Я хочу поговорить об идее привязки источника данных / свойства ItemsSource для DataGrid, как вы упомянули, и @ michael-hawker тоже.

В настоящее время DataGrid обязывает приложения устанавливать DataGrid.ItemsSource, но нецелесообразно создавать объект списка, содержащий миллион элементов. Таким образом, я хочу, чтобы DataGrid перестала быть умной в отделе поиска данных и вместо этого позволила мне полностью выполнять поиск данных самостоятельно, без использования DataGridBoundColumn.Binding и DataGrid.ItemsSource.

Это интересно, и я хотел бы подробнее остановиться на этом, поскольку мы действительно заинтересованы в производительности. Какого рода ситуацию / сценарий с данными вы конкретно ищете? Хотели бы вы подключить DataGrid прямо к результату SQL-запроса, или базе данных, или чему-то в этом роде?

@khoshroomahdi Под копированием и

@alexyak , не могли бы вы немного расшириться? Свойство SelectedItems в настоящее время позволяет вам получить все выбранные элементы в DataGrid (хотя и в режиме расширенного выбора, а не в режиме множественного выбора). Из нескольких других комментариев я вижу, что выбор в DataGrid определенно требует доработки, но я хочу лучше понять ваш запрос.

@anawishnoff, да, именно так.
У меня есть данные в ячейках Excel, и я хочу скопировать их в запущенное приложение.

Для сценариев без привязки к данным мы должны посмотреть, как элемент управления WinForms DataGridView, который я написал много лет назад, поддерживает виртуальный режим: https://docs.microsoft.com/en-us/dotnet/api/system. windows.forms.datagridview.virtualmode

В настоящее время DataGrid обязывает приложения устанавливать DataGrid.ItemsSource, но нецелесообразно создавать объект списка, содержащий миллион элементов. Таким образом, я хочу, чтобы DataGrid перестала быть умной в отделе поиска данных и вместо этого позволила мне полностью выполнять поиск данных самостоятельно, без использования DataGridBoundColumn.Binding и DataGrid.ItemsSource.

Я согласен, это тоже было бы неплохо. Я думаю о чем-то вроде ListBox, где вы можете либо добавлять элементы вручную, либо устанавливать ItemsSource. Тем не менее, в прошлом я просто генерировал новый DataTable, представляющий частичное представление полной базы данных для реализации разбиения на страницы (что является хорошим вариантом использования для этого). Затем для представления этого DataTable может быть установлено значение ItemsSource. Так что, хотя я определенно считаю, что это хорошо, это не кажется обязательным для высокой производительности.

Что касается всех комментариев, превращающих элемент управления в более или менее подмножество Excel (r), я думаю, что DataGrid из коробки должен поддерживать выбор ячеек и редактирование отдельных ячеек. Однако такие вещи, как копирование / вставка между внешними приложениями, должны выполняться разработчиком.

@alexyak Что касается вашего запроса на то, чтобы сделать SelectedItems реальным привязываемым DependencyProperty, это также было бы здорово для восстановления состояния (большинство моих запросов на функции до сих пор предназначены для восстановления состояния просмотра). Я думаю, что это проблема всего фреймворка, поскольку она не поддерживается ни одним из известных мне элементов управления WinUI / UWP. Вероятно, это должен быть общий запрос функции. См. Обсуждение здесь

@anawishnoff написал:

Ваш вклад настолько подробный и продуманный, большое вам спасибо за все это!

Спасибо, я рад слышать, что мой вклад помогает сделать DataGrid еще лучше :)

Какого рода ситуацию / сценарий с данными вы конкретно ищете? Хотели бы вы подключить DataGrid прямо к результату SQL-запроса, или базе данных, или чему-то в этом роде?

Это все еще слишком умно. Это умное поведение не позволяет различным приложениям выполнять извлечение данных разными способами. У разных приложений совершенно разные обстоятельства, поэтому «лучшая» система извлечения данных различается для разных приложений - единого «лучшего» не существует. Например, некоторые приложения никогда не отображают более пары сотен строк, тогда как некоторые другие приложения могут работать с миллионом строк, как упомянуто @dotMorten , поэтому один размер обуви не подходит для всех.

Я предлагаю по-настоящему отупить его до этого уровня:

1. DataGrid решает, что ему необходимо отобразить (или иным образом использовать) значение, которое существует в столбце 5 строки 9001 во внешней системе хранения данных.
2. DataGrid уведомляет приложение о том, что ему требуется значение для столбца 5 строки 9001.
3. Приложение извлекает значение столбца 5 строки 9001. Это может включать асинхронный SQL-запрос, асинхронную задачу C # или любую другую систему данных. В идеале DataGrid должен позволять этому шагу быть асинхронным.
4. Приложение уведомляет DataGrid о завершении получения значения столбца 5 строки 9001. Приложение передает это значение DataGrid.
5. DataGrid использует значение любым необходимым образом, например, отображает значение, как указано в шаге 1.

@RBrid написал:

Для сценариев без привязки к данным мы должны посмотреть, как элемент управления WinForms DataGridView, который я написал много лет назад, поддерживает виртуальный режим:

Да да да! Я никогда не использовал WinForms DataGridView, но я только что прочитал документацию и считаю, что вы попали в точку. На веб-странице, на которую вы ссылаетесь, написано:
_ "Виртуальный режим предназначен для использования с очень большими хранилищами данных." _

Я вижу, что WinForms DataGridViewCellValueEventArgs содержит следующие свойства:

public int RowIndex { get; }      // DataGrid sets RowIndex.
public int ColumnIndex { get; }   // DataGrid sets ColumnIndex.
public object Value { get; set; } // The app sets Value.

Это отлично, за исключением того, что в идеале он должен быть обновлен для поддержки современных ключевых слов C # async и await или эквивалента UWP ( IAsyncOperation<TResult> ), а точнее любой задержки по времени. между DataGrid, запрашивающим значение ячейки, и приложением, доставляющим значение ячейки в DataGrid. Таким образом, чтобы обновить его для поддержки асинхронного режима, сделайте следующее:

1. Сохраните событие CellValueNeeded .
2. Удалите свойство DataGridViewCellValueEventArgs.Value .
3. Создайте в DataGrid метод с именем типа SupplyCellValue который будет вызывать приложение, вместо того, чтобы требовать немедленно / синхронно установить свойство DataGridViewCellValueEventArgs.Value .

Метод SupplyCellValue можно определить так:

class DataGrid
{
    public void SupplyCellValue(int rowIndex, int columnIndex, object value);
    // Alternatively:
    public void SupplyCellValue(int rowIndex, DataGridColumn column, object value);
}

Таким образом, во время выполнения процедура выглядит так:

1. DataGrid решает, что ему необходимо отобразить (или иным образом использовать) значение, которое существует в столбце 5 строки 9001 во внешней системе хранения данных.
2. DataGrid запускает событие CellValueNeeded и устанавливает DataGridViewCellValueEventArgs.RowIndex равным 9001 и DataGridViewCellValueEventArgs.ColumnIndex равным 5.
3. Обработчик событий (приложение) запускает асинхронную задачу, которая извлекает значение для столбца 5 строки 9001.
4. Когда асинхронная задача завершается, то есть когда приложение получило значение, приложение вызывает метод DataGrid.SupplyCellValue .

Этот упрощенный метод более мощный и гибкий, чем интеллектуальный автоматизированный метод DataGridBoundColumn.Binding и DataGrid.ItemsSource .

@alexyak , не могли бы вы немного расшириться? Свойство SelectedItems в настоящее время позволяет вам получить все выбранные элементы в DataGrid (хотя и в режиме расширенного выбора, а не в режиме множественного выбора). Из нескольких других комментариев я вижу, что выбор в DataGrid определенно требует доработки, но я хочу лучше понять ваш запрос.

Нам нужна правильная двусторонняя привязка данных для моделей просмотра для управления множественным выбором.

@verelpode , мы смоделировали модель WinForms DataGridView после еще более старых элементов управления Win32 ComCtl32. В частности, я думаю о том, как элемент управления списком использовал сообщение LVN_GETDISPINFO в виртуальном режиме (см. Https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview # handle-virtual-list-view-control-notification-codes и https://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo). Старые вещи из 90-х.

В любом случае, я считаю, что аспект асинхронного извлечения данных следует обрабатывать через «отложенные события».
Элементы управления WinUI уже дважды используют отложенные события:

runtimeclass RefreshRequestedEventArgs
{
    Windows.Foundation.Deferral GetDeferral();
}

runtimeclass TeachingTipClosingEventArgs
{
    TeachingTipCloseReason Reason{ get; };
    Boolean Cancel;
    Windows.Foundation.Deferral GetDeferral();
}

Это шаблон, который хочет принять новое событие DataGrid CellValueNeeded. Это позволяет обработчику событий предоставлять данные асинхронно и сообщать элементу управления, когда он это делает. См. Https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferral.

@RBrid
Хорошее замечание о том, что GetDeferral() - это новый стандартный шаблон. В этом конкретном случае CellValueNeeded кажется намного сложнее использовать Deferral чем в других случаях / событиях. Поправьте меня, если я ошибаюсь, но я думаю, что проблема с использованием GetDeferral() в этом конкретном случае заключается в том, что GetDeferral() создает новый объект каждый раз, когда он вызывается, и это приведет к чрезмерному создание и очистка огромного количества объектов повторяются для каждой ячейки каждой строки потенциально большого количества строк. Я не видел исходный код различных реализаций GetDeferral() поэтому могу ошибаться в этом.

Другими словами, если Deferral поддерживает переработку или иным образом не имеет способа сделать GetDeferral() намного более эффективным, тогда это все равно слишком умно. Мое упрощенное предложение с методом SupplyCellValue позволяет избежать накладных расходов на создание, завершение и удаление нового экземпляра Deferral для каждой ячейки каждой применимой строки.

1. GetDeferral()
2. Отсрочка.
3. Отсрочка.
4. Повторите вышеуказанные шаги большое количество раз.

Получение значения ячейки - не единственная задача управления данными, которая может быть передана приложению на аутсорсинг. Сортировка также может быть передана на аутсорсинг. Поэтому, возможно, стоит подумать об интерфейсе, а не об одном событии CellValueNeeded . Приложение предоставит DataGrid модуль управления данными в виде объекта, реализующего определенный интерфейс. DataGrid будет вызывать этот интерфейс для получения значений ячеек, а также потенциально других задач, таких как сортировка.

Для поддержки миллиона строк, упомянутых @dotMorten , CellValueNeeded не решит другую проблему, которая возникает, когда пользователь щелкает заголовок столбца, а DataGrid пытается отсортировать миллион строк. Таким образом, извлечение ячеек и сортировка могут быть переданы приложению через вышеупомянутый модуль / интерфейс.

Если приложение не предоставляет какой-либо модуль / объект управления данными для DataGrid, то в идеале DataGrid будет использовать модуль управления данными по умолчанию. Таким образом, весь существующий код привязки данных в DataGrid будет перемещен из DataGrid в отдельный новый класс - класс, который реализует модуль управления данными по умолчанию, работая с DataGridBoundColumn.Binding и т. Д.

т.е. когда сортировка также передается на аутсорсинг приложению или его модулю управления данными, тогда это открывает дверь для различных решений, поддерживающих миллион строк, таких как написание модуля управления данными, который инструктирует SQL-сервер выполнять сортировку вместо того, чтобы пытаться: и - невозможность выполнить сортировку миллиона строк внутри DataGrid менее чем через 10 или 20 часов после того, как пользователь щелкнет заголовок столбца, чтобы начать сортировку.

@verelpode , да, это

Взяв зависимость от Windows Community Toolkit DataGrid, в которой есть сведения о строках в качестве функции (хотя и с серьезной ошибкой производительности, но с обходным путем), мы действительно хотели бы, чтобы эта новая сетка данных также имела эту функцию - с той же опцией. чтобы иметь одновременно несколько деталей строки. Использование его для сценария потоковой передачи данных от сервера к клиенту.

Re миллиона строк по сравнению с графическим интерфейсом подкачки, @robloo писал:

Я согласен, что [поддержка миллиона строк] тоже было бы неплохо. .... Тем не менее, в прошлом я просто генерировал новый DataTable, представляющий частичное представление полной базы данных для реализации разбиения на страницы (что является хорошим вариантом использования для этого). Затем для представления этого DataTable может быть установлено значение ItemsSource. Так что, хотя я определенно считаю, что это хорошо, это не кажется обязательным для высокой производительности.

Пейджинг - полезный метод, о котором стоит упомянуть, но он имеет существенные недостатки: он делает функцию сортировки DataGrid практически бесполезной. То же самое и с функцией фильтрации в следующей версии DataGrid. Пейджинг делает сортировку и фильтрацию бесполезными или, по крайней мере, менее полезными.

Например, представьте, что 2 или 3 столбца являются столбцами даты, и пользователь хочет просмотреть строки, которые имеют самую последнюю (или самую старую) дату во втором столбце даты. Таким образом, пользователь щелкает заголовок второго столбца даты, чтобы отсортировать DataGrid по этому столбцу, а также щелкает, чтобы изменить направление сортировки с убывания на возрастание или наоборот. Это отлично работает, если подкачка не используется или если общее количество строк достаточно мало, чтобы не превышать одну страницу, но он ломается, если существует несколько страниц.

Пользователь должен найти самую последнюю (или самую старую) дату во всех строках, но графический интерфейс DataGrid с разбивкой на страницы показывает только самую последнюю (или самую старую) дату на текущей странице, а не по всем строкам, поэтому разбиение по страницам делает сортировку (и фильтрацию) практически бесполезный.

Это поднимает вопрос, какие строки попадают на какую страницу. Ответ заключается в том, что каждая страница обычно содержит практически случайное подмножество строк, когда страницы / строки получены с помощью запроса SQL SELECT , который не использует ORDER BY . (Я имею в виду случайное с точки зрения пользователя, а не на самом деле случайное.)

Псевдослучайный метод бесполезен для конечных пользователей. Чтобы устранить эту проблематичную случайность, мы могли бы подумать об использовании SQL ORDER BY (вместе с ключевым словом ASC или DESC для управления направлением сортировки), и тогда да, страницы не более длинный случайный, но он все еще не работает, потому что при таком использовании ORDER BY всегда выполняется сортировка по одному и тому же столбцу и в одном направлении сортировки, что означает, что порядок сортировки часто отличается от порядка сортировки, выбранного конечным пользователем, щелкнув по столбцу заголовок в DataGrid.

Чтобы исправить это, вам нужно будет использовать другой SQL-запрос каждый раз, когда пользователь нажимает на другой заголовок столбца. SQL ORDER BY ... ASC/DESC должен быть таким же, как и любой порядок сортировки, выбранный конечным пользователем DataGrid. DataGrid в настоящее время не поддерживает это.

Предлагаемое решение содержится в моем предыдущем сообщении : я предлагал, чтобы DataGrid позволяла передавать сортировку на аутсорсинг приложению (или «модулю управления данными»). Эта идея позволит приложению (или «модулю управления данными») изменять SQL ORDER BY ... ASC/DESC всякий раз, когда конечный пользователь изменяет порядок сортировки DataGrid, щелкая заголовки столбцов и т. Д.

Также может быть целесообразно дать уже существующему событию DataGrid.Sorting настраиваемое свойство в аргументах события, которое позволяет приложениям (обработчику событий) отменять сортировку и переходить к выполнению. В идеале аргументы событий также должны указывать, было ли изменение порядка сортировки запрошено программно, а не запрошено ли конечным пользователем, щелкнув заголовки столбцов и т. Д. В этом случае также может помочь переименовать событие DataGrid.Sorting во что-то менее неоднозначное. потому что в настоящее время намерение и цель события Sorting неясны. См. Также предлагаемое событие SortOrderChanged в другом моем сообщении .

Взяв зависимость от DataGrid набора инструментов сообщества Windows, в котором есть строка
Детали как функцию (хотя и с серьезной ошибкой производительности, но с обходным путем), мы бы
мне очень нравится, что эта новая сетка данных также имеет эту функцию - с той же опцией, чтобы иметь
несколько деталей строки одновременно. Использование его для сценария потоковой передачи данных от сервера к клиенту.

Ссылка на проблему производительности Row Details: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2842
Реплика: https://github.com/observito/DataGridRowDetailsPerfTest

Хорошей отправной точкой является изучение вашего партнера Telerik с его RadDataGrid (UWP с открытым исходным кодом). Я использовал его с одним из моих клиентов, и он действительно хорошо работает. Он сверхбыстрый и универсальный. Единственное, что является сложным, это их код, нет возможности что-либо изменить из их движка без хорошего понимания архитектуры.

Я ожидал, что новый DataGrid будет таким же производительным, как и Telerik.

Возможности сетки syncfusion великолепны, но они не подходят для mvvm. Так что ты мог бы сделать лучше.

Привет всем снова! Давайте продолжим этот разговор. Что вы думаете о документации DataGrid, которая существует в настоящее время?

Вот ссылка на главную страницу документации, которая ведет на все другие соответствующие страницы.

Если мы создаем новый DataGrid, мы хотим быть уверенными, что сопровождающая его документация будет первоклассной, простой для понимания и затрагивает все проблемы и сценарии, которые важны для наших разработчиков.

_Какие темы вы хотели бы обсудить? Какие темы можно прояснить? _

Привет всем снова! Давайте продолжим этот разговор. Что вы думаете о документации DataGrid, которая существует в настоящее время?

Вот ссылка на главную страницу документации, которая ведет на все другие соответствующие страницы.

Если мы создаем новый DataGrid, мы хотим быть уверенными, что сопровождающая его документация будет первоклассной, простой для понимания и затрагивает все проблемы и сценарии, которые важны для наших разработчиков.

_Какие темы вы хотели бы обсудить? Какие темы можно прояснить? _

Были бы полезны изображения, показывающие типичные настройки DataGrid, а также xaml и код для их создания.

Были бы полезны изображения, показывающие типичные настройки DataGrid, а также xaml и код для их создания.

@mdtauk Существуют ли какие-либо конкретные настройки DataGrid, которые вы считаете «типичными», или варианты использования, в которых вы постоянно находите DataGrid лучшим выбором для использования?

Были бы полезны изображения, показывающие типичные настройки DataGrid, а также xaml и код для их создания.

@mdtauk Существуют ли какие-либо конкретные настройки DataGrid, которые вы считаете «типичными», или варианты использования, в которых вы постоянно находите DataGrid лучшим выбором для использования?

Я думаю, что это временные рамки WinUI 3.0, показывающие общие сценарии представления сетки / значков данных WPF, Win32. А также то, что Microsoft считает дизайном пользовательского интерфейса Fluent / Modern DataGrid.

То есть, если идея, лежащая в основе элемента управления, состоит в том, чтобы стимулировать переход от старых пользовательских интерфейсов к WinUI 3.

@anawishnoff Я думаю, что некоторые из вопросов, которые у нас возникли по

• Тематика / Повторный шаблон / Согласование
• Привязка данных (в целом и в XAML)
• Событие / Обработка выбора / Оболочка
• Редактирование поведения (особенно редактирование по щелчку)
• Многостраничный просмотр (который должен хорошо сочетаться с # 60 и # 268)
  
  
  
  • Координация загрузки анимации при загрузке данных
  
  
• Копировать / Вставить / Форматировать
• Различные типы данных столбца (и пользовательские) (например, перечисления)
• Контекстные меню
• Доступность

Я заметил, что существующему Toolkit DataGrid требуется IEnumerable для его свойства ItemsSource. Хотя это кажется логичным решением, оно делает невозможным установку объекта, возвращаемого Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector (), в качестве этого свойства. (Если нет способа привести возвращаемый объект). Кроме того, другие элементы управления, такие как ListView и GridView, поддерживают установку для своего свойства ItemsSource значения типа объекта. Я не уверен, но поддержка этого, вероятно, позволит более гибко реагировать на пользовательский интерфейс во время операций хранения.

@mdtauk Существуют ли какие-либо конкретные настройки DataGrid, которые вы считаете «типичными», или варианты использования, в которых вы постоянно находите DataGrid лучшим выбором для использования?

Я думаю, что это временные рамки WinUI 3.0, показывающие общие сценарии представления сетки / значков данных WPF, Win32. А также то, что Microsoft считает дизайном пользовательского интерфейса Fluent / Modern DataGrid.

То есть, если идея, лежащая в основе элемента управления, состоит в том, чтобы стимулировать переход от старых пользовательских интерфейсов к WinUI 3.

Пример Win32 (проводник)

Пример WPF

Пример Fabric Web

Пример UWP

@mdtauk Спасибо за эти скриншоты! Я определенно считаю важным выделить ключевые элементы, которые работали в предыдущих версиях элемента управления, и задокументировать, как их можно достичь с помощью нового элемента управления.

@ michael-hawker Замечательно. Я уже вижу там несколько тем, которые неоднократно поднимались в этой ветке, так что это определенно хорошее место для начала.

@ duke7553 Я не уверен на 100% в решении этой проблемы, или если поддержка типа объекта была бы разумной. Может быть, @RBrid сможет

@anawishnoff & @ duke7553 , я бы
Object ItemsSource { get; set; };

Надеюсь, он поддерживает CellDecorationStyleSelector, как в Telerik.

@anawishnoff

мы заинтересованы в том, чтобы преобразовать его в собственный элемент управления WinUI

хмммм, когда вы говорите "выпускной", будет ли это включать понижение версии до C ++? В настоящее время DataGrid WinUI написан на C #. Надеюсь, что «выпускник» не будет означать «понижение». Важно отметить, что WinUI должен достичь момента, когда команда WinUI сможет сказать, что WinUI лучше WPF во всех важных аспектах, но эта цель ужасно запоздала. Эта цель станет еще более назревшей, если время / ресурсы будут потрачены на ненужное понижение версии кода, такого как DataGrid, с C # на C ++.

Хотя изначально существовала причина для написания WinRT / UWP / WinUI на C ++, к сожалению, эта причина не реализовалась, и Google / Android заняли большую часть рынка смартфонов, поэтому первоначальная причина использования C ++ больше не применима (легко сказал задним числом, но не так-то просто сказать раньше). Если бы WinUI с самого начала был написан на C #, то цель «лучше, чем WPF» была бы достигнута 3 года назад, но сейчас прошло 8 лет, и она все еще не достигнута, и никто не может точно сказать, когда цель будет достигнута. Будем надеяться, что достижение цели «лучше, чем WPF» и «выпускных» целей WinUI DataGrid не будут отложены из-за ненужного преобразования на более старый и менее производительный язык программирования.

Я предвзято отношусь к C ++, потому что я начал программировать на C ++ до того, как C # вообще существовал, и люди предпочитают придерживаться того, чему они изначально научились, и с любовью вспоминают _ "старые добрые времена" _. Несмотря на мою предвзятость в пользу C ++, я перестал писать C ++ и считаю, что DataGrid не следует понижать до C ++ и откладывать. Оставьте это как C # и сосредоточьтесь на более важных вещах, таких как внесение различных улучшений, предложенных людьми в этом выпуске, и достижение цели лучше, чем WPF, до достижения 1 десятилетия.

Мне нравятся многие аспекты WinUI, и я ценю множество умных улучшений в нем, и я пишу код приложения для WinUI, но вы хотите знать правду? По правде говоря, к сожалению, я еще не выпустил ни одного приложения WinUI для пользователей. Программное обеспечение, выпущенное для пользователей, написано с использованием WPF, и пользователям все равно, потому что программное обеспечение работает хорошо и включает в себя модернизацию графического интерфейса. Хотя я написал целую кучу кода приложения для WinUI, все это подготовка, планирование, тестирование, ожидание, которые на самом деле не используются пользователями. Надеюсь, в следующем году первый компонент WinUI будет выпущен для пользователей, но я буду признателен за этот переход гораздо больше, чем они. Если все пойдет по плану, пользователи вряд ли заметят переключение.

С точки зрения Microsoft WinRT / UWP - это готовое к выпуску программное обеспечение, публикуемое для пользователей с 2012 года, но, с моей точки зрения, UWP все еще остается большим экспериментом. Для меня UWP (включая WinUI) - это большая версия для бета-тестирования, с которой я играл в течение многих лет.

В течение первых нескольких лет UWP каждый год я думал: _ "эээ ... Я подожду до следующего года. В WPF все еще слишком много вещей, которых не хватает в UWP. Конечно, следующий год будет лучше." _
Затем наступил следующий год, и я повторил ту же мысль. Затем наступил следующий год, и я повторил ту же мысль. Надеюсь, этот год - последний год, когда я говорю об этом, или, по крайней мере, это мое намерение.

WinUI не может позволить себе больше задержек. Оставьте DataGrid WinUI как код C #. Начните писать больше кода WinUI на C #, чтобы повысить производительность. Прошло 8 лет, и Android завоевал огромную долю рынка. Это серьезная ситуация.

Кстати, на самом деле я был милым / щедрым, когда сказал, что UWP все еще является бета-версией, потому что технически UWP соответствует определению альфа-версии, а не бета-версии. Чтобы быть настоящей бета-версией, она должна быть полнофункциональной, но UWP еще не достигла статуса полной функциональности, поэтому UWP все еще является альфа-версией. Например, в статье Википедии «Жизненный цикл выпуска программного обеспечения» говорится:

«Бета-фаза обычно начинается, когда программное обеспечение имеет полную функциональность, но может содержать ряд известных или неизвестных ошибок».
«Альфа-версия программного обеспечения может не содержать всех функций, которые запланированы для окончательной версии».

Википедия определяет «функция завершена» следующим образом:

«В полной версии программного обеспечения реализованы все запланированные или основные функции, но она еще не является окончательной из-за ошибок, проблем с производительностью или стабильностью. Это происходит в конце альфа-тестирования разработки».

Было бы неразумно описывать UWP как полнофункциональный, потому что, если он действительно полнофункциональный, тогда UWP должен иметь все возможности Windows 95 и многое другое, но это не так - UWP пока не превосходит Windows 95 во всех областях. . Windows 95 была выпущена 25 лет назад. Когда 7–8 лет назад был выпущен UWP / WinRT, Microsoft понесла убытки в размере 900 миллионов долларов и острую нехватку приложений в Магазине Windows. Это была альфа-версия, обозначенная как релизная, поэтому разработчики приложений ждали и наблюдали. Сегодня, почти 8 лет спустя, это все еще альфа-версия и очень просроченная, и я все еще жду, смотрю и жду.

Для Microsoft и разработчиков было бы очень выгодно, если бы Microsoft примет серьезное решение / обязательство расставить приоритеты в производстве настоящей бета-версии UWP, за которой быстро последует настоящая версия Release Candidate. Это было бы очень рекомендуется и очень разумный курс действий. Было бы отлично для всех.

UWP все еще является альфа / неполным по нескольким причинам, например: 25 лет назад в Windows 95 было легко использовать функцию «MoveFile» для перемещения файла или папки (хотя функция называлась «MoveFile», она поддерживала оба файла. и папки). Может ли UWP перемещать папки? Нет, не сейчас. Очевидно, что возможность перемещать папки является одной из основных основных важных функций, но в UWP все еще отсутствует эта важная функция и другие, поэтому было бы неразумно описывать UWP как полнофункциональную, поэтому UWP еще не достиг статуса бета-версии, несмотря на выпущен 7-8 лет назад. Microsoft необходимо отдать приоритет истинной бета-версии UWP.

Насколько мне известно, общедоступного репозитория GitHub для отслеживания проблем UWP (кроме проблем с пользовательским интерфейсом) еще не существует (или, если репозиторий UWP существует, я не смог его найти). Опять же, это соответствует определению альфа-версии, потому что публичное репо для отслеживания проблем часто нежелательно во время альфа-стадии. Если бы это была настоящая бета-версия или релизная версия, то уже было бы открыто общедоступное хранилище для отслеживания проблем, а UWP включал бы все функции Windows 95, Windows 7 и многое другое.

Как эта ситуация влияет на DataGrid ? Учитывая, что полнофункциональная бета-версия UWP так ужасно просрочена, и учитывая серьезность этой ситуации и многомиллиардные убытки, понесенные в результате Microsoft, было бы неоправданно и разумно тратить еще больше времени путем преобразования WinUI DataGrid в неуправляемый код и более старый язык программирования. Microsoft неоднократно заявляла, что большим преимуществом C # и «управляемого кода» является повышенная производительность, и я могу сказать, что утверждения Microsoft об «управляемом коде» определенно были верны в моем опыте работы как с C ++, так и с C #. UWP достигла бы истинного статуса бета-версии несколько лет назад, если бы в основном была написана с использованием управляемого кода, начиная с версии 1.0. Так что я надеюсь, что ситуация не станет еще хуже, если выполнить еще больше этих ненужных переходов с управляемого кода на неуправляемый.

Для сравнения: большая часть WPF была успешно завершена за 4 года с 2006 по 2010 год. WPF - это в первую очередь управляемый код, в отличие от UWP. UWP - это неуправляемый код, и после 8 лет разработки Windows 95 по-прежнему превосходит UWP в нескольких областях, поэтому Microsoft была явно права, когда Microsoft заявила, что управляемый код увеличивает производительность. Эту проблему нужно решить как можно скорее. WinUI должно было быть намного проще / быстрее создать, чем WPF, потому что оба проекта имеют одного и того же владельца (Microsoft), поэтому WinUI может свободно копировать код из WPF. Таким образом, WinUI должен был занять примерно половину времени разработки WPF. На самом деле WinUI никогда не должен был запускаться, скорее Microsoft должна была разработать функции WinUI в новых версиях WPF - WinUI должен был быть WPF 5.0. Таким образом, ситуация представляла собой большой беспорядок, и для Microsoft было бы очень полезно уделить первоочередное внимание оставшейся очистке этого беспорядка и прекратить делать вещи, которые делают многомиллиардную ошибку еще хуже, чем она была ранее (и все еще остается, когда вы смотрите при сегодняшней ситуации на рынке смартфонов).

Это означает, что для предотвращения еще больших потерь Microsoft будет полезно помнить то, что Microsoft уже говорила / знала в прошлом:

• Согласно собственным заявлениям Microsoft, управляемый код увеличивает производительность. Если сравнить 8 лет работы UWP с 4 годами работы WPF, можно сделать вывод, что Microsoft была права в отношении преимуществ управляемого кода.
• Языки сценариев предназначены для написания сценариев, а языки программирования - для программирования. JavaScript и PowerShell хороши по своему прямому назначению (сценарии), но они явно не подходят для программирования приложений.
• Чтобы добиться успеха, Microsoft должна перейти от альфа-версии к бета-версии для выпуска, и это будет успешным только в том случае, если это настоящая окончательная версия, а не неполная альфа-версия, помеченная как «выпуск». Таким образом, Microsoft Store в течение слишком долгого времени был в основном пуст.
• Инженеры-программисты и другие сотрудники работают лучше всего, когда они работают за разумное вознаграждение, разумное количество рабочих часов и здоровую рабочую среду. Очевидно, многомиллиардные убытки Microsoft никогда не будут компенсированы использованием неоплачиваемых фанатиков / фанатиков и их так называемой «дневной работы» и «ночной работы» и их неустойчивых / нездоровых условий труда.
• Огромный успех Android на рынке произошел не благодаря неоплачиваемым фанатикам. Если бы причиной победы были бесплатные фанатики, то Linux не потерпел бы поражения. Объяснение намного проще: планшеты и смартфоны Android стоят НАМНОГО ниже, чем планшеты и смартфоны на Windows. Очевидно, что конечных пользователей не волнуют религии / идеология «открытого исходного кода» (пользователи даже не знают, что это такое), им просто нравятся низкие цены на устройства Android.
• Win16 крайне устарела. Это технология, появившаяся 20–30 лет назад, с первых дней «Дикого Запада» программирования. Поэтому перестаньте писать новый код на базе Win16. Название «Win32» на самом деле не меняет того факта, что это по-прежнему принципиально Win16. Win32 - это то же самое, что и Win16, за исключением того, что размер указателей увеличен с 16 до 32 бит. Слишком много групп в Microsoft продолжают писать новый код на основе Win16 / 32. Это очень неэффективно и большая трата ресурсов.

@anawishnoff

мы заинтересованы в том, чтобы преобразовать его в собственный элемент управления WinUI

См. Также статью в Википедии «Невосполненные затраты» :

Эффект невозвратных затрат (или эффект Конкорда) - это тот факт, что поведение часто следует за ошибкой невозвратных затрат; люди демонстрируют «большую тенденцию продолжать дело после того, как были вложены деньги, усилия или время». Такое поведение можно описать как «бросать хорошие деньги за плохими», а отказ поддаться этому можно описать как «сокращение своих потерь».

И аналогично «Предвзятость продолжения плана» :

Предвзятость в отношении продолжения плана, стремление к достижению цели или настойчивость - неблагоразумная тенденция настаивать на неудачном плане. Это опасно для капитанов судов или пилотов самолетов, которые могут придерживаться запланированного курса, даже если это ведет к фатальной катастрофе, и вместо этого они должны прервать движение. ..... Проекты часто страдают перерасходом средств и задержками из-за ошибки планирования и связанных с этим факторов, включая чрезмерный оптимизм, нежелание признать провал, групповое мышление и неприятие потери невозвратных затрат.

WinRT / UWP привел к тому, что Microsoft понесла убытки в размере 900 миллионов долларов в первый или второй год и слишком долго оставалась пустым магазином приложений. WinRT / UWP потерпел катастрофический отказ, поэтому его следовало прервать на второй год, но он был продолжен из-за «систематической ошибки продолжения плана» и нежелания потерять невозвратные затраты. Этому учат на курсах менеджмента. Сняло ли в конечном итоге продолжение плана катастрофический сбой WinRT / UWP или обратил его вспять? Нет, сегодня это катастрофический провал, если посмотреть на долю рынка смартфонов. Эти описания в Википедии точно описывают ситуацию с UWP.

Сегодня мы все должны согласиться с тем, что в настоящий момент, через 7-8 лет после выпуска WinRT / UWP, уже слишком поздно отменять UWP, но это означает, что мы снова становимся жертвой «предвзятости продолжения плана» "и неприятие потери невозвратных затрат.

Так что же можно разумно сделать, чтобы спасти ситуацию? Мы не можем спасти ситуацию, отменив UWP, хотя его определенно следовало отменить много лет назад. Что мы можем сделать, так это: принять гигантский ущерб, нанесенный WinRT, но не причинять никакого дальнейшего ущерба, и внести изменения в процедуры / политики проекта. Это означает, что перестаньте повторять / продолжать одни и те же катастрофические ошибки WinRT. Например, прекратите понижать уровень такого большого количества управляемого кода до непродуктивного старого неуправляемого «собственного» кода. Задержка в достижении настоящего бета-статуса уже очень велика - зачем еще больше усугублять задержку?

Ошибка «Предвзятость продолжения плана» / невозвратных затрат сохраняется, если DataGrid переведен на неуправляемый «собственный» код. Когда совершается катастрофическая ошибка, такая как WinRT / UWP, становится намного хуже, когда эта же ошибка повторяется снова и снова и снова. Чтобы ограничить урон, нужно перестать повторять одну и ту же ошибку. Настало время извлечь уроки из катастрофического отказа WinRT и начать накладывать повязки, чтобы остановить продолжающуюся кровопотерю.

Преобразование DataGrid в неуправляемый код - это то же самое, что пойти в библиотеку и позаимствовать все лучшие книги по управлению проектами у лучших авторов с наибольшими знаниями / опытом, а затем бросить все эти прекрасные книги по управлению в костер и наблюдать, как они горят.

@verelpode Мне любопытно, что вы

@dotMorten - причина, по которой я написал дополнительные подробности в этих сообщениях, заключается в том, что, если я не объясню проблему адекватно, люди ее не поймут. Но, к сожалению, теперь я вижу, что дополнительная деталь не удалась, и все равно ее все равно не поняли. Это очень расстраивает. Это причина, по которой многие люди даже не утруждают себя написанием отзывов, потому что они считают, что бессмысленно пытаться объяснять людям подобные проблемы, и даже если сообщение успешно понято, человеческая природа - стрелять в человек, который сообщает плохие новости, поэтому лучше вообще ничего не говорить или просто «вежливо» улыбнуться, думая об обратном.

так как он становится полностью свободным от этого с v3.

Эта привязка v3 не предотвращает повторение одних и тех же ошибок. «Предвзятость продолжения плана» все еще существует.

Перейдите на домашнюю страницу Microsoft:
https://www.microsoft.com/en-us/
Теперь прокрутите домашнюю страницу вниз, пока не увидите Windows Phone. Ой! Посмотри на это! Мы достигли конца домашней страницы, и Windows Phone нигде не упоминается на главной странице Microsoft! Что это значит? Значит, проснись. Это означает, что UWP, как я уже сказал, потерпела катастрофический провал. Это означает, что важно перестать повторять те же ошибки, которые привели к сбою UWP. Это означает, что нужно изменить план, чтобы спастись и восстановиться после стихийного бедствия.
Было бы ошибкой руководства, если бы WinUI и DataGrid продолжали повторять те же ошибки, что и в случае отказа UWP.

«В мае 2016 года Microsoft распотрошила свой мобильный бизнес ... В 2017 году исполнительный директор Microsoft Джо Бельфиоре сообщил, что Microsoft прекратила разработку новых телефонов Windows и новых функций для Windows 10 Mobile, сославшись на потерю доли рынка и отсутствие разработка приложений ".
- https://en.wikipedia.org/wiki/Microsoft_Mobile

Ана перечисляет 5 пунктов, по которым следует оставить отзыв о DataGrid. Какие из этих моментов вы комментируете? Думаю, этого я не понимаю из того, что вы пишете. UWP не удовлетворяет потребности всех, но WinUI3 не требует использования модели приложения UWP, и, кажется, вы в основном против UWP? Так что у вас должно быть все в порядке.

Вы упомянули, что DataGrid не должен продолжать делать те же ошибки, что и он. Итак, какие именно ошибки связаны с существующим DataGrid и как вы предлагаете их исправить? (кроме того, что вы не хотите, чтобы это было реализовано на C ++ по какой-то причине)

@dotMorten

Ана перечисляет 5 пунктов, по которым следует оставить отзыв о DataGrid. Какие из этих моментов вы комментируете?

Часть, где я процитировал Ану в начале своего сообщения. Я комментирую часть сообщения Аны, которую я процитировал в начале своего сообщения.

WinUI3 не требует использования модели приложения UWP

Это не имеет отношения к моему сообщению. Несвязанность WinUI 3 и доступность через пакет nuget не имеет отношения к вопросу о том, продолжает ли WinUI 3 те же ошибки управления, которые привели к провалу UWP и Windows Phone, а также к многомиллиардным убыткам Microsoft.

как вы предлагаете их исправить?

6 пунктов в конце моего предыдущего сообщения . Второй пункт (сценарии) относится к WinUI и UWP в целом, но не относится к DataGrid. Первый пункт - самый важный, если вы спрашиваете конкретно о DataGrid.
Я также написал: прекратите понижать такие большие объемы управляемого кода до непродуктивного старого неуправляемого «собственного» кода. Задержка в достижении настоящего бета-статуса уже очень велика - зачем еще больше усугублять задержку?

@anawishnoff написал:

мы заинтересованы в том, чтобы преобразовать его в собственный элемент управления WinUI

«переход на собственный элемент управления WinUI» представляет собой практически продолжение / повторение некоторых из тех же ошибок, которые привели к «потере доли рынка и отсутствию разработки приложений», упомянутым в Википедии:

«В мае 2016 года Microsoft распотрошила свой мобильный бизнес ... В 2017 году исполнительный директор Microsoft Джо Бельфиоре сообщил, что Microsoft прекратила разработку новых телефонов Windows и новых функций для Windows 10 Mobile, сославшись на потерю доли рынка и отсутствие разработка приложений ".
- https://en.wikipedia.org/wiki/Microsoft_Mobile

Почему DataGrid следует продолжать идти по тому же пути, который разрушил мобильный бизнес Microsoft?

@verelpode

WinUI 3 продолжает те же ошибки управления, которые привели к провалу UWP и Windows Phone, а также к многомиллиардным убыткам Microsoft.

Я не работаю в Microsoft, но мне любопытно, почему вы говорите, что WinUI допускает ошибки управления.
Из того, что я вижу, сам факт того, что исходный код WinUI открыт и каждый может участвовать в обсуждениях и принятии решений, на самом деле помогает определить, что такое WinUI, и должен предотвращать ошибки.
Вы упомянули, что DataGrid продолжает идти тем же путем, что и мобильные устройства, но я нигде не видел упоминания мобильных устройств. Возможно, вы сможете оставить отзыв непосредственно о том, что обсуждается в этом вопросе.
Если вы чувствуете, что в WinUI есть неправильное управление, то, возможно, вы можете создать отдельную проблему со своими проблемами, но я действительно не думаю, что ваши комментарии имеют какое-либо отношение к элементу управления DataGrid.

@verelpode, пожалуйста, оставьте здесь свой отзыв по теме. Если у вас есть сомнения по поводу WinUI или UWP в целом, начните новую тему обсуждения или свяжитесь со мной напрямую (напишите мне или DM в твиттере). Или вы можете обсудить уже существующую тему, например, # 717 или # 1531.

Вы поделились опасениями по поводу переписывания DataGrid на C ++, но на самом деле в первоначальном предложении об этом ничего не говорилось. @anawishnoff пытается собрать отзывы о наборе функций DataGrid. С точки зрения реализации, если имеет смысл сохранить его на C #, мы бы это сделали (и его все равно можно было бы вызывать из C ++, если бы мы делали это как компонент WinRT).

@jevansaks - Мой отзыв был по теме, но человеческая природа стрелять в мессенджера, доставляющего плохие новости. Ваш ответ меня огорчает и разочаровывает. Хорошо, я перестану пытаться помочь, потому что моя помощь нежелательна, потому что она слишком честная и прямая и затрагивает болезненные вопросы, которые слишком болезненно осознавать и решать (катастрофический отказ WinRT вызывает слишком много эмоций, и поэтому их легче стереть это по памяти и продолжить тот же старый исходный план WinRT, как будто катастрофы даже не было). Я выйду из этого обсуждения и больше не буду участвовать в разработке DataGrid, потому что продолжение откровенного и откровенного разговора о реальных проблемах будет только раздражать людей.

@verelpode Здесь никто не «стрелял в посыльного, доставляющего плохие новости». @jevansaks предложил вам открыть новый выпуск, чтобы поделиться своими опасениями по поводу UWP / WinUI / WinRT в этом репозитории. Эта проблема действительно касается только DataGrid, и хотя действительно одна из ваших проблем была связана с DataGrid, подавляющее большинство касалось UWP / WinUI / WinRT в целом. Я уверен, что если вы еще раз взглянете на это обсуждение, вы увидите, что команда WinUI просто просит вас сосредоточить эту проблему исключительно на предложении DataGrid и открыть новую / использовать существующую проблему для решения ваших более широких проблем по поводу Платформа.

Обеспокоенность, о которой вы упомянули, может стать основой для интересного обсуждения с участием как команды WinUI, так и сообщества, но этот конкретный вопрос не подходит для такого обсуждения.

@anawishnoff
Я почти уверен, что элемент управления Microsoft Pivot Viewer Control не был HTML. Пожалуйста, посмотри на это снова. Возможность визуализировать большие наборы данных с использованием чего-то подобного - это то, чем мы иногда хотели заниматься. Думаю, он был доступен в Silverlight. https://www.microsoft.com/silverlight/pivotviewer/default# Он использовал Deep Zoom для его функциональности. Добавление возможности Deep Zoom в WinUI 3.0 было бы потрясающе! Не совсем Datagrid, а элемент управления отображением данных. Есть много «заброшенных» идей из первых дней WPF, таких как Deep Zoom, которые так и не вошли в производственный элемент управления WPF, который было бы замечательно со временем вернуть к жизни в WinUI 3.0. Черт возьми, вытащите доктора WPF из подвала и заставьте его снова писать !!! Нам нужно его вернуть. Нам нужно начать движение. ВЕРНИТЕ Dr. WPF !!!!! Куда ты пропал? Доктор WinUI !!!

@PaulMontgomerySP звучит так, как будто вам следует открыть новый выпуск, чтобы обсудить элемент управления Pivot. Не стесняйтесь ссылаться на предыдущее обсуждение этого в Windows Community Toolkit здесь: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/770

Событие изменения выбора срабатывает для каждой строки, к которой я перехожу с клавиатуры.
Было бы неплохо иметь событие исключительно для щелчка мыши или касания ячейки, а не только для события изменения выбора.

Событие изменения выбора запускается как для щелчка, так и для клавиатуры. Было бы очень полезно иметь событие исключительно для щелчка.

@ Going-Gone Мне любопытно, как это можно использовать? Зачем нужно знать разницу? Также вы не можете использовать событие с нажатием?

Одно ограничение, с которым я столкнулся с DataGrid из UWP Toolkit, - это то, что DataGridTemplateColumn имеет CellTemplate, но не имеет CellTemplateSelector (и то же самое отсутствует для CellEditingTemplate ). Это упростило бы адаптацию пользовательского интерфейса в каждой ячейке к данным, используя подход селектора, вместо того, чтобы делать это с дополнительным уровнем элементов управления пользовательского интерфейса под ним, чтобы справиться с этим.

Также сделайте возможным выбирать строки не только в последовательном порядке, как я подробно объяснил здесь:
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

Ни в каком конкретном порядке вещей, которые клиенты часто просят поддерживать сетку.

1. Возможность сохранять, загружать и строить фильтры. Например, фильтровать по выражению linq, фильтровать по запросу SQL, фильтровать по дереву выражений и наоборот. Пример - https://querybuilder.js.org/demo.html

1. Высокая скорость передачи данных в реальном времени, производительность имеет значение. Частота обновления менее 1 мс для торгового приложения по сравнению с более чем 1 миллионом строк имеет разные соображения по производительности.
2. Возможность указать порядок сортировки, например i. сортировка по высокой / низкой, ii. сортировка по низкой / высокой и iii. нет вида или я. сортировка по низкой / высокой, ii. сортировка по высокой / низкой и iii. нет вида
3. Фильтрация в стиле Excel
4. Возможность применять CSS-форматирование к ячейкам, условное форматирование
5. Возможность легко сохранять / загружать настройки сетки, например фильтры, ширину столбцов, сортировку и т. Д.
6. Прокрутка работает, например, не сбрасывается после обновления данных, плавная.
7. События сбора данных должны иметь возможность запускать события после загрузки диапазонов, а не отдельных объектов. Например, я считаю, что ObservableCollection требует подкласса для предотвращения срабатывания INotifyPropertyChange для каждого добавленного отдельного объекта.
8. Лучшие события, когда данные загружаются / загружаются, загрузка данных началась, загрузка данных, загрузка данных, особенно при использовании асинхронной загрузки.
9. Сетки часто связаны с другими элементами управления, такими как фильтры данных, выбор диапазона, кросс-фильтр (например, https://github.com/dc-js/dc.js), диаграммы, сводные таблицы и т. Д.
10. Интеллектуальная сортировка, которая обрабатывает буквенно-цифровые данные, например порядок сортировки ABC11, ABC12, ABC111 вместо ABC11, ABC111, ABC12
11. Неограниченные уровни иерархических сеток, например https://docs.telerik.com/devtools/wpf/controls/radgridview/hierarchical-gridview/hierachy-overview

Полезные ресурсы: - Создавайте лучшие таблицы данных
https://news.ycombinator.com/item?id=21460966
https://uxdesign.cc/design-better-data-tables-4ecc99d23356

Я не смогу выполнить привязку к Columwidth напрямую из заголовка. В WPF в этом случае я должен использовать объект BindingProxy.

Удобное динамическое изменение размера активной строки для упрощения редактирования.
Полный контроль над контекстными меню в режиме редактирования.

Надеюсь, он поддерживает CellDecorationStyleSelector, как в Telerik.

Доступность!
Упоминание об этом, чтобы он был задокументирован, но этот элемент управления должен быть полностью доступен.
Текущая версия набора инструментов имеет некоторые ограничения в этой области: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3400 и https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079
Кроме того, хотя Telerik RadDataGrid имеет несколько замечательных функций, похоже, что он не поддерживает специальные возможности .

С большим толчком Microsoft к D&I я удивлен, что потребность в полной доступности всех элементов управления не указывается как требование повсюду.

Возможно, это уже возможно, и я просто не знаю, как этого добиться ... но как насчет пользовательского стиля строки или ячейки?

Возможность настроить таргетинг на конкретную строку, изменить фон и цвет текста была бы замечательной.

По сравнению с WCT UWP DataGrid:
1) Производительность
2) Больше встроенных типов столбцов (я предполагаю, что они имеют лучшую производительность, чем столбцы шаблонов)
3) Возможность привязать события мыши к ячейке, то есть касание, касание правой кнопкой мыши и наведение (или указатель вниз или что-то еще)
4) События клавиатуры на ячейку
5) Если (3) не работает, мы могли бы эмулировать, если бы у нас была функция проверки нажатия
6) Производительность

Сколько людей возразят, если WinUI DataGrid откажется от функции, позволяющей конечным пользователям редактировать значения ячеек прямо или непосредственно внутри DataGrid?

Кто-нибудь помнит VB6? VB6 DataGrid изначально поддерживает Edit, Delete и AddNew. Добавить было доступно как пустая строка, автоматически добавляемая в конец списка. Заполните строку, появится еще одна пустая строка.

DataGrid должен иметь возможность поддерживать ввод данных, даже если большинство разработчиков предпочитают отключать эту функцию по умолчанию.

При переносе приложения VB6 на UWP нам пришлось написать собственную сетку данных для поддержки добавления / редактирования / удаления.

Кажется, что большинство, кто вносит здесь свой вклад, - это люди WPF / Xaml, это стоит два цента от кого-то, кто не является парнем по xaml.

Я часто использую элементы управления DataGrid в своем программном обеспечении. Монтаж - это место, важно! Вот некоторые из моих пожеланий / болевых точек:

1. Возможность настройки контекстного меню в режиме редактирования.
2. Лучшая производительность и больший контроль при автоматическом изменении размера столбцов. Я хочу, чтобы пользователь мог контролировать размеры, если это необходимо, но в большинстве случаев это не нужно. Я не хочу, чтобы размеры столбцов постоянно менялись, но я хочу, чтобы они каким-то образом основывались на данных без необходимости измерять объем данных в миллион строк.
3. При редактировании я хочу иметь возможность нажимать другой элемент управления / кнопку, которая что-то делает с редактируемыми данными (или с ними), не завершая редактирование. (В этом было бы меньше необходимости, если бы был реализован №1 - хотя все еще полезно.)
4. текущий способ обработки исключений с помощью события DataError грубый. (Извините, у меня возникли проблемы с конкретизацией этого вопроса, но я знаю, что в прошлом это несколько раз причиняло мне боль.)
5. Было бы неплохо встроить возможность автоматической прокрутки: http://stackoverflow.com/questions/2567809/how-to-autoscroll-a-datagridview-during-drag-and-drop
6. Возможность отображения «водяного знака», указывающего, когда данные «грязные» (см. BetterGrid для некоторых дополнительных полезных улучшений для DataGridView.
7. Возможность покинуть строку (без ошибки проверки), когда необходимая «ключевая» ячейка остается пустой.
8. Встроенная возможность не отображать изображение (вместо красного X) для строки, добавленной пользователем. См. Https://stackoverflow.com/questions/937919/datagridviewimagecolumn-red-x
9. Разрешить немедленную фиксацию столбца флажка при изменении: https://stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

Когда ожидается релиз альфа-версии? Будет ли он открыт для взносов? Пытаюсь отказаться от устаревшей сетки данных и очень жду этого, особенно функции виртуализации.

Извините за очень поздний ввод в эту ветку, но для меня это «ново»;)
_отредактировано после того, как узнал немного больше о поведении элемента управления_

Работая с DataGrid над созданием интерфейса для облачных накопителей, похожего на проводник, я обнаружил, что определение строки и ячейки, которые были задействованы, может быть немного сложнее, чем должно быть (ИМХО)

В дизайне моего приложения строки представляют файлы или папки (DriveItems). В подробном представлении отображается более подробная информация об элементе.

Я хотел создать возможность щелкать элемент папки, а интерфейс перепрыгивать и создавать список этих элементов, позволяющий перемещаться по диску.

Например, если я нажму на запись в столбце «Родительский» элемента, здесь /drive/root:/Documents/Vital%20Documents , интерфейс будет сброшен на эту папку и перечислит файлы в ней.

Хотя можно получить событие clicked для ячейки, у этого события, похоже, нет контекста для обработчика, чтобы определить ячейку, которая была затронута (строка, да, но не столбец), и я не уверен, что в настоящее время контроль позволил бы мне иметь как поведение касания ячейки, так и поведение автоматически открываемых деталей (все еще исследуя то, что я мог бы назвать "хаками", которые позволили бы это, но мы должны напомнить себе, что когда дизайнеры начинают отменять нормальное функционирование элемента управления, особенно не задокументированное поведение, они рискуют нарушить дизайн из-за изменений в поведении элемента управления.

Все это говорит о том, что DataGrid, похоже, поддерживает мой сценарий, имея событие, которое в настоящее время возвращает DriveItem как CurrentItem, также должно включать CurrentColumn , который будет всем объектом DataGridColumn который был нажат внутри, через из которого можно было бы извлечь имя столбца. Теперь я понимаю, что у нас есть объект CurrentColumn, который мы можем исследовать по событию, поэтому, хотя мне бы хотелось, чтобы это было лучше в качестве аргументов события, это должно сработать.

Кроме того, более строгий контроль поведения деталей может заключаться в том, что детали будут разворачиваться автоматически только при нажатии на один конкретный столбец, а не при каждом щелчке в любом месте строки.

Возможно, базовый класс объекта DataGridColumn может иметь свойство ExpandDetails , которому по умолчанию может быть присвоено значение true для каждого столбца, что будет означать, что этот конкретный столбец, по которому выполняется щелчок, вызывает расширение строки. Других, у которых свойство является ложным, не будет.

В моем дизайне, например, первый столбец - это тип элемента, как в «Файл» или «Папка», или «Изображение» или «Фото», «Аудио» и т. Д. Я мог бы представить, чтобы этот столбец был единственным, вызывающим автоматическое расширение, а затем щелчок по столбцу «Путь» может вызвать описанное выше поведение «получить список этого пути».

Что касается сортировки, то логически важно реализовать достаточный контроль, чтобы позволить дизайнерам получить многоуровневую сортировку. Я не проводил исследования, чтобы определить, как текущий элемент управления может поддерживать это посредством перехвата / переопределения событий и обратных вызовов, но это не выглядит однозначным.

Наконец, я знаю, что вы хорошо об этом знаете, но (даже если я прошу о большей функциональности), давайте, ПОЖАЛУЙСТА, не пытайтесь добавить кучу сложных поведений, которые пользователи могут реализовать сами поверх DataGrid. Среди них, которые я бы не реализовал в DataGrid, есть те, которые связаны с внешним хранением фильтров или сортировок и т. Д. Я бы также избегал превращения этого элемента управления в клон Excel.

-Спасибо, отличная работа!
-e

Прикрепленные группы: при просмотре наборов данных с большими группами должен быть контекст о том, какая группа (или группы, например, навигационная цепочка) просматривается. Это кажется важной функцией удобства использования для всех иерархических представлений на основе списков: представлений сгруппированных списков, таблиц данных и древовидных представлений.

Я бы построил новый элемент управления DataGrid поверх нового элемента управления WinUI ItemsRepeater. И этот элемент управления предоставляет свой ItemsSource как объект:
Object ItemsSource { get; set; };

@RBrid Вернемся к этому ~ год спустя. Я понял, что ItemsRepeater, хотя и имеет объект ItemsSource, на самом деле не имеет встроенной поддержки следующих интерфейсов, необходимых для работы с виртуализированными источниками данных:

• ISupportIncrementalLoading
• IItemsRangeInfo
• ISelectionInfo

-Как насчет того, чтобы получить там MVP, чтобы мы могли использовать Datagrid из C ++.