Más modos de visualización. Eche un vistazo al Explorador de archivos y sus vistas de iconos. El DataGrid debería poder mostrar íconos / elementos en una cuadrícula con agrupación, así como las filas y columnas encabezadas.

Sé que esto puede no ser posible o fuera de alcance, pero es un aspecto de WinUI vs Win32 que no es tan fácil como 1: 1, y una versión moderna del Explorador de archivos, o los cuadros de diálogo de archivos comunes, pueden necesitar de tal control. Este podría ser ese control, no un control personalizado interno.

Mi lista de deseos: para mí, una buena cuadrícula de datos incluye todas las características siguientes de forma predeterminada. Estoy tomando prestadas algunas capturas de pantalla del mundo html.

Filtre fácilmente toda la página con el recuento de filas preferido.

Seleccionar / anular la selección de columnas visibles, clasificación de columnas, copiar, imprimir

Exportar datos a un formato específico.

Reordenación de columnas arrastrando la columna.

Filtrado de columnas

Encabezado fijo: donde el encabezado permanece en la parte superior incluso cuando se desplaza

Detalles de fila con plantilla XAML para obtener detalles.

Agrupación de filas

Orden de filas de arrastrar y soltar

En mi opinión, las características anteriores deberían ser estándar en todas las cuadrículas de datos.

Si desea que la cuadrícula de datos se destaque en el mundo html, también incluiría lo siguiente. Me encuentro muchas veces mirando una cuadrícula de datos y luego estableciéndome en una vista de lista ya que la cuadrícula de datos carece de estas características.

Desliza la fila lateralmente para incluir funciones como editar, eliminar, marcar, etc.

Las características anteriores manejan principalmente la "presentación de datos", lo que todavía falta en WinUI es lo que creo que debería ser una característica nativa de WinUI (control) como Microsoft Pivot Control. para complementar la cuadrícula de datos.

MS ya tiene el código fuente para esto y fue un control absolutamente increíble en los días.

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

Ahora cubre la presentación y visualización de datos que deberían ser el mínimo para diferenciar a WinUI de todas las características básicas que existen.

Lo más importante es que realmente muestra el poder de las "aplicaciones nativas" que deberían incluir animaciones asombrosas y controles visualmente atractivos que son poderosos y se ven realmente geniales.

Puedo llevar esto un paso más allá y decir que después de las características anteriores (visualizaciones) podemos incluir animaciones 2D / 3D que crean un concepto de profundidad en los datos y nos llevarán a una estratosfera diferente, pero supongo que eso es para otro día; ))

Un buen punto de partida es mirar a su socio Telerik con su RadDataGrid (UWP Open Source). Con uno de mis clientes, lo usé y realmente funciona bien. Es muy rápido y versátil. Lo único que es difícil es su código, no hay forma de modificar nada de su motor sin una buena comprensión de la arquitectura.

Esperaría que el nuevo DataGrid tenga el mismo rendimiento que Telerik.

Estoy muy contento de ver que el equipo de WinUI está considerando un control DataGrid.

Las mejoras más sustanciales que me gustaría ver de un nuevo control para reemplazar el Toolkit DataGrid:

• La capacidad de recuperar un DataGridRow por índice
• Eventos específicos de los propios DataGridRows. Por ejemplo, DoubleTapped y RightTapped.
• Desplazamiento suave
• Validación de entrada para cambios de nombre de celda
• Un DataGridColumn diseñado específicamente para iconos de fila
• Fácil personalización de colores, etc.

La opción de tener un botón de edición que coloque iconos arrastrables al lado de cada fila para mover el orden sería una característica útil. También sería genial ver que algunas sombras detrás de la fila se levantan y mueven (ya que uno de los atributos principales de Fluent es la profundidad). Las flechas pequeñas hacia arriba y hacia abajo pueden ser buenas junto al icono de arrastrar para mover las filas más fácilmente con la entrada del mouse. Si se mueve una fila con las flechas, una animación de deslizamiento sutil sería un buen toque. Con la entrada táctil, la opción de mantener una fila y simplemente moverla sin siquiera tener que presionar el botón de edición también podría funcionar bien. No estoy seguro de si esto ya es compatible, pero pude ver casillas de verificación de selección como en el Explorador de archivos, lo que hace obvio qué DataGrids admiten la selección de filas y simplemente mejoran la UX general. La aplicación de recordatorios de iOS contiene algunas de estas ideas (los ejemplos se muestran a continuación). La aplicación iOS Stocks también tiene un tipo similar de trato con filas móviles. La mayoría de estas ideas también funcionarían muy bien para columnas.

@NoahFeller Ese tipo de acción tiene más sentido para una vista de lista. Con una vista de cuadrícula, no está reorganizando el orden, debería haber opciones de clasificación, pero el usuario no está arrastrando cosas.

*Editar
Después de pensarlo un poco más, veo cómo esta opción puede ser útil. Sin embargo, definitivamente no creo que este deba ser el comportamiento predeterminado.

@NoahFeller Ese tipo de acción tiene más sentido para una vista de lista. Con una vista de cuadrícula, no está reorganizando el orden, debería haber opciones de clasificación, pero el usuario no está arrastrando cosas.

*Editar
Después de pensarlo un poco más, veo cómo esta opción puede ser útil. Sin embargo, definitivamente no creo que este deba ser el comportamiento predeterminado.

Sí, probablemente tengas razón @yaichenbaum. Estaba visualizando esas sugerencias como la capacidad de hacer una clasificación personalizada y pensé que arrastrar podría ser útil para eso. Así que estoy de acuerdo, definitivamente no es el predeterminado, pero podría ser bastante útil como opción. ¡Gracias por la respuesta!

La simplicidad de la función de tabla de datos a cuadrícula de datos de WPF. De hecho, he estado luchando durante la última semana tratando de hacer que una cuadrícula de datos de UWP funcione como lo tenía en WPF, donde podría vincular una cuadrícula de datos a una vista de datos, luego llenar la vista de datos de SQL con una vista predeterminada de tabla de datos. La cuadrícula simplemente mostró la tabla de datos. Fue increíblemente simple de hacer, y UWP hasta ahora lo ha hecho ridículamente complicado.

hazlo multiplataforma

Me gustaría solicitar un modo de selección de celda única, estilo Excel.
El objetivo final es un modo con el comportamiento exacto de WinForms DataGridView.

Tener una variedad de opciones de virtualización que pueden admitir diferentes casos de uso (desde opciones de virtualización de desplazamiento simple como el reciclaje hasta otros conceptos como la paginación de datos)
A menudo (en controles de escritorio similares que admiten esto), algunas de estas opciones comienzan a fallar cuando se utilizan con plantillas personalizadas para columnas con datos únicos. Cuanto más puedan soportar en esos casos, mejor.

Si es posible, la propuesta de Paging Control # 268 debe sincronizarse y los ganchos necesarios deben agregarse al control DataGrid.

¡Estas son buenas noticias! He estado esperando algo oficial en el frente de DataGrid durante un tiempo desde que apareció en el kit de herramientas de la comunidad. Este es realmente el último control que falta en WinUI 3.0 para el que el kit de herramientas de la comunidad no tiene una buena alternativa.

Primero, por favor, no reinventes la rueda. Como base, comience con la implementación de WPF de DataGrid (sé que no puede usar el código, pero use el 100% de la API), NO la de Silverlight. WPF DataGrid tenía muchas más funciones y tenía menos errores en mis pruebas.

Al usar el kit de herramientas de la comunidad DataGrid, también solicité las siguientes adiciones de API que surgieron para varios casos de uso. Discusión aquí :

• RowPressed: como se discutió anteriormente. Indica que se ha pulsado una fila para que se puedan producir más procesos o menús contextuales.
• RowDoublePressed: Igual que RowPressed, solo la versión de doble clic.
• ColumnHeaderPressed: Ocurre cada vez que se presiona un encabezado de columna. Debe tener prioridad sobre las actualizaciones internas de cualquier dirección de clasificación. Esto permitirá menús de filtrado personalizados o opciones de clic derecho para activar / desactivar columnas.
• ColumnHeaderDoublePressed: Igual que ColumnHeaderPressed, solo la versión de doble clic.
• ColumnHeaderWidthChanged: Ocurre siempre que el usuario cambia el tamaño del ancho del encabezado de una columna. Esto permitirá guardar esta información de forma limpia. Esto suele ser necesario al restaurar el estado de la interfaz de usuario.

También sigo teniendo muchos problemas con la comunidad que tomó DataGrid restableciendo la posición de desplazamiento a la parte superior después de que se cambia ItemsSource. Esto debe arreglarse para que el desplazamiento se conserve como en WPF; sin embargo, también necesitamos poder controlar esto, por lo que sugeriría la siguiente API también:

• FirstRowInView (): devuelve la primera fila visible en el DataGrid utilizado para restaurar el estado.
• VerticalOffset: Obtener / Establecer nuevamente para restaurar el estado de la barra de desplazamiento
• HorizontalOffset: Obtener / Establecer para restaurar el estado de la barra de desplazamiento

@RBrid También ayudó con algunos análisis aquí :

Nuevos eventos sugeridos y algunas mejoras a los eventos preexistentes:

| Evento | Comentarios |
| : --- | : --- |
| ContextRequestedForColumnHeader | Para admitir la visualización de un menú contextual (u otro menú flotante) cuando se hace clic con el botón derecho en el encabezado de una columna. Lo mismo que Windows.UI.Xaml.UIElement.ContextRequested pero para los encabezados de columna en lugar de todo el DataGrid. |
| ContextCanceledForColumnHeader | Lo mismo que Windows.UI.Xaml.UIElement.ContextCanceled pero para los encabezados de columna en lugar de todo el DataGrid. |
| ContextRequestedForRow | Para admitir la visualización de un menú contextual (u otro menú flotante) cuando se hace clic con el botón derecho en una fila. Lo mismo que Windows.UI.Xaml.UIElement.ContextRequested pero para filas en lugar de todo el DataGrid. |
| ContextCanceledForRow | Lo mismo que Windows.UI.Xaml.UIElement.ContextCanceled pero para filas en lugar de todo el DataGrid. |
| RowTapped | Tenga en cuenta también el caso de tocar una fila que ya está seleccionada. |
| RowDoubleTapped | Lo mismo que Windows.UI.Xaml.UIElement.DoubleTapped pero para filas en lugar de todo el DataGrid. |
| RowRightTapped | Lo mismo que Windows.UI.Xaml.UIElement.RightTapped pero para filas en lugar de todo el DataGrid. Consulte también ContextRequestedForRow . |
| PointerPressedInRow | Lo mismo que Windows.UI.Xaml.UIElement.PointerPressed pero para filas en lugar de todo el DataGrid. |
| PointerReleasedInRow | Lo mismo que Windows.UI.Xaml.UIElement.PointerReleased pero para filas en lugar de todo el DataGrid. |
| PointerMovedInRow | Lo mismo que Windows.UI.Xaml.UIElement.PointerMoved pero para filas en lugar de todo el DataGrid. Posiblemente PointerMovedInRow solo se activaría mientras se captura el puntero. |
| ColumnHeaderTapped | Tenga en cuenta también el caso de tocar un encabezado de columna que ya está seleccionado. |
| ColumnHeaderDoubleTapped | Lo mismo que Windows.UI.Xaml.UIElement.DoubleTapped pero para los encabezados de columna en lugar de todo el DataGrid. |
| ColumnHeaderRightTapped | Lo mismo que Windows.UI.Xaml.UIElement.RightTapped pero para los encabezados de columna en lugar de todo el DataGrid. Consulte también ContextRequestedForColumnHeader . |
| ColumnHeaderWidthChanged | Alternativamente, podría llamarse ColumnHeaderResized . En los argumentos del evento, incluya una propiedad booleana que especifique si el usuario la modificó o si se modificó mediante programación. Obviamente, los argumentos del evento también deben especificar qué encabezado de columna se redimensionó / ​​cambió. |
| SortOrderChanged | Debe activarse cuando cambia la lista de encabezados de columna seleccionados. También se activa cuando cualquiera de las columnas seleccionadas cambia entre orden ascendente o descendente. En los argumentos de evento, incluya una propiedad booleana que especifique si el usuario cambió el orden de clasificación o si lo cambió mediante programación. Consulte también el evento preexistente Sorting . Creo que se activará un nuevo evento SortOrderChanged después de que se active el evento Sorting , si no se cancela la clasificación. |
| Sorting | Ya existe, pero considere agregar una propiedad booleana configurable en argumentos de evento que permita cancelar la solicitud de clasificación. Por ejemplo, es posible que la clasificación no sea válida o no se pueda realizar y deba cancelarse. También agregue una propiedad booleana para especificar si la ordenación fue solicitada por el usuario o mediante programación. |
| ColumnSortDirectionChanged | Este evento podría crearse, pero podría ser innecesario si se crea el evento SortOrderChanged mencionado anteriormente, si SortOrderChanged también se activa cuando cambia la dirección de clasificación. |
| ColumnDisplayIndexChanged | Ya existe, pero considere agregar una propiedad booleana (en argumentos de evento) que especifique si el usuario la modificó o si se modificó mediante programación. Además, documente por qué es necesario tener los eventos ColumnDisplayIndexChanged y ColumnReordered . Alternativamente, elimine uno de estos eventos. |
| ColumnReordered | Ya existe, pero considere agregar una propiedad booleana que especifique si fue modificada por el usuario o modificada mediante programación. |
| SelectionChanged | Ya existe, pero considere agregar una propiedad booleana (en argumentos de evento) que especifique si el usuario la modificó o si se modificó mediante programación. |
| CopyingRowClipboardContent | Ya existe, pero considere agregar una propiedad booleana a los argumentos del evento que especifique si la operación se corta en lugar de copiar. Alternativamente, haga un evento separado para cortar. |
| CuttingRowClipboardContent | No existe Considere la posibilidad de crear un evento que se active cuando el usuario intente cortar filas (mediante la tecla de acceso rápido control-X, el menú contextual o de otra manera). Alternativamente, cree la propiedad booleana antes mencionada que permitiría activar CopyingRowClipboardContent para las operaciones de copia y corte |
| PastingRowClipboardContent | No existe Considere la posibilidad de crear un evento que se active cuando el usuario intente pegar (mediante la tecla de acceso rápido control-V, el menú contextual o de otra manera). |

Creo que la característica más importante para mí sería la capacidad de manejar fácilmente un millón de filas o más, sin tener que cargar un millón de filas en la memoria. La interfaz ISupportIncrementalLoading no es lo suficientemente buena para esto, porque la barra de desplazamiento solo refleja cuántas filas ha cargado hasta ahora (no el recuento total), y para llegar a la fila 1 millón, tendría que seguir desplazándose hasta el final y cargar más y más datos, y espero no quedarme sin memoria. Pero si sé que tengo 1 millón de registros de datos, déjeme decirle a la cuadrícula de datos, y si me desplazo rápido o salto hasta el final, se me puede pedir que proporcione las últimas filas.
Piense en desplazarse por una lista de filas en una base de datos que incorporaré dinámicamente.

Creo que la característica más importante para mí sería la capacidad de manejar fácilmente un millón de filas o más, sin tener que cargar un millón de filas en la memoria. La interfaz ISupportIncrementalLoading no es lo suficientemente buena para esto, porque la barra de desplazamiento solo refleja cuántas filas ha cargado hasta ahora (no el recuento total), y para llegar a la fila 1 millón, tendría que seguir desplazándose hasta el final y cargar más y más datos, y espero no quedarme sin memoria. Pero si sé que tengo 1 millón de registros de datos, déjeme decirle a la cuadrícula de datos, y si me desplazo rápido o salto hasta el final, se me puede pedir que proporcione las últimas filas.
Piense en desplazarse por una lista de filas en una base de datos que incorporaré dinámicamente.

Esta.

'Moderna' significa liviana y rápida, y las aplicaciones empresariales comúnmente se tratan de clasificar toneladas de datos internos para encontrar y explorar los registros apropiados. Paginación, clasificación, carga incremental asincrónica, desplazamiento sin fin: todos estos son elementos básicos de las aplicaciones de escritorio que aprovechan las cuadrículas de datos.

MS debería producir una aplicación de muestra que destaque estas características en la nueva cuadrícula y recopilar comentarios de los desarrolladores empresariales a lo largo del tiempo para mejorar estas experiencias. Haga que se ejecute a partir de un gran conjunto de datos como World Wide Importers para demostrar su eficacia.

@dotMorten

Creo que la característica más importante para mí sería la capacidad de manejar fácilmente un millón de filas o más, sin tener que cargar un millón de filas en la memoria.

Yo también deseo eso. Para ayudar a admitir un millón de filas (y me refiero a ayudar, no necesariamente la solución completa), sugiero que DataGrid haga que su técnica actual de enlace de datos sea opcional. Creo que actualmente el enlace de datos es obligatorio (a menos que mi conocimiento ya no esté actualizado con la última versión de DataGrid). DataGrid no debería requerir el uso de Windows.UI.Xaml.Data.Binding como la única forma admitida de recuperar los valores para cada celda / columna en cada fila visible.

Sugiero que DataGrid permita que las aplicaciones le den a DataGrid un delegado o instancia de interfaz que DataGrid invocará siempre que DataGrid necesite recuperar el valor de una celda / columna en una fila (alternativamente, este delegado o interfaz podría recuperar la fila completa - todos los valores de columna para una fila especificada).

Idealmente (si es posible), DataGrid permitiría que este delegado o interfaz funcione de forma asincrónica . Por ejemplo, el delegado o la interfaz pueden devolver un Task o IAsyncOperation<TResult> lugar de devolver inmediatamente el valor solicitado.

Alternativamente, el soporte asincrónico también es posible sin Task y IAsyncOperation<TResult> , si DataGrid funciona de manera similar al siguiente procedimiento:

1. DataGrid decide que necesita recuperar el valor de la celda / columna 5 en el ID de fila 50001. Alternativamente, DataGrid decide recuperar todos los valores de columna para el ID de fila 50001.
2. DataGrid invoca un delegado o instancia de interfaz o un controlador de eventos que notifica a la aplicación que DataGrid ha solicitado la carga de los valores de datos de la columna / fila especificada o de toda la fila.
3. La aplicación recupera los datos de fila solicitados de forma asincrónica. Por ejemplo, podría realizar de forma asincrónica una consulta de base de datos SQL.
4. La aplicación termina de recuperar los datos de fila solicitados. La aplicación invoca un método en DataGrid que proporciona los datos de la fila a DataGrid.
5. DataGrid muestra los datos de la fila o hace cualquier otra cosa que tenga que hacer con los datos.

Primero que nada, ¡guau! Muchas gracias a todos los que están contribuyendo con sus ideas. Tengo algunas respuestas específicas a continuación, pero en general, quería decir que estoy guardando un montón de estos comentarios y realmente disfruto escuchando cómo podemos construir un DataGrid moderno increíble. ¡Sigue viniendo!

@Pinox muchas gracias por esa respuesta detallada y las capturas de pantalla. Tu lista de deseos es increíble (¡especialmente esas animaciones geniales!). Estoy de acuerdo en que esas características que se encuentran en html son un buen punto de inspiración y son simples, pero mejorarían enormemente la calidad de vida. ¡Definitivamente guardaré este comentario para referencia futura!

@verelpode , @robloo , @ duke7553 ¡ SÍ a los eventos específicos de DataGrid! Gracias a todos por el detalle que pusieron en estos. Como diseñamos para tocar primero y para una variedad de entradas, ¡eventos como estos definitivamente deberían implementarse!

@dotMorten , @jkewley , @verelpode El rendimiento es definitivamente una de las principales motivaciones de este proyecto y una de las principales mejoras que queremos implementar, a través de una nueva historia de virtualización de datos y el uso de controles modernos como ItemsRepeater. Los mantendremos a todos actualizados una vez que tengamos más detalles, pero gracias nuevamente por estos detalles que ha sugerido.

@ Laz3rPanth3r , @robloo , @keeganatorr Lo escuchamos alto y claro acerca de que le gustan los DataGrids que pertenecen a WPF y otros marcos de interfaz de usuario. ¡Definitivamente estamos teniendo esto en cuenta en esta actualización!

¡Gracias por el gran trabajo en DataGrid y la solicitud de comentarios! Aquí hay algunas mejoras más sugeridas.

Necesita más subclases de DataGridColumn

Las subclases / implementaciones actuales de DataGridColumn son insuficientes. Sugiero crear las siguientes nuevas subclases de DataGridColumn :

| Subclase propuesta | Descripción |
| : --- | : --- |
| DataGridIconColumn | Un requisito común es mostrar un ícono en cada fila de una lista, por lo tanto, sugiero hacer una subclase DataGridColumn llamada DataGridIconColumn que tipifique el valor de la celda recuperada en Windows.UI.Xaml.Controls.IconSource y muestre el IconSource instancia (se representa una instancia IconSource en cada celda). |
| DataGridImageColumn | DataGridImageColumn debería funcionar igual que el DataGridIconColumn excepto que debería representar Windows.UI.Xaml.Media.ImageSource lugar de Windows.UI.Xaml.Controls.IconSource . |
| DataGridDateTimeColumn | Muestra la fecha y / o la hora, según la configuración. Escribe el valor de la celda en System.DateTimeOffset o System.DateTime (ambos compatibles) y lo convierte en texto para que se muestre en la celda. La conversión a texto debe controlarse formateando configuraciones / propiedades en la clase DataGridDateTimeColumn . Obviamente, también se debe admitir la clasificación por fecha / hora. |
| DataGridTimeSpanColumn | Escribe el valor de la celda en System.TimeSpan y lo convierte en texto para que se muestre en la celda. La conversión a texto debe controlarse formateando configuraciones / propiedades en la clase DataGridTimeSpanColumn . Obviamente, la ordenación también debe ser compatible, y debe ordenar las instancias TimeSpan , no el texto mostrado. |
| DataGridDataSizeColumn | Escribe el valor de la celda en System.Int64 , UInt64 , Int32 , o UInt32 (todos compatibles) y lo convierte en un tamaño en bytes (como texto ) para ser mostrado. Por ejemplo, 1572864 se mostraría como "1,5 MB" porque 1572864/1024/1024 = 1,5. La conversión a texto debe controlarse mediante configuraciones / propiedades en la clase DataGridDataSizeColumn . La clasificación debe realizarse utilizando el valor entero original, no el texto mostrado. |
| DataGridCustomColumn | Esto debería funcionar de manera similar al DataGridTemplateColumn preexistente excepto sin el Windows.UI.Xaml.DataTemplate . Debería invocar un delegado / devolución de llamada o un evento para generar y / o actualizar el subárbol de elementos de la GUI mostrado. |
| DataGridTextColumn | Ya existe, pero considere agregar propiedades o eventos que permitan que las aplicaciones anulen la conversión de objeto a texto y la función de comparación para ordenar. Explico esto con más detalle más adelante en mi mensaje. |

DataGridCustomColumn sería así:

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
}

Cuando se activa el evento DataGridCustomColumn.DisplayingCell , el controlador de eventos debe generar o actualizar su propio subárbol UIElement para mostrar el DataGridDisplayingCellEventArgs.CellValue , y establecer la propiedad DataGridDisplayingCellEventArgs.CellUIElement a ese UIElement subárbol, y luego DataGrid lo mostrará.

La próxima vez que DataGrid active este evento, DataGrid debe establecer la propiedad DataGridDisplayingCellEventArgs.CellUIElement en la instancia UIElement que fue previamente generada por el controlador de eventos, para permitir que el controlador de eventos se reutilice / recicle y actualice el mismo subárbol UIElement (potencialmente con un valor diferente en DataGridDisplayingCellEventArgs.CellValue ). El controlador de eventos se permite que sea reciclar el mismo UIElement subárbol O establecer la propiedad DataGridDisplayingCellEventArgs.CellUIElement a un recién creado UIElement subárbol.

También considere la posibilidad de hacer el nuevo evento DisplayingCell directamente en la clase base DataGridColumn , en lugar de hacer la subclase DataGridCustomColumn . Por lo tanto, el evento DataGridColumn.DisplayingCell podría permitir la personalización o anulación del UIElement generado para cada subclase de DataGridColumn .

En el DataGridTextColumn preexistente, actualmente el valor / objeto de la celda se convierte en texto para su visualización invocando System.Object.ToString . Considere realizar un delegado / devolución de llamada o un evento que permita que las aplicaciones anulen esta conversión de valor a texto. Considere también una propiedad que permite a las aplicaciones especificar una instancia System.Collections.IComparer para anular el comportamiento de clasificación.

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

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

Alternativamente, en lugar de hacer la propiedad Comparer en DataGridTextColumn , considere la posibilidad de hacer la propiedad Comparer directamente en la clase base DataGridColumn , para permitir apps para controlar el comportamiento de clasificación de todas las subclases de DataGridColumn .

Del mismo modo, la propiedad CellValueToToStringConverter también se podría hacer en la clase base DataGridColumn porque sería útil tener la capacidad de convertir cualquier valor de celda en texto independientemente de la subclase de DataGridColumn se utiliza. Por ejemplo, al copiar una fila al portapapeles, cada valor de celda podría convertirse en texto. (Tanto los formatos de texto como los que no son de texto pueden colocarse simultáneamente en el portapapeles; las aplicaciones suelen hacer esto para aumentar la compatibilidad con otras aplicaciones).

Volver a ordenar cuando se selecciona DataGridIconColumn o DataGridImageColumn : Obviamente, DataGrid no puede ordenar iconos o imágenes, por lo tanto, podría usar cualquiera de estas soluciones:

• Simplemente no permita a los usuarios finales seleccionar (ordenar por) un encabezado de columna del tipo DataGridIconColumn o DataGridImageColumn .
• Hacer una AlternativeText propiedad en el IconSource clase. Cuando DataGridIconColumn ordena las filas, o cuando convierte la celda en texto para el portapapeles / copia, usaría la propiedad AlternativeText .
• Cree una propiedad Comparer configurable (de tipo System.Collections.IComparer ) en DataGridColumn o DataGridIconColumn .

Acceso a filas / elementos seleccionados

Considere mejorar la funcionalidad para obtener y configurar las filas / elementos seleccionados, porque la funcionalidad actual es insuficiente. Actualmente existen estas propiedades:

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

Descubrí que a veces necesitaba acceso a las instancias de DataGridRow de las filas seleccionadas, por lo que espero que las siguientes propiedades se puedan agregar a DataGrid:

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

Alternativamente, si lo anterior es demasiado difícil de implementar, la siguiente variación de solo lectura es menos poderosa pero aún útil:

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

Si las instancias de DataGridRow pueden reciclarse , la documentación de las propiedades anteriores debe advertir que la información devuelta solo es válida temporalmente, por lo que debe leerse / usarse de inmediato y no conservarse durante un período de tiempo más prolongado.

Además, la propiedad SelectedIndex preexistente da acceso a un índice seleccionado, pero ¿qué pasa con el acceso a todos los elementos seleccionados? Por lo tanto, sugiero hacer la siguiente propiedad SelectedIndexes :

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

Personalmente, encuentro el nombre "SelectedIndex" confuso porque DataGrid se usa a menudo junto con una base de datos y el término "índice" tiene un significado completamente diferente en una base de datos, por lo que sugiero cambiar el nombre de las propiedades de la siguiente manera, pero espero que mi sugerencia de nomenclatura será rechazado:

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

También deseo tener la capacidad de desplazar el DataGridRow y / o DataGridColumn especificados a la vista. Actualmente existe este método:

public void ScrollIntoView(object item, DataGridColumn column);

Sugiero reemplazar el método ScrollIntoView preexistente con estos 2 métodos:

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

Obtenga y establezca el orden de clasificación en un solo golpe

Cuando las aplicaciones se abren y cierran, necesitan la capacidad de guardar y restaurar la configuración del usuario final de DataGrid, incluido el orden de clasificación y otras configuraciones. Orden de clasificación que significa la lista de columnas que fueron seleccionadas por el usuario. Tenga en cuenta que esta es una lista, no una sola columna. Se puede seleccionar más de una columna simultáneamente, es decir, la columna principal para clasificar, la columna secundaria para clasificar y la columna terciaria para clasificar, etc.

Por lo tanto, la siguiente propiedad podría realizarse en DataGrid, pero en realidad esta es solo la primera idea y no es ideal:

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

Lo anterior no es ideal porque no admite guardar y restaurar el DataGridColumn.SortDirection de cada columna en una sola visita . Me doy cuenta de que las aplicaciones pueden hacerlo en varios pasos:

1. Establezca la propiedad SortOrder en la lista de columnas seleccionadas.
2. Establezca la propiedad SortDirection de cada una de las columnas seleccionadas (repita este paso para cada columna).

Eso sigue siendo problemático porque tiene múltiples accesos, lo que significa que causa múltiples complejos de DataGrid que consumen mucho tiempo. Los usuarios finales podrían notar y sufrir un retraso significativo en un DataGrid que contiene una gran cantidad de filas, cuando el DataGrid se recurre varias veces innecesariamente. Para eliminar este problema, sugiero la siguiente solución que permite a las aplicaciones restaurar el orden de clasificación completo de un solo golpe y no causar más que un solo recurso.

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

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

Tenga en cuenta que escribí deliberadamente IReadOnlyList<DataGridColumnAndDirection> no IList<DataGridColumnAndDirection> arriba porque las aplicaciones no deberían poder modificar la lista devuelta por la propiedad SortOrder . En lugar de modificar la lista, las aplicaciones deben establecer la propiedad SortOrder en una lista que DataGrid copiará y usará para reemplazar completamente la lista de orden de clasificación completa. Por lo tanto, funcionaría de un solo golpe y evitaría múltiples complejos turísticos costosos.

Cuando DataGrid.SortOrder se establece en una nueva lista, DataGrid también establecería la propiedad DataGridColumn.SortDirection en cada columna de la nueva lista SortOrder , pero sin causar múltiples complejos turísticos. Por tanto, DataGrid.SortOrder[i].SortDirection es equivalente a DataGridColumn.SortDirection .

Obtenga y establezca el orden de las columnas mostradas en un solo golpe

Cuando las aplicaciones se abren y cierran, necesitan la capacidad de guardar y restaurar el orden del usuario final de las columnas, preferiblemente de una sola vez. Sé que la propiedad preexistente DataGridColumn.DisplayIndex es configurable, por lo tanto, teóricamente, las aplicaciones podrían restaurar la configuración del usuario final iterando a través de todas las columnas en DataGrid.Columns y establecer el DisplayIndex de cada una, pero esto podría causar errores. Por ejemplo, DisplayIndex puede fallar o comportarse de manera inesperada cuando una aplicación necesita establecer temporalmente DisplayIndex de una columna en el mismo DisplayIndex de otra columna. Además, si no se realiza de una vez, podría desencadenar múltiples redibujos y / o recálculos costosos.

Por lo tanto, sugiero hacer una propiedad ColumnDisplayOrder en DataGrid:

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

Lo mismo que mencioné anteriormente para SortOrder , ColumnDisplayOrder es deliberadamente IReadOnlyList<DataGridColumn> no IList<DataGridColumn> porque debería funcionar de una vez.
Cuando DataGrid.ColumnDisplayOrder se establece en una nueva lista, DataGrid actualizará el DataGridColumn.DisplayIndex de cada columna para que coincida.

Permitir que los usuarios finales oculten / muestren columnas

De acuerdo con las propiedades preexistentes DataGridColumn.CanUserReorder etc, sugiero hacer una propiedad CanUserChangeVisibility en DataGridColumn . Cuando DataGridColumn.CanUserChangeVisibility es verdadero, el usuario final podría provocar cambios en la propiedad DataGridColumn.Visibility .

Admite elementos GUI generados dinámicamente en tiempo de ejecución

Permita que se genere la GUI de detalles de fila sin requerir el uso de DataGrid.RowDetailsTemplate ( Windows.UI.Xaml.DataTemplate ). Para lograr esto, se debe pensar un poco en la API, pero esta es mi primera idea de cómo hacerlo: tal vez hacerlo a través del evento preexistente DataGrid.LoadingRow cambiando la propiedad DataGridRowDetailsEventArgs.DetailsElement para ser configurable para que el controlador de eventos pueda generar (o actualizar) el UIElement por sí mismo y dárselo a DataGrid configurando la propiedad DetailsElement .

La razón por la que el uso obligatorio de Windows.UI.Xaml.DataTemplate es un problema: aunque las plantillas son una buena característica, el concepto de plantilla espera un fragmento / documento XAML inmutable creado previamente que fue escrito por el desarrollador de antemano. Por lo tanto, las plantillas son un problema cuando la aplicación necesita generar dinámicamente la GUI en tiempo de ejecución. Por lo tanto, deseo las alternativas antes mencionadas a DataTemplate .

Arrastrar y soltar filas, hacia adentro y hacia afuera

Sugiero tener la capacidad de habilitar opcionalmente la función de arrastrar y soltar filas de salida. DataGrid implementaría la función de arrastrar pero no la de soltar. Cuando se produce la caída, DataGrid desencadenaría un evento y la aplicación responde al evento para realizar la acción deseada cuando la fila se coloca fuera de DataGrid.

También la capacidad de habilitar opcionalmente la función de arrastrar y soltar entrantes de filas o elementos / objetos. DataGrid aceptaría arrastrar y soltar entrantes, pero no implementa la colocación. DataGrid desencadenaría un evento cuando se suelta la fila / elemento / objeto, y la aplicación responde al evento para realizar la acción deseada cuando la fila se suelta dentro de DataGrid.

Fondos de celda individuales

Tenemos una solicitud de función de un cliente que desea que se realicen celdas individuales (cambiando el color / pincel de fondo de la celda) en ciertos momentos (como cuando nuestra aplicación detecta cambios o valores importantes o valores peligrosos que exceden los límites de seguridad, etc.).

Por lo tanto, podría proponer una propiedad DataGridCell.Background (de tipo Brush ), pero creo que esta forma de hacerlo probablemente sea defectuosa porque DataGrid recicla instancias DataGridCell , ¿no? Así que supongo que hilitar celdas individuales estableciendo una propiedad DataGridCell.Background sería una solución poco confiable.

Una mejor manera podría ser a través del evento DataGridColumn.DisplayingCell que propuse en mi mensaje anterior. El controlador de eventos podría establecer una propiedad CellBackgroundBrush en DataGridDisplayingCellEventArgs .

Recuperación simplificada de datos de DataGrid (valores de celda)

Sé que "tonto" suena muy mal, pero en realidad me encantaría que DataGrid se hiciera tonto en el área de recuperación de datos (recuperación de los valores de celda que va a mostrar DataGrid).

Actualmente, DataGrid intenta realizar la recuperación de datos de una manera automática conveniente a través de su propiedad DataGrid.ItemsSource más técnicas de enlace de datos (la propiedad DataGridBoundColumn.Binding ) e interfaces como System.ComponentModel.INotifyPropertyChanged .

Sí, el enlace de datos es una característica conveniente, ¡pero en realidad prefiero que DataGrid haga _less_ en ese departamento! Varios componentes de Microsoft me causan grandes dificultades debido a su comportamiento de intentar ser inteligente pero en realidad terminan siendo demasiado inteligentes . En general, experimentaría menos dificultades y menos trabajo si estos componentes dejaran de intentar ser tan inteligentes / automáticos / convenientes. Al diseñar un comportamiento automático, considero que vale la pena tener en cuenta que automático suena muy bien, pero tiene el potencial de ser contraproducente.

_ "Simplemente déjame hacerlo yo solo". _
A veces, la mejor solución es simplemente permitir que las aplicaciones realicen la tarea por sí mismas, en lugar de intentar y no hacerlo "automáticamente" dentro de un componente como DataGrid. Desearía que DataGrid me permitiera realizar por completo la recuperación de datos por mí mismo, en lugar de intentar recuperar automáticamente los datos a través de las propiedades DataGridBoundColumn.Binding y DataGrid.ItemsSource .

Idealmente, me gustaría eliminar el requisito de usar la propiedad DataGrid.ItemsSource para suministrar los artículos. @dotMorten mencionó un millón de filas. Actualmente, DataGrid hace obligatorio que las aplicaciones establezcan DataGrid.ItemsSource , pero no es práctico crear un objeto de lista que contenga un millón de elementos. Por lo tanto, deseo que DataGrid deje de ser inteligente en el departamento de recuperación de datos y, en su lugar, me permita realizar la recuperación de datos por mí mismo, sin usar DataGridBoundColumn.Binding y DataGrid.ItemsSource .

@anawishnoff escribió:

El rendimiento es definitivamente una de las principales motivaciones de este proyecto y una de las principales mejoras que queremos implementar, a través de una nueva historia de virtualización de datos y el uso de controles modernos como ItemsRepeater.

Veo que dijo que la nueva historia de virtualización de datos mejorará el rendimiento, y eso es una buena noticia, pero ¿eliminará también el requisito de usar la propiedad DataGridBoundColumn.Binding para proporcionar los valores de celda que muestra DataGrid?

Si todo el trabajo de recuperación de datos se subcontrata a la aplicación que usa DataGrid, entonces la aplicación tiene total flexibilidad para realizar la recuperación de datos de la manera que necesite. Esto permitiría muchos escenarios diferentes de recuperación de datos, incluido el millón de filas que mencionó @dotMorten . Hazlo tonto, por favor: sonríe:

¿Algunas funciones innecesarias en WPF DataGrid?

La versión WPF de DataGrid tiene algunas características que parecen innecesarias o poco prácticas, y estas características podrían omitirse en WinUI DataGrid, pero espero que algunas personas probablemente tengan una opinión diferente sobre estas características.

¿Cuántas personas plantearían una objeción si WinUI DataGrid abandonara la función en la que los usuarios finales pueden editar valores de celda en línea / directamente dentro de DataGrid? En nuestro caso, en todos los lugares donde usamos DataGrid, siempre configuramos DataGrid.IsReadOnly en verdadero para deshabilitar la función de edición en línea / directa. Permitimos a los usuarios editar la fila seleccionada en un panel o panel separado, o en RowDetails ( DataGrid.RowDetailsTemplate ), pero no directamente dentro del DataGrid.

Parece que WinUI DataGrid ya se ha movido en la dirección de eliminar el soporte para la edición en línea / directa porque WPF DataGrid tenía CanUserAddRows y CanUserDeleteRows pero estas propiedades ya no existen en WinUI DataGrid. ¿Por qué no ir hasta el final para eliminar por completo la función de edición en línea / directa? ¿Cuántas personas tienen objeciones a esta idea?

Selección de celda individual: WPF DataGrid tiene una propiedad SelectionUnit que puede establecer en Cell , FullRow o CellOrRowHeader . En nuestro caso, siempre lo configuramos en FullRow y nunca encontramos la necesidad de configurarlo en Cell . Sin embargo, veo que una persona aquí ya ha solicitado el modo de selección de celda única. Mi pregunta es si el modo de selección de celda es una solicitud común o rara.

Por otro lado, la selección de celdas individuales puede ser útil cuando el usuario copia filas / celdas en el portapapeles. Permitiría a los usuarios copiar una celda individual (o varias celdas contiguas) al portapapeles en lugar de copiar toda la fila. Sin embargo, no estoy seguro de si esta función es realmente valiosa o no.

| Característica dudosa en WPF | Comentarios |
| : --- | : --- |
| DataGrid.IsReadOnly | ¿Quizás no hay necesidad real de establecer IsReadOnly en falso? |
| DataGrid.CanUserAddRows | No existe en WinUI DataGrid. Ya abandonado, o quizás aún no implementado (no conozco el plan). |
| DataGrid.CanUserDeleteRows | No existe en WinUI DataGrid. Ya abandonado, o quizás aún no implementado (no conozco el plan). |
| DataGrid.SelectionUnit | No existe en WinUI DataGrid. |

Vaya, increíble discusión aquí. ❤️

También acepto la API de WPF DataGrid. El DataGrid de WPF es realmente el DataGrid que quiero para WinUI 3.0.

Pero incluso WPF DataGrid carece de algunas funciones. En el pasado, la mayoría de mis clientes usaban un DataGrid de terceros más poderoso para obtener estas funciones:

• Filtros en los encabezados de columna
• Una fila de filtro completa en la parte superior de DataGrid
• Potente visualización de datos jerárquicos. Algunos DataGrids de terceros realmente funcionan como un poderoso TreeView con DataGrids anidados. Si bien WPF DataGrid permite construir algo así, no lo admite de fábrica
• Soporte para diferentes tipos de datos. Como, por ejemplo, una columna DateTime. En DataGrid de WPF, debe usar DataGridTemplateColumn

Pero de todos modos, hagas lo que hagas, creo que construir un DataGrid es una declaración poderosa y un compromiso con WinUI 3.0. Para las aplicaciones LOB, no puede tomarse en serio un marco de interfaz de usuario que no contenga un DataGrid integrado. ¡Y es genial ver esta inversión hecha para WinUI!

@thomasclaudiushuber

Para las aplicaciones LOB, no puede tomarse en serio un marco de interfaz de usuario que no contenga un DataGrid integrado. ¡Y es genial ver esta inversión hecha para WinUI!

¡Acordado! En nuestro caso, DataGrid es un componente fundamentalmente esencial que usamos en varios lugares y no podemos vivir sin él.

Potente visualización de datos jerárquicos. Algunos DataGrids de terceros realmente funcionan como un poderoso TreeView con DataGrids anidados.

Estoy dividido en ese tema porque, como usted, me parecería útil un DataGrid jerárquico en algunas situaciones, pero mi preocupación es que si DataGrid implementa la funcionalidad jerárquica, entonces podría volverse excesivamente complejo y difícil, y el lanzamiento de Lo más probable es que DataGrid se retrase sustancialmente. Sería difícil agregar nuevas características debido a la complejidad de hacer que las nuevas características sean compatibles con la funcionalidad jerárquica y no jerárquica.

Para eliminar el problema de complejidad / retrasos antes mencionado, sugiero esta solución: Cree una clase separada llamada HierarchicalDataGrid que use / envuelva internamente una instancia de DataGrid . Alternativamente, HierarchicalDataGrid podría heredar públicamente DataGrid pero sospecho que esta herencia no es práctica, por lo que prefiero sugerir que HierarchicalDataGrid herede Control e internamente tenga un campo privado de escriba DataGrid . Por lo tanto, la funcionalidad jerárquica se implementaría en la capa HierarchicalDataGrid que dirige una instancia interna DataGrid no jerárquica.

La ventaja clave de la solución anterior es que ofrecería las características jerárquicas deseadas _ sin_ atascar DataGrid , sin hacer que DataGrid tan complejo que se vuelva inmanejable y lento de desarrollar.

Soporte para diferentes tipos de datos. Como, por ejemplo, una columna DateTime.

Estoy de acuerdo. Echa un vistazo a los DataGridDateTimeColumn y DataGridTimeSpanColumn que propuse en un mensaje anterior.

@Pinox

Filtra fácilmente toda la página

@thomasclaudiushuber

Filtros en los encabezados de columna; Una fila de filtro completa en la parte superior de DataGrid;

Los filtros serían excelentes para ayudar a los usuarios finales a encontrar rápidamente una fila o filas, en lugar de la situación actual de verse obligados a mirar manualmente una gran cantidad de filas para encontrar lo que están buscando.

Pero, ¿qué pasa con el problema de hacer coincidir el texto del filtro del usuario con columnas que no son de texto? ¿Significa columnas distintas a DataGridTextColumn , como filtrar con DataGridTemplateColumn etc.? Sugiero resolver esto con algo aproximadamente como la siguiente solución que le da a DataGridColumn (y subclases) la capacidad de convertir un valor de celda en palabras clave para usar con búsqueda / filtrado / coincidencia.

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);
    }
}

A continuación, se muestra un ejemplo de cómo utilizar el método 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);
    }
}

Alternativamente, el valor de la celda podría convertirse en una sola cadena en lugar de una colección de palabras clave, pero la razón por la que sugerí una colección de palabras clave es que las palabras clave hacen posible el uso de algoritmos de búsqueda que se ejecutan a alta velocidad incluso cuando la cantidad de filas es muy grande.

Fácil copia pasada de Excel
Ahora no hay forma de usar ctrl + v para copiar el contenido de las celdas de Excel en la cuadrícula de datos. Ahora copia todo el contenido de las celdas en una celda en la cuadrícula de datos.

Proporcione una compatibilidad adecuada con varios elementos seleccionados, haciendo SelectedItems como una propiedad de dependencia para permitir el uso de enlace de datos al administrar filas seleccionadas.

@verelpode Puedo ver que la selección de celdas individuales es útil para cualquier aplicación de tipo de hoja de cálculo, ¿no? Creo que importa más en escenarios de edición que en escenarios de visualización. Al visualizar datos en una cuadrícula de datos sin editar, acepto que no vería un uso para la selección de celdas individuales y siempre tendré una selección de filas completa.

@anawishnoff Creo que @ Laz3rPanth3r estaría de acuerdo y el par de problemas aquí y aquí del kit de herramientas de que poder ingerir datos de manera fácil y simple en DataGrid es una característica importante. Debería poder arrancar la cuadrícula enlazándose a una colección de objetos o expandiendo objetos en una lista. Si puede seleccionar columnas de manera inteligente para números y cadenas y tipos de datos básicos, sería genial. El desarrollador siempre puede trabajar más después de personalizar columnas individuales más allá de eso.

Puedo ver que la selección de celdas individuales es útil para cualquier aplicación de tipo de hoja de cálculo, ¿no?

En una hoja de cálculo, los encabezados de las columnas se nombran con letras ascendentes del alfabeto, A, B, C, D, ... y el tipo de cada columna es el mismo, como si cada columna usara DataGridTextColumn y ninguna otra columna se necesita el tipo, y los nombres de las columnas tampoco son realmente necesarios porque se generan automáticamente a partir del alfabeto.
Otra diferencia entre DataGrid y una hoja de cálculo es que una hoja de cálculo no ordena las filas cuando hace clic en cualquiera de los encabezados de columna.

Mi punto es que solo existe una similitud superficial (principalmente una similitud visual) entre DataGrid y una hoja de cálculo. DataGrid no funciona realmente como una hoja de cálculo. La técnica de recuperación de datos de celda de DataGrid tampoco es adecuada para una hoja de cálculo.

Me encanta DataGrid, pero funcionaría mal si intentara usarlo para implementar una hoja de cálculo. No creo que DataGrid sea la opción correcta para cualquiera que quiera implementar una hoja de cálculo.

El diseño existente de DataGrid se alinea mucho mejor con una base de datos SQL que con una hoja de cálculo, y los desarrolladores de bases de datos SQL gritarían fuerte si alguien intentara afirmar que una base de datos es "sólo una hoja de cálculo".

@verelpode Tus contribuciones son tan detalladas y pensadas, ¡muchas gracias por todo eso! Quiero hablar sobre la idea de vincular una fuente de datos / la propiedad ItemsSource de DataGrid, como mencionaste y @ michael-hawker también lo hizo.

Actualmente, DataGrid hace obligatorio que las aplicaciones configuren DataGrid.ItemsSource, pero no es práctico crear un objeto de lista que contenga un millón de elementos. Por lo tanto, deseo que DataGrid deje de ser inteligente en el departamento de recuperación de datos y, en su lugar, me permita realizar la recuperación de datos por mí mismo, sin usar DataGridBoundColumn.Binding y DataGrid.ItemsSource.

Esto es interesante y me gustaría profundizar más en él, ya que estamos realmente interesados ​​en el rendimiento. ¿Qué tipo de situación / escenario de datos está buscando, específicamente? ¿Le gustaría conectar el DataGrid directamente al resultado de una consulta SQL, o una base de datos, o algo por el estilo?

@khoshroomahdi Al copiar y pegar, ¿quiere decir que desea copiar celdas de Excel en un DataGrid en una aplicación en ejecución y completar de esa manera? Ese es un caso de uso interesante, me gustaría escuchar más.

@alexyak , ¿podrías expandirte un poco más? La propiedad SelectedItems actualmente le permite obtener todos los elementos seleccionados en un DataGrid (aunque a través del modo de selección extendido, no precisamente del modo de selección múltiple). Veo en algunos otros comentarios aquí que la selección dentro de un DataGrid definitivamente necesita trabajo, pero quiero comprender mejor su solicitud.

@anawishnoff sí exactamente.
Tengo algunos datos en celdas excelentes y quiero copiarlos en la aplicación en ejecución.

Para escenarios no vinculados a datos, deberíamos ver cómo el control WinForms DataGridView, que escribí hace muchos años, admitía un modo virtual: https://docs.microsoft.com/en-us/dotnet/api/system. windows.forms.datagridview.virtualmode

Actualmente, DataGrid hace obligatorio que las aplicaciones configuren DataGrid.ItemsSource, pero no es práctico crear un objeto de lista que contenga un millón de elementos. Por lo tanto, deseo que DataGrid deje de ser inteligente en el departamento de recuperación de datos y, en su lugar, me permita realizar la recuperación de datos por mí mismo, sin usar DataGridBoundColumn.Binding y DataGrid.ItemsSource.

Estoy de acuerdo en que también estaría bien. Estoy pensando en algo como ListBox, donde puede agregar elementos manualmente o configurar ItemsSource. Dicho esto, en el pasado solo generaba una nueva DataTable que representa una vista parcial de la base de datos completa para implementar la paginación (que es un buen caso de uso para esto). A continuación, se puede establecer una vista de ese DataTable en ItemsSource. Entonces, aunque definitivamente creo que es bueno tener esto, no parece obligatorio para un alto rendimiento.

Con respecto a todos los comentarios que convierten el control en más o menos un subconjunto de Excel (r), creo que, desde el primer momento, el DataGrid debería admitir la selección de celdas y la edición por celda. Sin embargo, cosas como copiar / pegar entre aplicaciones externas deben ser manejadas por el desarrollador.

@alexyak Con respecto a su solicitud de convertir SelectedItems en una propiedad de dependencia real y enlazable, esto también sería excelente para restaurar el estado (la mayoría de mis solicitudes de funciones hasta ahora son para restaurar el estado de la vista). Creo que este es un problema de todo el marco, ya que no es compatible con ningún control de WinUI / UWP que yo conozca. Probablemente debería ser una solicitud de función general. Ver discusión aquí

@anawishnoff escribió:

Tus contribuciones son tan detalladas y pensadas, ¡muchas gracias por todo eso!

Gracias, me alegra saber que mis contribuciones son útiles para hacer que DataGrid sea aún mejor :)

¿Qué tipo de situación / escenario de datos está buscando, específicamente? ¿Le gustaría conectar el DataGrid directamente al resultado de una consulta SQL, o una base de datos, o algo por el estilo?

Eso sigue siendo demasiado inteligente. Este comportamiento inteligente evita que diferentes aplicaciones realicen la recuperación de datos de diferentes maneras. Las diferentes aplicaciones tienen circunstancias muy diferentes, por lo que el "mejor" sistema de recuperación de datos es diferente para diferentes aplicaciones; no existe un "mejor" único. Por ejemplo, algunas aplicaciones nunca muestran más de un par de cientos de filas, mientras que otras aplicaciones pueden funcionar con un millón de filas como mencionó @dotMorten , por lo tanto, una talla de zapato no sirve para todos.

Sugiero realmente simplificarlo a este nivel:

1. DataGrid decide que necesita mostrar (o usar) el valor que existe en la columna 5 de la fila 9001 en el sistema de almacenamiento de datos externo.
2. DataGrid notifica a la aplicación que necesita el valor para la columna 5 de la fila 9001.
3. La aplicación recupera el valor de la columna 5 de la fila 9001. Esto puede implicar una consulta SQL asíncrona, una Tarea C # asíncrona o cualquier otro sistema de datos. Idealmente, DataGrid debería permitir que este paso sea asíncrono.
4. La aplicación notifica a DataGrid que terminó de recuperar el valor de la columna 5 de la fila 9001. La aplicación le da este valor a DataGrid.
5. DataGrid usa el valor de cualquier manera que sea necesario, como mostrar el valor como se menciona en el paso 1.

@RBrid escribió:

Para escenarios no vinculados a datos, deberíamos ver cómo el control WinForms DataGridView, que escribí hace muchos años, admitía un modo virtual:

¡Si si si! Nunca he usado WinForms DataGridView, pero acabo de leer la documentación ahora y creo que ha dado en el clavo. La página web a la que vinculó dice:
_ "El modo virtual está diseñado para su uso con grandes almacenes de datos". _

Veo que WinForms DataGridViewCellValueEventArgs contiene estas propiedades:

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

Eso es excelente, excepto que, idealmente, debería actualizarse para admitir las palabras clave modernas C # async y await , o el equivalente de UWP ( IAsyncOperation<TResult> ), o más bien cualquier tipo de retraso de tiempo entre DataGrid que solicita el valor de la celda y la aplicación que entrega el valor de la celda a DataGrid. Por lo tanto, para actualizarlo para admitir async, haga lo siguiente:

1. Mantenga el evento CellValueNeeded .
2. Quite la propiedad DataGridViewCellValueEventArgs.Value .
3. Cree un método en DataGrid llamado algo así como SupplyCellValue que la aplicación invocará, en lugar de ser requerido para establecer inmediatamente / sincrónicamente la propiedad DataGridViewCellValueEventArgs.Value .

El método SupplyCellValue podría definirse así:

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

Por lo tanto, en tiempo de ejecución, el procedimiento es:

1. DataGrid decide que necesita mostrar (o usar) el valor que existe en la columna 5 de la fila 9001 en el sistema de almacenamiento de datos externo.
2. DataGrid desencadena el evento CellValueNeeded y establece DataGridViewCellValueEventArgs.RowIndex en 9001 y DataGridViewCellValueEventArgs.ColumnIndex en 5.
3. El controlador de eventos (la aplicación) comienza a ejecutar una tarea asíncrona que recuperará el valor de la columna 5 de la fila 9001.
4. Cuando la tarea asíncrona termina de ejecutarse, es decir, cuando la aplicación ha recuperado el valor, la aplicación invoca el método DataGrid.SupplyCellValue .

Esta técnica simplificada es más poderosa y flexible que la técnica automatizada inteligente de DataGridBoundColumn.Binding y DataGrid.ItemsSource .

@alexyak , ¿podrías expandirte un poco más? La propiedad SelectedItems actualmente le permite obtener todos los elementos seleccionados en un DataGrid (aunque a través del modo de selección extendido, no precisamente del modo de selección múltiple). Veo en algunos otros comentarios aquí que la selección dentro de un DataGrid definitivamente necesita trabajo, pero quiero comprender mejor su solicitud.

Necesitamos un enlace de datos bidireccional adecuado para que los modelos de vista administren selecciones múltiples

@verelpode , habíamos modelado el modelo WinForms DataGridView a partir de los controles Win32 ComCtl32 aún más antiguos. En particular, estoy pensando en cómo el control de vista de lista usó el mensaje LVN_GETDISPINFO en modo virtual (consulte https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview # handling-virtual-list-view-control-notification-codes y https://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo). Cosas viejas de los 90.

De todos modos, creo que la forma en que se debe manejar el aspecto de recuperación de datos asincrónicos es a través de 'eventos diferidos'.
Los controles de WinUI ya usan eventos diferidos dos veces:

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

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

Es el patrón que el nuevo evento CellValueNeeded de DataGrid querría adoptar. Permite que el controlador de eventos proporcione datos de forma asincrónica y le diga al control cuando haya terminado de hacerlo. Consulte https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferral.

@RBrid
Buen punto acerca de que GetDeferral() es el nuevo patrón estándar. En este caso particular de CellValueNeeded , parece mucho más difícil usar Deferral que en otros casos / eventos. Corrígeme si me equivoco, pero creo que el problema con el uso de GetDeferral() en este caso particular es que GetDeferral() crea un nuevo objeto cada vez que se invoca, y esto daría lugar a una excesiva Se repite una gran cantidad de creación y limpieza de objetos para cada celda de cada fila de un número potencialmente grande de filas. No he visto el código fuente de varias implementaciones de GetDeferral() , por lo que podría estar equivocado al respecto.

En otras palabras, a menos que Deferral apoye el reciclaje o tenga una forma de hacer que GetDeferral() mucho más eficiente, entonces sigue siendo demasiado inteligente. Mi propuesta simplificada con el método SupplyCellValue evita incurrir en la sobrecarga de crear, completar y eliminar una nueva instancia Deferral para cada celda de cada fila aplicable.

1. GetDeferral()
2. Aplazamiento Completo
3. Aplazamiento Desechar
4. Repita los pasos anteriores una gran cantidad de veces.

La tarea de recuperar un valor de celda no es la única tarea de administración de datos que puede subcontratarse a la aplicación. La clasificación también podría subcontratarse. Por lo tanto, valdría la pena considerar pensar en una interfaz en lugar de un solo evento CellValueNeeded . Una aplicación le daría a DataGrid un módulo de gestión de datos en forma de objeto que implementa una determinada interfaz. DataGrid invocaría esta interfaz para recuperar valores de celda, pero también potencialmente otras tareas como la clasificación.

Para admitir el millón de filas que mencionó @dotMorten , CellValueNeeded sí solo no resolvería el otro problema que ocurre cuando el usuario hace clic en el encabezado de una columna y DataGrid intenta ordenar un millón de filas. Por lo tanto, la recuperación Y clasificación de celdas podría subcontratarse a la aplicación a través del módulo / interfaz mencionado anteriormente.

Si la aplicación no proporciona ningún módulo / objeto de gestión de datos a DataGrid, lo ideal es que DataGrid utilice un módulo de gestión de datos predeterminado. Por lo tanto, todo el código de enlace de datos existente en DataGrid se movería de DataGrid a una nueva clase separada: la clase que implementa el módulo de administración de datos predeterminado al trabajar con DataGridBoundColumn.Binding etc.

es decir, cuando la clasificación también se subcontrata a la aplicación o su módulo de gestión de datos, esto abre la puerta a varias soluciones que admiten un millón de filas, como escribir un módulo de gestión de datos que indique al servidor SQL que realice la clasificación, en lugar de intentar- y no ordenar un millón de filas dentro de DataGrid en menos de 10 o 20 horas después de que el usuario hace clic en el encabezado de la columna para comenzar la ordenación.

@verelpode , sí, esa es una preocupación válida. Esperaría que DataGrid posea un grupo de objetos Windows.Foundation.Deferral reciclables. Necesitaríamos confirmar la viabilidad y el rendimiento con seguridad.

Habiendo tomado una dependencia en el DataGrid del kit de herramientas de la comunidad de Windows que tiene detalles de fila como una característica (aunque con un error de rendimiento grave pero con una solución alternativa), realmente nos gustaría que esta nueva cuadrícula de datos también tuviera eso como una característica, con la misma opción para tener varios detalles de fila al mismo tiempo. Utilizándolo para un escenario de transmisión de datos de servidor a cliente.

Con un millón de filas frente a una GUI de paginación , @robloo escribió:

Estoy de acuerdo en que [apoyar un millón de filas] también sería bueno. .... Dicho esto, en el pasado solo generaba una nueva DataTable que representa una vista parcial de la base de datos completa para implementar la paginación (que es un buen caso de uso para esto). A continuación, se puede establecer una vista de ese DataTable en ItemsSource. Entonces, aunque definitivamente creo que es bueno tener esto, no parece obligatorio para un alto rendimiento.

La paginación es una técnica útil y que vale la pena mencionar, pero tiene desventajas sustanciales: hace que la función de clasificación de DataGrid sea prácticamente inútil. Lo mismo ocurre con una función de filtrado en la próxima versión de DataGrid. La paginación hace que la clasificación y el filtrado sean inútiles o, al menos, mucho menos útiles.

Por ejemplo, imagine que 2 o 3 columnas son columnas de fecha y el usuario desea ver las filas que tienen la fecha más reciente (o la más antigua) en la segunda columna de fecha. Por lo tanto, el usuario hace clic en el encabezado de la columna de la segunda fecha para ordenar el DataGrid por esa columna, y también hace clic para cambiar la dirección de clasificación de descendente a ascendente o viceversa. Esto funciona muy bien si no hay paginación en uso, o si la cantidad total de filas es lo suficientemente pequeña como para no exceder una sola página, pero se rompe si existen varias páginas.

El usuario debe encontrar la fecha más reciente (o más antigua) en todas las filas, pero una GUI de DataGrid paginada solo muestra la fecha más reciente (o más antigua) en la página actual, no en todas las filas, por lo que la paginación hace que la clasificación (y el filtrado) sea prácticamente inútil.

Esto plantea la cuestión de qué filas caen en qué página. La respuesta es que cada página normalmente contiene un subconjunto prácticamente aleatorio de filas, cuando las páginas / filas se obtienen mediante una consulta SQL SELECT que no usa ORDER BY . (Me refiero al azar desde el punto de vista del usuario, no verdaderamente al azar).

El pseudoaleatorio no es útil para los usuarios finales. Para eliminar esta aleatoriedad problemática, podríamos pensar en usar SQL ORDER BY (junto con la palabra clave ASC o DESC para controlar la dirección de clasificación), y luego sí, las páginas son no más aleatorio, pero aún está roto porque este uso de ORDER BY siempre se ordena por la misma columna y la misma dirección de clasificación, lo que significa que el orden de clasificación es frecuentemente diferente al orden de clasificación elegido por el usuario final que hace clic en una columna encabezado en DataGrid.

Para solucionarlo, deberá utilizar una consulta SQL diferente cada vez que el usuario haga clic en un encabezado de columna diferente. El SQL ORDER BY ... ASC/DESC debería mantenerse igual que cualquier orden de clasificación elegido por el usuario final de DataGrid. DataGrid no admite esto actualmente.

Una solución sugerida está en mi mensaje anterior : sugerí que DataGrid debería permitir que la clasificación se subcontrate a la aplicación (oa un "módulo de administración de datos"). Esta idea haría posible que la aplicación (o "módulo de gestión de datos") cambie el SQL ORDER BY ... ASC/DESC siempre que el usuario final cambie el orden de clasificación de DataGrid haciendo clic en los encabezados de las columnas, etc.

También podría valer la pena darle al evento preexistente DataGrid.Sorting una propiedad configurable en los argumentos del evento que permita a las aplicaciones (el controlador de eventos) cancelar la clasificación y tomar el control. Idealmente, los argumentos del evento también especificarían si el cambio de orden de clasificación se solicitó mediante programación o si el usuario final hizo clic en los encabezados de las columnas, etc. En este caso, también podría ayudar cambiar el nombre del evento DataGrid.Sorting a algo menos ambiguo porque actualmente la intención y el propósito del evento Sorting no están claros. Vea también el evento propuesto

Habiendo tomado una dependencia en el DataGrid del kit de herramientas de la comunidad de Windows que tiene Row
Detalles como una característica (aunque con un error de rendimiento grave pero con una solución), lo haríamos
Me gusta mucho esta nueva cuadrícula de datos para tener eso como una característica también, con la misma opción para tener
varios detalles de filas al mismo tiempo. Utilizándolo para un escenario de transmisión de datos de servidor a cliente.

Enlace al problema de rendimiento de Detalles de fila: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2842
Repro: https://github.com/observito/DataGridRowDetailsPerfTest

Un buen punto de partida es mirar a su socio Telerik con su RadDataGrid (UWP Open Source). Con uno de mis clientes, lo usé y realmente funciona bien. Es muy rápido y versátil. Lo único que es difícil es su código, no hay forma de modificar nada de su motor sin una buena comprensión de la arquitectura.

Esperaría que el nuevo DataGrid tenga el mismo rendimiento que Telerik.

Las características de la cuadrícula de syncfusion son excelentes, pero no son compatibles con mvvm. Entonces podrías hacerlo mejor.

¡Hola de nuevo todos! Sigamos con esta conversación. ¿Qué piensa sobre la documentación de DataGrid que existe actualmente?

Aquí hay un enlace a la página de documentación principal que enlaza con todas las demás páginas relevantes.

Si creamos un nuevo DataGrid, queremos asegurarnos de que la documentación que lo acompaña sea de primera, fácil de entender y aborde todos los problemas y escenarios que son importantes para nuestros desarrolladores.

_ ¿Cuáles son algunos de los temas que desearías que tuviéramos? ¿Cuáles son algunos temas que podrían aclararse? _

¡Hola de nuevo todos! Sigamos con esta conversación. ¿Qué piensa sobre la documentación de DataGrid que existe actualmente?

Aquí hay un enlace a la página de documentación principal que enlaza con todas las demás páginas relevantes.

Si creamos un nuevo DataGrid, queremos asegurarnos de que la documentación que lo acompaña sea de primera, fácil de entender y aborde todos los problemas y escenarios que son importantes para nuestros desarrolladores.

_ ¿Cuáles son algunos de los temas que desearías que tuviéramos? ¿Cuáles son algunos temas que podrían aclararse? _

Las imágenes que muestren configuraciones típicas de DataGrid, junto con el xaml y el código para hacerlas, serían útiles.

Las imágenes que muestren configuraciones típicas de DataGrid, junto con el xaml y el código para hacerlas, serían útiles.

@mdtauk ¿Hay alguna configuración específica de DataGrid que le

Las imágenes que muestren configuraciones típicas de DataGrid, junto con el xaml y el código para hacerlas, serían útiles.

@mdtauk ¿Hay alguna configuración específica de DataGrid que le

Creo que para el período de tiempo de WinUI 3.0, que muestra escenarios comunes de vista de icono / cuadrícula de datos de WPF, Win32. Además de lo que Microsoft considera diseños de interfaz de usuario de DataGrid Fluent / Modern.

Eso es si la idea detrás del control es alentar el paso de las IU antiguas a WinUI 3

@anawishnoff Creo que algunas de las preguntas que teníamos del kit de herramientas en términos de cosas que la gente buscaba documentación sobre dónde estaban más de estos escenarios también:

• Tematización / Re-plantillas / Alineación
• Enlace de datos (en general y en XAML)
• Evento / Manejo de selección / Carcasa
• Editar comportamientos (especialmente editar al hacer clic)
• Multi-paginación (que debería emparejarse bien con el n. ° 60 y el n. ° 268)
  
  
  
  • Cargando coordinación de animación mientras se cargan los datos
  
  
• Copiar / Pegar / Formatear
• Diferentes tipos de datos de columna (y personalizados) (por ejemplo, enumeraciones)
• Menús contextuales
• Accesibilidad

Noté que el Toolkit DataGrid existente requiere un IEnumerable para su propiedad ItemsSource. Si bien esto parece una decisión lógica, hace que configurar el objeto devuelto por Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector () como esta propiedad sea imposible. (A menos que haya una forma de convertir el objeto devuelto) Además, otros controles como ListView y GridView admiten la configuración de su propiedad ItemsSource en un valor del tipo de objeto. No estoy seguro, pero admitir esto probablemente permitiría una interfaz de usuario más receptiva durante las operaciones de almacenamiento.

@mdtauk ¿Hay alguna configuración específica de DataGrid que le

Creo que para el período de tiempo de WinUI 3.0, que muestra escenarios comunes de vista de icono / cuadrícula de datos de WPF, Win32. Además de lo que Microsoft considera diseños de interfaz de usuario de DataGrid Fluent / Modern.

Eso es si la idea detrás del control es alentar el paso de las IU antiguas a WinUI 3

Ejemplo de Win32 (Explorador de archivos)

Ejemplo de WPF

Ejemplo de telaraña

Ejemplo de UWP

@mdtauk ¡ Gracias por esas capturas de pantalla! Definitivamente creo que es importante resaltar los elementos clave que han funcionado en versiones anteriores del control y documentar cómo se pueden lograr con el nuevo control.

@ michael-hawker Impresionante. Ya veo algunos temas allí que se han mencionado varias veces en este hilo, por lo que definitivamente son un buen lugar para comenzar.

@ duke7553 No estoy 100% seguro de una solución a eso, o si sería prudente admitir un tipo de objeto. ¿Quizás @RBrid pueda

@anawishnoff & @ duke7553 , construiría el nuevo control DataGrid sobre el nuevo control WinUI ItemsRepeater. Y ese control expone su ItemsSource como un Objeto:
Object ItemsSource { get; set; };

Espero que sea compatible con CellDecorationStyleSelector como en Telerik.

@anawishnoff

estamos interesados ​​en graduarlo a un control nativo de WinUI

hmmmm, cuando dices "graduarse", ¿eso incluiría rebajarlo a C ++? Actualmente, el DataGrid de WinUI está escrito en C #. Espero que "graduado" no signifique "rebajar". Es importante destacar que WinUI necesita llegar a un punto en el que el equipo de WinUI pueda decir que WinUI es mejor que WPF en todos los aspectos importantes, pero este objetivo está muy atrasado. Este objetivo se retrasará aún más si se desperdician tiempo / recursos en degradaciones innecesarias de código como DataGrid de C # a C ++.

Aunque originalmente existía una razón para escribir WinRT / UWP / WinUI en C ++, desafortunadamente esa razón no llegó a buen término, y Google / Android tomó la mayor parte del mercado de teléfonos inteligentes, por lo tanto, la razón original para usar C ++ ya no es aplicable (fácilmente dicho en retrospectiva, pero no tan fácil de decir antes). Si WinUI se escribió en C # desde el principio, entonces el objetivo mejor que WPF se habría logrado hace 3 años, pero ahora son 8 años y aún no se ha logrado, y nadie puede decir con precisión cuándo se alcanzará el objetivo. Es de esperar que el objetivo mejor que WPF y los objetivos de "graduación" de WinUI DataGrid no se retrasen por una conversión innecesaria a un lenguaje de programación más antiguo y menos productivo.

Estoy predispuesto a favor de C ++ porque comencé a programar en C ++ antes de que existiera C #, y la gente prefiere seguir con lo que aprendieron originalmente y recordar con cariño _ "los buenos viejos tiempos" _. A pesar de mi sesgo a favor de C ++, dejé de escribir C ++ y creo que DataGrid no debería ser degradado a C ++ y retrasado. Déjelo como C # y concéntrese en cosas más importantes, como realizar las diversas mejoras sugeridas por las personas en este problema, y ​​lograr el objetivo mejor que WPF antes de que se alcance 1 década.

Amo muchos aspectos de WinUI, y aprecio las muchas mejoras inteligentes en él, y escribo el código de la aplicación para WinUI, pero ¿quieres saber la verdad honesta? La verdad es que, lamentablemente, todavía no he lanzado ninguna aplicación WinUI a los usuarios. El software lanzado a los usuarios está escrito con WPF, y a los usuarios no les importa porque el software funciona bien e incluye modernizaciones de GUI. Aunque he escrito un montón de código de aplicación para WinUI, todo es preparación, planificación, prueba, espera, no en uso por parte de los usuarios. Es de esperar que el próximo año se lance a los usuarios el primer componente de WinUI, pero agradeceré mucho más este cambio que ellos. Los usuarios apenas notarán el cambio, si todo va según lo planeado.

Desde el punto de vista de Microsoft, WinRT / UWP es un software de calidad de lanzamiento, publicado para los usuarios desde el año 2012, pero desde mi punto de vista, UWP sigue siendo un gran experimento. Para mí, UWP (incluido WinUI) es una gran versión de prueba beta con la que he estado jugando durante años.

Durante los primeros años de UWP, todos los años pensaba: _ "errr ... esperaré hasta el próximo año. Todavía hay demasiadas cosas en WPF que faltan en UWP. Seguramente el próximo año será mejor". _
Luego llegó el año siguiente y repetí el mismo pensamiento. Luego llegó el año siguiente y repetí el mismo pensamiento. Ojalá este año sea el último de decir eso, o al menos esa es mi intención.

WinUI no puede permitirse más retrasos. Deje el DataGrid de WinUI como código C #. Comience a escribir más código WinUI en C # para aumentar la productividad. Han pasado 8 años y Android ha ganado una cuota de mercado masiva. Esa es una situación grave.

Por cierto, en realidad estaba siendo amable / generoso cuando dije que UWP todavía es una versión beta, porque técnicamente UWP coincide con la definición de una versión alfa, no beta. Para ser una verdadera versión beta, debe tener todas las funciones, pero UWP aún no ha alcanzado el estado de función completa, por lo que UWP sigue siendo alfa. Por ejemplo, el artículo de Wikipedia "Ciclo de vida de la versión de software" dice:

"La fase beta generalmente comienza cuando las funciones del software están completas, pero es probable que contenga una serie de errores conocidos o desconocidos".
"Es posible que el software Alpha no contenga todas las funciones previstas para la versión final".

Wikipedia define "característica completa" de la siguiente manera:

"Una versión completa de funciones de una pieza de software tiene todas sus funciones planificadas o primarias implementadas, pero aún no es definitiva debido a errores, problemas de rendimiento o estabilidad. Esto ocurre al final de las pruebas alfa de desarrollo".

No sería razonable describir UWP como con todas las funciones porque si realmente tiene todas las funciones, entonces UWP debe tener todas las capacidades de Windows '95 y más, pero no las tiene: UWP aún no supera a Windows 95 en todas las áreas. . Windows 95 se lanzó hace 25 años. Cuando se lanzó UWP / WinRT hace 7-8 años, Microsoft sufrió una pérdida de $ 900 millones y una falta paralizante de aplicaciones en la Tienda Windows. Era una versión alfa etiquetada como versión de lanzamiento, por lo que los desarrolladores de aplicaciones esperaron y observaron. Hoy, casi 8 años después, todavía es una versión alfa y muy atrasada, y todavía estoy esperando y mirando y esperando.

Sería muy beneficioso para Microsoft y los desarrolladores si Microsoft tomara una decisión o un compromiso serio para priorizar la producción de una verdadera versión beta de UWP, para ser seguida rápidamente por una verdadera versión Release Candidate. Esto sería muy recomendable y un curso de acción muy sensato. Sería excelente para todos.

UWP todavía es alfa / incompleto por varias razones, por ejemplo: hace 25 años, era fácil usar la función "MoveFile" en Windows 95 para mover un archivo o carpeta (aunque la función se llamaba "MoveFile", admitía ambos archivos y carpetas). ¿UWP puede mover carpetas? No aún no. Obviamente, la capacidad de mover carpetas es una de las características esenciales básicas fundamentales, pero a UWP todavía le falta esta característica esencial y otras, por lo tanto, no sería razonable describir UWP como característica completa, por lo tanto, UWP aún no ha alcanzado el estado beta, a pesar de siendo lanzado hace 7-8 años. Microsoft debe priorizar una verdadera versión beta de UWP.

Hasta donde yo sé, todavía no existe un repositorio público de GitHub para rastrear problemas de UWP (que no sean problemas de IU) (o si existe un repositorio de UWP, no pude encontrarlo). Nuevamente, esto coincide con la definición de una versión alfa porque a menudo no se desea un repositorio público de seguimiento de problemas durante una etapa alfa. Si fuera una verdadera versión beta o de lanzamiento, entonces ya se habría abierto un repositorio público de seguimiento de problemas, y UWP incluiría todas las características de Windows 95 y Windows 7, y más.

¿Cómo afecta esta situación a DataGrid ? Teniendo en cuenta que una versión beta con todas las funciones de UWP está terriblemente atrasada, y considerando la gravedad de esta situación y la pérdida multimillonaria que Microsoft ha sufrido como resultado, no sería justificable y razonable perder aún más tiempo. convirtiendo WinUI DataGrid a código no administrado y un lenguaje de programación más antiguo. Microsoft dijo repetidamente que una gran ventaja de C # y el "código administrado" es una mayor productividad, y puedo decir que las afirmaciones de Microsoft sobre el "código administrado" eran definitivamente ciertas en mis experiencias tanto con C ++ como con C #. UWP habría alcanzado el verdadero estado beta hace varios años si se hubiera escrito principalmente con código administrado a partir de la versión 1.0. Así que espero que la situación no empeore aún más al realizar más de estas degradaciones innecesarias de código administrado a código no administrado.

A modo de comparación, la mayor parte de WPF se completó con éxito en los 4 años de 2006 a 2010. WPF es principalmente código administrado, a diferencia de UWP. UWP es un código no administrado y después de 8 años de desarrollo, Windows 95 todavía supera a UWP en algunas áreas, por lo que Microsoft estaba claramente en lo cierto cuando Microsoft afirmó que el código administrado aumenta la productividad. Este problema debe resolverse lo antes posible. WinUI debería haber sido mucho más fácil / rápido de crear que WPF porque ambos proyectos tienen el mismo propietario (Microsoft), por lo que WinUI puede copiar libremente el código de WPF. Por lo tanto, WinUI debería haber requerido aproximadamente la mitad del tiempo de desarrollo de WPF. En realidad, WinUI nunca debería haberse iniciado, sino que Microsoft debería haber desarrollado las funciones de WinUI en nuevas versiones de WPF; WinUI debería haber sido WPF 5.0. Entonces, la situación era un gran lío y sería muy beneficioso para Microsoft priorizar la limpieza restante de este lío y dejar de hacer cosas que hacen que el error multimillonario sea aún peor de lo que ya era (y todavía lo es cuando miras en la situación actual de cuota de mercado de teléfonos inteligentes).

Esto significa que, para evitar aún más pérdidas, Microsoft se beneficiaría recordando lo que Microsoft ya dijo / sabía en el pasado:

• El código administrado aumenta la productividad, según las propias afirmaciones de Microsoft. Cuando observa los 8 años de UWP en comparación con los 4 años de WPF, la conclusión debe ser que Microsoft estaba en lo cierto con respecto a los beneficios del código administrado.
• Los lenguajes de scripting son para scripting y los lenguajes de programación son para programación. JavaScript y PowerShell son buenos para los propósitos previstos (secuencias de comandos), pero obviamente son opciones inadecuadas para la programación de aplicaciones.
• Para tener éxito, Microsoft debe progresar de alfa a beta para su lanzamiento, y esto solo tiene éxito si es una versión de lanzamiento real, no una alfa incompleta etiquetada como "lanzamiento". Por lo tanto, Microsoft Store estuvo prácticamente vacía durante un tiempo excesivamente largo.
• Los ingenieros de software y otros empleados trabajan mejor cuando trabajan a cambio de una remuneración razonable, una cantidad razonable de horas de trabajo y un entorno de trabajo saludable. Obviamente, la pérdida multimillonaria de Microsoft nunca se revertirá mediante el uso de fanáticos / fanáticos no remunerados y sus llamados "trabajos diurnos" y "trabajos nocturnos" y sus condiciones de trabajo insostenibles / insalubres.
• La gran ganancia de cuota de mercado de Android no se debió a fanáticos no remunerados. Si los fanáticos no remunerados fueran la razón de la victoria, Linux no habría fallado. La explicación es mucho más simple: el precio de las tabletas y teléfonos inteligentes Android es MUCHO más bajo que las tabletas y teléfonos inteligentes con Windows. Obviamente, a los usuarios finales no les importan las religiones / ideologías de "código abierto" (los usuarios ni siquiera saben qué es eso), sino que simplemente aman los precios económicos de los dispositivos Android.
• Win16 es extremadamente obsoleto. Es tecnología de hace 20-30 años, de los primeros días de programación del "Salvaje Oeste". Por lo tanto, deje de escribir código nuevo basado en Win16. Llamarlo "Win32" no cambia realmente el hecho de que sigue siendo fundamentalmente Win16. Win32 es lo mismo que Win16 excepto con los punteros expandidos en tamaño de 16 bits a 32 bits. Demasiados grupos en Microsoft continúan escribiendo código nuevo basado en Win16 / 32. Esto es muy ineficiente y una gran pérdida de recursos.

@anawishnoff

estamos interesados ​​en graduarlo a un control nativo de WinUI

Consulte también el artículo de Wikipedia "Costo hundido" :

El efecto del costo hundido (o efecto Concorde) es el hecho de que el comportamiento a menudo sigue a la falacia del costo hundido; la gente demuestra "una mayor tendencia a continuar un esfuerzo una vez que se ha realizado una inversión en dinero, esfuerzo o tiempo". Este comportamiento puede describirse como "arrojar buen dinero tras el mal", y negarse a sucumbir a él puede describirse como "reducir las pérdidas".

Y de manera similar "Sesgo de continuación del plan" :

El sesgo de continuación del plan, get-there-itis o press-on-itis es una tendencia imprudente a persistir con un plan que está fallando. Este es un peligro peligroso para los capitanes de barco o pilotos de aeronaves que pueden ceñirse a un rumbo planificado incluso cuando conduce a un desastre fatal y deberían abortar en su lugar. ..... Los proyectos a menudo sufren sobrecostos y retrasos debido a la falacia de la planificación y factores relacionados, incluido el optimismo excesivo, la falta de voluntad para admitir el fracaso, el pensamiento grupal y la aversión a la pérdida de costos hundidos.

WinRT / UWP hizo que Microsoft sufriera una pérdida de $ 900 millones en el primer o segundo año y una tienda de aplicaciones vacía durante demasiado tiempo. WinRT / UWP fue una falla catastrófica, por lo que debería haberse cancelado en el segundo año, pero continuó debido al "sesgo de continuación del plan" y la aversión a la pérdida de costos irrecuperables. Este material se enseña en cursos de gestión. ¿La continuación del plan eventualmente borró o revirtió la falla catastrófica de WinRT / UWP? No, sigue siendo una falla catastrófica hoy si se mira en términos de la cuota de mercado de teléfonos inteligentes. Esas descripciones en Wikipedia describen con precisión la situación de UWP.

Hoy en día, todos tenemos que estar de acuerdo en que en el momento actual, 7-8 años después del lanzamiento de WinRT / UWP, es demasiado tarde para cancelar UWP, pero esto significa que volvemos a ser víctimas del "sesgo de continuación del plan "y aversión a la pérdida de costes hundidos.

Entonces, ¿qué se puede hacer razonablemente para rescatar la situación? No podemos rescatar la situación cancelando UWP, aunque definitivamente debería haberse cancelado hace años. Lo que podemos hacer es esto: Aceptar el daño gigantesco que hizo WinRT, pero no causar más daño, y realizar cambios en los procedimientos / políticas del proyecto. Esto significa que deje de repetir / continuar los mismos errores catastróficos de WinRT. Por ejemplo, deje de degradar cantidades tan grandes de código administrado a código "nativo" antiguo no administrado e improductivo. El retraso en alcanzar el verdadero estado beta ya es muy grande, ¿por qué empeorar el retraso?

El error de "sesgo de continuación del plan" / costo hundido continúa si DataGrid se degrada a código "nativo" no administrado. Cuando se comete un error catastrófico como WinRT / UWP, se vuelve mucho peor cuando este mismo error se repite una y otra vez. Para limitar el daño, es necesario dejar de repetir el mismo error. Ha llegado el momento de aprender del catastrófico fracaso de WinRT y empezar a aplicar vendajes para detener la pérdida de sangre en curso.

Convertir DataGrid a código no administrado es lo mismo que ir a una biblioteca y tomar prestados los mejores libros de administración de proyectos de los mejores autores con el mayor conocimiento / experiencia, y luego arrojar todos estos excelentes libros de administración a una hoguera y verlos arder.

@verelpode Tengo curiosidad por saber cuál es su punto aquí con sus dos publicaciones muy grandes wrt DataGrid. Personalmente, no entiendo realmente qué es la retroalimentación anterior específicamente para mejorar un control OOB DataGrid. Lo único que recibí fue que te preocupa que sea una pérdida de tiempo convertirlo a código nativo, pero eso no se dirige a aquellos que usan WinUI desde C ++. Aún puede usar la implementación administrada actual si está de acuerdo con la sobrecarga de cargar el tiempo de ejecución administrado. Todo lo demás parece tener que ver con WinRT y el modelo de aplicación para UWP, ninguno de los cuales se aplica realmente a WinUI, ya que se está separando completamente de eso con v3.

@dotMorten : la razón por la que escribí detalles adicionales en esos mensajes es porque si no explico el problema de manera adecuada, la gente no lo entenderá. Pero lamentablemente ahora veo que el detalle extra falló y todavía no se entendió de todos modos. Eso es muy frustrante. Esta es la razón por la que muchas personas ni siquiera se molestan en escribir comentarios, porque creen que no tiene sentido tratar de explicar este tipo de problemas a las personas, e incluso si el mensaje se entiende con éxito, entonces es la naturaleza humana disparar al persona que da las malas noticias, por lo que es mejor no decir nada en absoluto, o simplemente sonreír "cortésmente" mientras piensa lo contrario.

ya que se está separando completamente de eso con v3.

Esta desvinculación v3 no evita la repetición de los mismos errores. El "sesgo de continuación del plan" todavía existe.

Vaya a la página de inicio de Microsoft:
https://www.microsoft.com/en-us/
Ahora desplácese hacia abajo en la página de inicio hasta que vea Windows Phone. ¡Oh! ¡Mira eso! ¡Hemos llegado al final de la página de inicio y Windows Phone no se menciona EN NINGÚN LUGAR de la página de inicio de Microsoft! ¿Qué significa esto? Significa despertar. Significa que UWP fue un fracaso catastrófico como dije. Significa que es importante dejar de repetir los mismos errores que llevaron al fracaso de UWP. Significa, cambiar el plan para rescatar y recuperarse del desastre.
Sería un error de administración si WinUI y DataGrid continúan repitiendo los mismos errores que en la falla de UWP.

"En mayo de 2016, Microsoft destruyó su negocio móvil ... En 2017, el ejecutivo de Microsoft, Joe Belfiore, reveló que Microsoft había dejado de desarrollar nuevos teléfonos con Windows y nuevas funciones para Windows 10 Mobile, citando las pérdidas en la participación de mercado y la falta de desarrollo de aplicaciones ".
- https://en.wikipedia.org/wiki/Microsoft_Mobile

Ana enumera 5 puntos para proporcionar comentarios sobre wrt DataGrid. ¿Cuál de esos puntos estás comentando? Supongo que eso es lo que no entiendo de lo que estás escribiendo. UWP no satisface las necesidades de todos, pero WinUI3 no dicta el uso del modelo de aplicación UWP, y ¿parece que usted está mayormente en contra de UWP? Entonces deberías estar bien allí.

Mencionaste que DataGrid no debería seguir cometiendo los mismos errores que cometió. Entonces, ¿cuáles son esos errores específicamente relacionados con el DataGrid existente y cómo sugiere que se corrijan? (aparte de que no quiere que se implemente en C ++ por alguna razón)

@dotMorten

Ana enumera 5 puntos para proporcionar comentarios sobre wrt DataGrid. ¿Cuál de esos puntos estás comentando?

La parte donde cité a Ana al comienzo de mi mensaje. Estoy comentando la parte del mensaje de Ana que cité al principio de mi mensaje.

WinUI3 no dicta el uso del modelo de aplicación para UWP

Eso no está relacionado con mi mensaje. El hecho de que WinUI 3 no esté vinculado y esté disponible a través del paquete nuget es irrelevante para la pregunta de si WinUI 3 continúa con los mismos errores de administración que llevaron al fracaso de UWP y Windows Phone y la pérdida multimillonaria de Microsoft.

¿Cómo sugiere que se corrijan?

Las 6 viñetas al final de mi mensaje anterior . El segundo punto (secuencias de comandos) se relaciona con WinUI y UWP en general, pero no se relaciona con DataGrid. El primer punto es el más importante si pregunta específicamente sobre DataGrid.
También escribí: deje de degradar cantidades tan grandes de código administrado a código "nativo" antiguo no administrado e improductivo. El retraso en alcanzar el verdadero estado beta ya es muy grande, ¿por qué empeorar el retraso?

@anawishnoff escribió:

estamos interesados ​​en graduarlo a un control nativo de WinUI

"graduarlo a un control nativo de WinUI" constituye prácticamente una continuación / repetición de algunos de los mismos errores que llevaron a las "pérdidas en la participación de mercado y la falta de desarrollo de aplicaciones" mencionadas en Wikipedia:

"En mayo de 2016, Microsoft destruyó su negocio móvil ... En 2017, el ejecutivo de Microsoft, Joe Belfiore, reveló que Microsoft había dejado de desarrollar nuevos teléfonos con Windows y nuevas funciones para Windows 10 Mobile, citando las pérdidas en la participación de mercado y la falta de desarrollo de aplicaciones ".
- https://en.wikipedia.org/wiki/Microsoft_Mobile

¿Por qué DataGrid debería continuar por el mismo camino que destruyó el negocio móvil de Microsoft?

@verelpode

WinUI 3 continúa con los mismos errores de administración que llevaron al fracaso de UWP y Windows Phone y la pérdida multimillonaria de Microsoft.

No trabajo para Microsoft, pero tengo curiosidad por saber por qué dice que WinUI está cometiendo errores de gestión.
Por lo que veo, el hecho mismo de que WinUI es de código abierto y que todos pueden contribuir a las conversaciones y decisiones en realidad está ayudando a definir qué es WinUI y debería evitar que ocurran errores.
Mencionas que DataGrid continúa por el mismo camino que el móvil, pero en ninguna parte del campo vi que mencionara el móvil. Quizás pueda enviar comentarios directamente sobre lo que se está discutiendo en este tema.
Si cree que hay pasos de mala administración con WinUI, entonces tal vez pueda crear un problema separado con sus inquietudes, pero realmente no creo que sus comentarios tengan nada que ver con el control DataGrid.

@verelpode, por favor, mantenga sus comentarios aquí sobre el tema. Si tiene inquietudes sobre WinUI o UWP en general, inicie un nuevo tema de discusión o contácteme directamente (envíeme un correo electrónico o DM en Twitter). O podría considerar discutir sobre un tema existente como el # 717 o el # 1531.

Compartió preocupaciones sobre la reescritura de DataGrid en C ++, pero en realidad la propuesta original no mencionó nada al respecto. @anawishnoff está intentando recopilar comentarios sobre el conjunto de funciones de DataGrid. En cuanto a la implementación, si tiene más sentido mantenerlo en C #, lo haríamos (y aún podría llamarse desde C ++ si lo hiciéramos como un componente de WinRT).

@jevansaks - Mis comentarios fueron sobre el tema, pero es la naturaleza humana disparar al mensajero que da las malas noticias. Tu respuesta me entristece y me decepciona. De acuerdo, dejaré de intentar ayudar, porque mi ayuda no es deseada porque es demasiado honesta y directa y toca temas dolorosos que son demasiado dolorosos para reconocer y resolver (la falla catastrófica de WinRT genera demasiadas emociones y, por lo tanto, es más fácil de borrar). de memoria y continuar con el mismo plan original de WinRT como si el desastre nunca hubiera sucedido). Saldré de esta discusión y no participaré más en el desarrollo de DataGrid porque continuar hablando honesta y directamente sobre los problemas reales solo molestará a la gente.

@verelpode Nadie "disparó al mensajero que da las malas noticias" aquí. @jevansaks lo invitó a abrir un nuevo número para compartir sus inquietudes generales sobre UWP / WinUI / WinRT en este repositorio. Este problema realmente se trata solo de DataGrid y, si bien una de sus preocupaciones era sobre DataGrid, la gran mayoría se refería a UWP / WinUI / WinRT en general. Estoy seguro de que si vuelve a mirar esta discusión, verá que el equipo de WinUI solo le está pidiendo que mantenga este problema enfocado únicamente en la propuesta de DataGrid y que abra un nuevo / use un problema existente para sus preocupaciones más amplias sobre el plataforma.

Las preocupaciones que mencionó pueden ser la base para una discusión interesante que involucre tanto al equipo de WinUI como a la comunidad, pero este tema en particular no es adecuado para tal discusión.

@anawishnoff
Estoy bastante seguro de que Microsoft Pivot Viewer Control no era HTML. Por favor, mire hacia atrás. La capacidad de visualizar grandes conjuntos de datos usando algo así era algo que queríamos hacer en ocasiones. Estaba disponible en Silverlight, creo. https://www.microsoft.com/silverlight/pivotviewer/default# Usó Deep Zoom para su funcionalidad. ¡Agregar la capacidad Deep Zoom a WinUI 3.0 sería fabuloso! No es realmente la cuadrícula de datos, sino un control de visualización de datos. Hay muchas ideas "abandonadas" de los primeros días de WPF, como Deep Zoom, que nunca llegaron a convertirse en un control WPF de producción que sería maravilloso revivir en WinUI 3.0 con el tiempo. ¡¡¡Ve a sacar al Dr. WPF del sótano y haz que publique de nuevo !!! Lo necesitamos de vuelta. Necesitamos iniciar un movimiento. ¡¡¡¡¡TRAIGA AL Dr. WPF !!!!! ¿Dónde has ido? Dr. WinUI !!!

@PaulMontgomerySP parece que debería abrir un nuevo número para discutir el control Pivot. No dude en hacer referencia a la discusión anterior que se tuvo al respecto desde el Kit de herramientas de la comunidad de Windows aquí: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/770

La selección cambió el evento se activa para cada fila a la que me muevo con el teclado.
Sería bueno tener un evento únicamente para un clic del mouse o toque de celda, en lugar de solo el evento de cambio de selección.

La selección cambió los eventos de activación tanto para el clic como para el teclado. Sería muy beneficioso tener un evento únicamente para hacer clic.

@ Going-Gone Tengo curiosidad por saber cuál es el caso de uso. ¿Por qué necesitas saber la diferencia? Además, ¿no puedes usar el evento tapizado?

Una limitación que acabo de encontrar con el DataGrid del UWP Toolkit es que DataGridTemplateColumn tiene una CellTemplate, pero no tiene CellTemplateSelector (y lo mismo falta para CellEditingTemplate ). Simplificaría la adaptación de la interfaz de usuario en cada celda a los datos utilizando el enfoque de selector, en lugar de tener que hacer esto con un nivel adicional de controles de interfaz de usuario debajo para manejar eso.

También haga posible seleccionar filas no solo en un orden consecutivo como lo he explicado en detalle aquí:
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

Sin un orden particular de cosas que los clientes solicitan a menudo y que una red debería admitir

1. Capacidad para guardar, cargar y construir filtros. Por ejemplo, filtrar por expresión de linq, filtrar por consulta SQL, filtrar por árbol de expresión y viceversa. Ejemplo: https://querybuilder.js.org/demo.html

1. Capacidades de datos de alta velocidad en tiempo real, el rendimiento es importante. Las frecuencias de actualización de menos de 1 ms para aplicaciones comerciales frente a> 1 millón de filas tienen diferentes consideraciones de rendimiento.
2. Capacidad para especificar el orden de clasificación, por ejemplo, i. ordenar alto / bajo, ii. ordenar bajo / alto y iii. ningún tipo o yo. ordenar bajo / alto, ii. ordenar alto / bajo y iii. ningún tipo
3. Filtrado similar a Excel
4. Posibilidad de aplicar formato css a celdas, formato condicional
5. Capacidad para guardar / cargar fácilmente la configuración de la cuadrícula, por ejemplo, filtros, anchos de columna, clasificación, etc.
6. Desplazamiento que funciona, por ejemplo, no se reinicia después de la actualización de datos, sin problemas.
7. Los eventos de recopilación de datos deben tener opciones para activar eventos después de cargar rangos en lugar de objetos individuales. Por ejemplo, creo que ObservableCollection requiere una subclase para evitar que INotifyPropertyChange se active para cada objeto individual agregado.
8. Mejores eventos para cuando se cargan / cargan datos, se inicia la carga de datos, se cargan datos, se cargan datos, especialmente si se usa la carga asíncrona.
9. Las cuadrículas a menudo están vinculadas a otros controles, como filtros de datos, selección de rango, filtro cruzado (por ejemplo, https://github.com/dc-js/dc.js), gráficos, tablas dinámicas, etc.
10. Clasificación inteligente que maneja datos alfanuméricos, por ejemplo, orden de clasificación ABC11, ABC12, ABC111 en lugar de ABC11, ABC111, ABC12
11. Niveles ilimitados de cuadrículas jerárquicas, por ejemplo, https://docs.telerik.com/devtools/wpf/controls/radgridview/hierarchical-gridview/hierachy-overview

Recursos útiles: - Diseñe mejores tablas de datos
https://news.ycombinator.com/item?id=21460966
https://uxdesign.cc/design-better-data-tables-4ecc99d23356

No podré enlazar al ancho de columna desde el encabezado directamente. En WPF, debo usar un objeto BindingProxy en ese caso.

Cómodo cambio de tamaño dinámico de la fila activa para facilitar la edición.
Control total de los menús contextuales en el modo de edición.

Espero que sea compatible con CellDecorationStyleSelector como en Telerik.

¡Accesibilidad!
Mencionarlo para que esté documentado, pero este control debe ser completamente accesible.
La versión actual del kit de herramientas tiene algunas limitaciones en esta área: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3400 & https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079
Además, si bien Telerik RadDataGrid tiene algunas características excelentes, parece no ser compatible con la accesibilidad .

Con el gran impulso de Microsoft para D&I, me sorprende que la necesidad de que todos los controles sean completamente accesibles no se especifique como un requisito en todas partes.

Quizás esto ya sea posible, y todavía no sé cómo lograrlo ... pero ¿qué tal: estilo personalizado de fila o celda?

La capacidad de apuntar a una fila específica, alterar el fondo y el color del texto sería excelente.

En comparación con WCT UWP DataGrid:
1) Rendimiento
2) Más tipos de columnas integradas (supongo que tienen un mejor rendimiento que las columnas de plantilla)
3) Posibilidad de enganchar eventos del mouse por celda, es decir, tocar, tocar con el botón derecho y pasar el cursor (o con el puntero hacia abajo o lo que sea)
4) Eventos de teclado por celda
5) Si (3) no funciona, podríamos emular si tuviéramos la funcionalidad de prueba de acceso
6) Rendimiento

¿Cuántas personas plantearían una objeción si WinUI DataGrid abandonara la función en la que los usuarios finales pueden editar valores de celda en línea / directamente dentro de DataGrid?

¿Alguien recuerda VB6? El DataGrid de VB6 admitió Editar, Eliminar y Agregar Nuevo listo para usar. Agregar estaba disponible como una fila en blanco que se agrega automáticamente al final de la lista. Complete la fila y aparecerá otra fila en blanco.

Un DataGrid debe tener la opción de admitir la entrada de datos, incluso si la mayoría de los desarrolladores prefieren que esta función esté desactivada de forma predeterminada.

Al migrar una aplicación VB6 a UWP, tuvimos que escribir nuestra propia cuadrícula de datos para admitir agregar / editar / eliminar.

Parece que la mayoría de los que contribuyen aquí son gente de WPF / Xaml, esto vale dos centavos de alguien que no es un tipo de xaml.

Utilizo mucho los controles DataGrid en mi software. ¡La edición es un lugar importante! Algunos de mis deseos / puntos débiles son:

1. Posibilidad de personalizar el menú contextual cuando está en modo de edición.
2. Mejor rendimiento y más control al ajustar el tamaño de las columnas. Quiero que el usuario pueda controlar los tamaños si es necesario, pero en general no es necesario. No quiero que el tamaño de las columnas cambie constantemente, pero quiero que de alguna manera se basen en datos sin tener que medir un millón de filas de datos.
3. Al editar, quiero poder hacer clic en un control / botón diferente que hace algo con (o con) los datos que se están editando sin finalizar la edición. (Esto sería menos necesario si se implementara el n. ° 1, aunque sigue siendo útil).
4. la forma actual en que se manejan las excepciones mediante el evento DataError es aproximada. (Lo siento, tengo problemas para ser específico sobre esto, pero sé que me ha causado dolor varias veces en el pasado).
5. La capacidad de desplazamiento automático incorporada estaría bien: http://stackoverflow.com/questions/2567809/how-to-autoscroll-a-datagridview-during-drag-and-drop
6. Posibilidad de mostrar una "marca de agua" que indica cuándo los datos están "sucios" (consulte BetterGrid para obtener algunas mejoras útiles adicionales en DataGridView.
7. Posibilidad de abandonar una fila (sin un error de validación) cuando la celda "clave" requerida se deja en blanco.
8. Capacidad incorporada para no mostrar ninguna imagen (en lugar de una X roja) para una fila agregada por el usuario. Ver: https://stackoverflow.com/questions/937919/datagridviewimagecolumn-red-x
9. Permita que una columna de casilla de verificación se confirme inmediatamente cuando se cambie: https://stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

¿Cuándo se espera que se lance el alfa? ¿Estará abierto a contribuciones? Tratando de deshacerse de una cuadrícula de datos obsoleta y realmente esperando esto, especialmente la función de virtualización.

Perdón por poner una entrada muy tardía en este hilo, pero para mí es "nuevo";)
_editado después de conocer un poco más sobre cómo se comporta el control_

Al trabajar con DataGrid para crear una interfaz similar a un explorador para unidades en la nube, descubrí que determinar la fila y la celda que se aprovechan puede ser un poco más complejo de lo que "debería" ser (en mi humilde opinión)

En el diseño de mi aplicación, las filas representan archivos o carpetas (DriveItems). La vista de detalles muestra más detalles sobre el artículo.

Quería crear la capacidad de hacer clic en un elemento de la carpeta y hacer que la interfaz salte y cree una lista de esos elementos, lo que permite la navegación por todo el disco.

Por ejemplo, si toqué la entrada de la columna "Padre" del elemento, /drive/root:/Documents/Vital%20Documents aquí, la interfaz se restablecería a esa carpeta y enumeraría los archivos allí.

Aunque se puede obtener un evento en el que se hizo clic para la celda, ese evento no parece tener el contexto para que el controlador determine la celda que se tocó (fila, sí, pero no columna), y no estoy seguro de que actualmente el el control me permitiría tener tanto el comportamiento de interceptación de celda como el comportamiento de detalles abiertos automáticamente (aún investigando lo que podría llamar "hacks" que permitirían eso, pero tenemos que recordarnos que cuando los diseñadores comiencen a anular el funcionamiento normal del control, especialmente no comportamientos que están documentados, corren el riesgo de que el diseño se rompa debido a cambios en el comportamiento del control.

Dicho todo esto, DataGrid parece respaldar mi escenario al tener el evento que actualmente devuelve DriveItem como CurrentItem, también debería incluir un CurrentColumn que sería el objeto DataGridColumn completo en el que se hizo clic, a través de del cual sería posible extraer el nombre de la columna. Ahora me doy cuenta de que tenemos el objeto CurrentColumn que podemos investigar a partir del evento, por lo que, aunque me gustaría más, ya que el evento argumenta, esto debería funcionar.

Además, un control más estricto del comportamiento de los detalles podría ser que los detalles solo se expandieran automáticamente en función de hacer clic en una columna en particular, en lugar de expandirse cada vez que se hace clic en cualquier parte de la fila.

Tal vez la clase base del objeto DataGridColumn podría tener una propiedad ExpandDetails que se puede establecer como verdadera de forma predeterminada para cada columna, lo que significaría que se hace clic en esa columna en particular y hace que la fila se expanda. Otros donde la propiedad es falsa no lo serían.

En mi diseño, por ejemplo, la primera columna es el tipo de elemento, como en Archivo o Carpeta, o Imagen o Foto, Audio, etc. Podría imaginar configurar esa columna para que sea la única que provoque el comportamiento de expansión automática, y luego un clic en la columna Ruta podría causar el comportamiento de "obtener una lista de esa ruta" que describí anteriormente.

En cuanto a la clasificación, parecería lógicamente importante implementar suficiente control para permitir a los diseñadores obtener una clasificación de varios niveles. No he realizado una investigación para determinar cómo el control actual podría admitir esto mediante eventos de enganche / anulación y devoluciones de llamada, pero no parece sencillo.

Finalmente, sé que es muy consciente de esto, pero (incluso cuando estoy pidiendo más funcionalidad), evitemos POR FAVOR intentar agregar un montón de comportamientos complejos que los usuarios pueden implementar ellos mismos en la parte superior de DataGrid. Entre estos que no implementaría en DataGrid están los que tienen que ver con el almacenamiento externo de filtros o clases, etc. También evitaría convertir este control en un clon de Excel.

-gracias, gran trabajo!
-mi

Grupos fijos: cuando se navega por conjuntos de datos con grupos grandes, debe haber un contexto sobre qué grupo (o grupos, es decir, ruta de navegación) se está viendo. Esto parece una característica de usabilidad esencial para todas las vistas jerárquicas basadas en listas: vistas de listas agrupadas, cuadrículas de datos y vistas de árbol.

Construiría el nuevo control DataGrid sobre el nuevo control WinUI ItemsRepeater. Y ese control expone su ItemsSource como un Objeto:
Object ItemsSource { get; set; };

@RBrid Volviendo a esto ~ 1 año después. Me di cuenta de que ItemsRepeater, aunque tiene un objeto ItemsSource, en realidad no tiene soporte integrado para las siguientes interfaces necesarias para trabajar con fuentes de datos virtualizadas:

• ISupportIncrementalLoading
• IItemsRangeInfo
• ISelectionInfo

-¿Qué hay de tener un MVP allí ahora para que podamos usar un Datagrid de c ++?