Mehr Ansichtsmodi. Werfen Sie einen Blick auf den Datei-Explorer und seine Symbolansichten. Das DataGrid sollte in der Lage sein, Icons/Elemente in einem Raster mit Gruppierung anzuzeigen, sowie die überschriebenen Zeilen und Spalten.

Ich weiß, dass dies möglicherweise nicht möglich ist oder außerhalb des Umfangs liegt - aber es ist ein Aspekt von WinUI vs. Win32, der nicht so einfach ist wie 1:1 - und eine moderne Version des Datei-Explorers oder der allgemeinen Dateidialoge - möglicherweise erforderlich einer solchen Kontrolle. Dies könnte dieses Steuerelement sein, kein internes benutzerdefiniertes Steuerelement.

Meine Wunschliste: Für mich beinhaltet ein gutes Datagrid standardmäßig alle folgenden Funktionen. Ich leihe mir einige Screenshots aus der HTML-Welt aus.

Filtern Sie ganz einfach die gesamte Seite mit der bevorzugten Zeilenanzahl.

Sichtbare Spalten auswählen/abwählen , Spaltensortierung , Kopieren , Drucken

Exportieren Sie Daten in ein bestimmtes Format.

Spaltenneuordnung durch Ziehen der Spalte.

Spaltenfilterung

Fixed Header - wo der Header auch beim Scrollen oben bleibt

Zeilendetails mit XAML-Vorlage für Details.

Zeilengruppierung

Zeilenreihenfolge per Drag & Drop

Die oben genannten Funktionen sollten meiner Meinung nach in allen Datagrids Standard sein.

Wenn Sie Datagrid von der HTML-Welt abheben möchten, würde ich auch Folgendes hinzufügen. Ich schaue mir oft ein Datagrid an und entscheide mich dann für eine Listenansicht, da dem Datagrid diese Funktionen fehlen.

Wischen Sie seitlich über die Zeile, um Funktionen wie Bearbeiten, Löschen, Markieren usw. einzuschließen.

Die oben genannten Funktionen behandeln hauptsächlich die "Präsentation von Daten" , was bei WinUI noch fehlt, ist das, was meiner Meinung nach eine native WinUI-Funktion (control ) wie das Microsoft Pivot Control sein sollte. um das Datagrid zu ergänzen.

MS hat bereits den Quellcode dafür und es war damals eine absolut großartige Kontrolle.

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

Jetzt behandeln Sie die Präsentation und Visualisierung von Daten, die das Minimum sein sollten, um WinUI von allen grundlegenden Funktionen abzuheben.

Am wichtigsten ist, dass es wirklich die Leistung "nativer Apps" zeigt, die großartige Animationen und visuell ansprechende Steuerelemente enthalten sollten, die leistungsstark sind und wirklich cool aussehen.

Ich kann noch einen Schritt weiter gehen und sagen, dass wir nach den oben genannten Funktionen (Visualisierungen) 2D/3D-Animationen einfügen können, die ein Konzept der Tiefe in den Daten erzeugen und uns in eine andere Stratosphäre führen, aber ich denke, das ist für einen anderen Tag; ))

Ein guter Ausgangspunkt ist Ihr Partner Telerik mit seinem RadDataGrid (UWP Open Source). Bei einem meiner Kunden habe ich es verwendet und es funktioniert tatsächlich gut. Es ist hyperschnell und vielseitig. Das einzige, was schwierig ist, ist ihr Code, es gibt keine Möglichkeit, etwas von ihrer Engine zu ändern, ohne die Architektur zu verstehen.

Ich würde erwarten, dass das neue DataGrid genauso leistungsfähig ist wie Telerik.

Ich freue mich sehr zu sehen, dass das WinUI-Team ein DataGrid-Steuerelement in Betracht zieht.

Die wesentlichsten Verbesserungen, die ich mir von einem neuen Steuerelement als Ersatz für das Toolkit DataGrid wünschen würde:

• Die Möglichkeit, eine DataGridRow nach Index abzurufen
• Ereignisse, die für die DataGridRows selbst spezifisch sind. Zum Beispiel DoubleTapped und RightTapped.
• Flüssiges Scrollen
• Eingabevalidierung für Zellenumbenennungen
• Eine speziell für Zeilensymbole entwickelte DataGridColumn
• Einfache Anpassung von Farben usw.

Die Option, eine Bearbeitungsschaltfläche zu haben, die ziehbare Symbole neben jeder Reihe platziert, um die Reihenfolge zu verschieben, wäre eine nützliche Funktion. Es wäre auch toll zu sehen, wie einige Schatten hinter der Reihe angehoben und verschoben werden (da eines der Hauptattribute von Fluent die Tiefe ist). Kleine Pfeile nach oben und unten können neben dem Ziehsymbol gut sein, um die Zeilen mit der Mauseingabe einfacher zu verschieben. Wenn eine Zeile mit den Pfeilen verschoben wird, wäre eine dezente Schiebeanimation eine nette Geste. Bei der Touch-Eingabe funktioniert möglicherweise auch die Option, eine Zeile zu halten und sie einfach zu verschieben, ohne dass die Bearbeitungstaste gedrückt werden muss. Ich bin mir nicht sicher, ob dies bereits unterstützt wird, aber ich konnte Auswahlkästchen wie im Datei-Explorer sehen, die deutlich machen, welche DataGrids die Zeilenauswahl unterstützen und nur die allgemeine UX verbessern. Die iOS-Erinnerungs-App enthält einige dieser Ideen (Beispiele unten abgebildet). Die iOS Stocks App hat auch einen ähnlichen Deal mit beweglichen Zeilen. Die meisten dieser Ideen würden auch gut für Spalten funktionieren.

@NoahFeller Diese Art von Aktion ist für eine

*Bearbeiten
Nachdem ich ein wenig darüber nachgedacht habe, sehe ich, wie eine solche Option nützlich sein kann. Ich denke jedoch definitiv nicht, dass dies das Standardverhalten sein sollte.

@NoahFeller Diese Art von Aktion ist für eine

*Bearbeiten
Nachdem ich ein wenig darüber nachgedacht habe, sehe ich, wie eine solche Option nützlich sein kann. Ich denke jedoch definitiv nicht, dass dies das Standardverhalten sein sollte.

Ja du hast wahrscheinlich recht @yaichenbaum. Ich stellte mir diese Vorschläge als die Möglichkeit vor, eine benutzerdefinierte Sortierung durchzuführen, und ich dachte, das Ziehen könnte dafür nützlich sein. Ich stimme also zu, definitiv nicht standardmäßig, aber es könnte als Option ziemlich nützlich sein. Danke für die Rückmeldung!

Die Einfachheit der WPF-Datatable-to-Datagrid-Funktion. Ich habe tatsächlich in der letzten Woche oder so gekämpft, um ein UWP-Datagrid zum Laufen zu bringen, wie ich es in WPF hatte, wo ich einfach ein Datagrid an eine Dataview binden und dann die Dataview von SQL mit einer datatable.defaultview füllen konnte. Das Raster zeigte dann nur die Datentabelle an. Es war erstaunlich einfach, und UWP hat dies bisher lächerlich kompliziert gemacht.

mach es plattformübergreifend

Ich möchte einen Einzelzellenauswahlmodus im Excel-Stil anfordern.
Das ultimative Ziel ist ein Modus mit dem genauen Verhalten wie ein WinForms DataGridView.

Eine Auswahl an Virtualisierungsoptionen, die verschiedene Anwendungsfälle unterstützen können (von einfachen Scroll-Virtualisierungsoptionen wie Recycling bis hin zu anderen Konzepten wie Daten-Paging)
Häufig (in ähnlichen Desktop-Steuerelementen, die dies unterstützen) schlagen einige dieser Optionen fehl, wenn sie mit benutzerdefinierten Vorlagen für Spalten mit eindeutigen Daten verwendet werden. Je mehr sie in diesen Fällen unterstützen können, desto besser.

Wenn möglich, sollte der Vorschlag von Paging Control #268 synchronisiert und alle erforderlichen Hooks zum DataGrid-Steuerelement hinzugefügt werden.

Das sind gute Neuigkeiten! Ich habe eine Weile auf etwas Offizielles an der DataGrid-Front gewartet, seit es im Community-Toolkit erschienen ist. Dies ist wirklich das letzte Steuerelement, das in WinUI 3.0 fehlt, für das das Community-Toolkit keine gute Alternative bietet.

Zuerst erfinden Sie bitte das Rad nicht neu. Als Basis beginnen Sie mit der WPF-Implementierung des DataGrid (ich weiß, dass Sie den Code nicht verwenden können, aber bitte verwenden Sie 100% der API) - NICHT die Silverlight-Implementierung. Das WPF DataGrid war viel umfassender und weist in meinen Tests weniger Fehler auf.

Bei der Verwendung des Community-Toolkits DataGrid habe ich auch die folgenden API-Ergänzungen angefordert, die für verschiedene Anwendungsfälle diskutiert wurden :

• RowPressed : Wie oben besprochen. Zeigt an, dass eine Zeile gedrückt wurde, sodass eine weitere Verarbeitung oder Kontextmenüs erfolgen können.
• RowDoublePressed : Wie RowPressed, nur die Doppelklick-Version.
• ColumnHeaderPressed : Tritt immer dann auf, wenn eine Spaltenüberschrift gedrückt wird. Muss Vorrang vor internen Aktualisierungen der Sortierrichtung haben. Dies ermöglicht benutzerdefinierte Filtermenüs oder Rechtsklickoptionen zum Ein- und Ausschalten von Spalten.
• ColumnHeaderDoublePressed : Wie ColumnHeaderPressed, nur die Doppelklick-Version.
• ColumnHeaderWidthChanged : Tritt ein, wenn der Benutzer die Breite einer Spaltenüberschrift ändert. Dadurch können diese Informationen sauber gespeichert werden. Dies wird häufig beim Wiederherstellen des UI-Status benötigt.

Ich habe auch weiterhin viele Probleme damit, dass die Community von Takeit DataGrid die Bildlaufposition nach oben zurückgesetzt hat, nachdem ItemsSource geändert wurde. Dies muss behoben werden, damit der Offset wie in WPF beibehalten wird; Wir müssen dies jedoch auch kontrollieren können, weshalb ich auch die folgende API vorschlagen würde:

• FirstRowInView() : Gibt die erste sichtbare Zeile im DataGrid zurück, das zum Wiederherstellen des Zustands verwendet wird.
• VerticalOffset : Holen/Setzen Sie erneut, um den Status der Bildlaufleiste wiederherzustellen
• HorizontalOffset : Get/Set, um den Status der Bildlaufleiste wiederherzustellen

@RBrid auch mit einiger Analyse hilft hier :

Vorgeschlagene neue Events und einige Verbesserungen an bereits existierenden Events:

| Ereignis | Kommentare |
| :--- | :--- |
| ContextRequestedForColumnHeader | Um das Anzeigen eines Kontextmenüs (oder eines anderen Flyouts) zu unterstützen, wenn mit der rechten Maustaste auf eine Spaltenüberschrift geklickt wird. Wie Windows.UI.Xaml.UIElement.ContextRequested jedoch für Spaltenüberschriften anstelle des gesamten DataGrids. |
| ContextCanceledForColumnHeader | Wie Windows.UI.Xaml.UIElement.ContextCanceled jedoch für Spaltenüberschriften anstelle des gesamten DataGrids. |
| ContextRequestedForRow | Um das Anzeigen eines Kontextmenüs (oder eines anderen Flyouts) zu unterstützen, wenn mit der rechten Maustaste auf eine Zeile geklickt wird. Wie Windows.UI.Xaml.UIElement.ContextRequested jedoch für Zeilen anstelle des gesamten DataGrids. |
| ContextCanceledForRow | Wie Windows.UI.Xaml.UIElement.ContextCanceled jedoch für Zeilen anstelle des gesamten DataGrids. |
| RowTapped | Beachten Sie auch den Fall, dass Sie auf eine bereits ausgewählte Zeile tippen. |
| RowDoubleTapped | Wie Windows.UI.Xaml.UIElement.DoubleTapped jedoch für Zeilen anstelle des gesamten DataGrids. |
| RowRightTapped | Das gleiche wie Windows.UI.Xaml.UIElement.RightTapped jedoch für Zeilen anstelle des gesamten DataGrids. Siehe auch ContextRequestedForRow . |
| PointerPressedInRow | Das gleiche wie Windows.UI.Xaml.UIElement.PointerPressed jedoch für Zeilen anstelle des gesamten DataGrids. |
| PointerReleasedInRow | Wie Windows.UI.Xaml.UIElement.PointerReleased jedoch für Zeilen anstelle des gesamten DataGrids. |
| PointerMovedInRow | Wie Windows.UI.Xaml.UIElement.PointerMoved jedoch für Zeilen anstelle des gesamten DataGrids. Möglicherweise würde PointerMovedInRow nur ausgelöst, während der Zeiger erfasst wird. |
| ColumnHeaderTapped | Beachten Sie auch den Fall, dass Sie auf eine bereits ausgewählte Spaltenüberschrift tippen. |
| ColumnHeaderDoubleTapped | Wie Windows.UI.Xaml.UIElement.DoubleTapped jedoch für Spaltenüberschriften anstelle des gesamten DataGrids. |
| ColumnHeaderRightTapped | Wie Windows.UI.Xaml.UIElement.RightTapped jedoch für Spaltenüberschriften anstelle des gesamten DataGrids. Siehe auch ContextRequestedForColumnHeader . |
| ColumnHeaderWidthChanged | Alternativ könnte ColumnHeaderResized . Fügen Sie in das Ereignis args eine boolesche Eigenschaft ein, die angibt, ob sie vom Benutzer oder programmgesteuert geändert wurde. Natürlich sollten die Ereignisargumente auch angeben, welche Spaltenüberschrift in der Größe geändert/geändert wurde. |
| SortOrderChanged | Sollte ausgelöst werden, wenn sich die Liste der ausgewählten Spaltenüberschriften ändert. Wird auch ausgelöst, wenn eine der ausgewählten Spalten zwischen aufsteigender und absteigender Reihenfolge umgeschaltet wird. Fügen Sie in das Ereignis args eine boolesche Eigenschaft ein, die angibt, ob die Sortierreihenfolge vom Benutzer oder programmgesteuert geändert wurde. Siehe auch bereits vorhandenes Ereignis Sorting . Ich denke, ein neues Ereignis SortOrderChanged würde ausgelöst, nachdem das Ereignis Sorting ausgelöst wurde, wenn die Sortierung nicht abgebrochen wird. |
| Sorting | Ist bereits vorhanden, aber erwägen Sie, in Ereignisargumenten eine einstellbare boolesche Eigenschaft hinzuzufügen, die das Abbrechen der Sortieranforderung ermöglicht. Beispielsweise kann die Sortierung ungültig sein oder nicht durchgeführt werden und muss abgebrochen werden. Fügen Sie außerdem eine boolesche Eigenschaft hinzu, um anzugeben, ob die Sortierung vom Benutzer oder programmgesteuert angefordert wurde. |
| ColumnSortDirectionChanged | Dieses Ereignis könnte erstellt werden, aber es könnte unnötig sein, wenn das oben genannte Ereignis SortOrderChanged erzeugt wird, wenn SortOrderChanged auch ausgelöst wird, wenn sich die Sortierrichtung ändert. |
| ColumnDisplayIndexChanged | Ist bereits vorhanden, aber erwägen Sie, eine boolesche Eigenschaft (in Ereignisargumenten) hinzuzufügen, die angibt, ob sie vom Benutzer oder programmgesteuert geändert wurde. Bitte dokumentieren Sie auch, warum es notwendig ist, sowohl die ColumnDisplayIndexChanged als auch die ColumnReordered Ereignisse zu haben. Beseitigen Sie alternativ eines dieser Ereignisse. |
| ColumnReordered | Ist bereits vorhanden, aber erwägen Sie, eine boolesche Eigenschaft hinzuzufügen, die angibt, ob sie vom Benutzer oder programmgesteuert geändert wurde. |
| SelectionChanged | Ist bereits vorhanden, aber erwägen Sie, eine boolesche Eigenschaft (in Ereignisargumenten) hinzuzufügen, die angibt, ob sie vom Benutzer oder programmgesteuert geändert wurde. |
| CopyingRowClipboardContent | Existiert bereits, aber erwägen Sie, den Ereignisargumenten eine boolesche Eigenschaft hinzuzufügen, die angibt, ob die Operation ausgeschnitten statt kopiert wird. Alternativ erstellen Sie ein separates Ereignis für den Schnitt. |
| CuttingRowClipboardContent | Existiert nicht. Ziehen Sie in Erwägung, ein Ereignis zu erstellen, das ausgelöst wird, wenn der Benutzer versucht, Zeilen auszuschneiden (über Strg-X-Hotkey, Kontextmenü oder anderweitig). Alternativ können Sie die oben genannte boolesche Eigenschaft erstellen, die es ermöglicht, dass CopyingRowClipboardContent sowohl für die Kopier- als auch für die Ausschneideoperationen ausgelöst wird |
| PastingRowClipboardContent | Existiert nicht. Ziehen Sie in Erwägung, ein Ereignis zu erstellen, das ausgelöst wird, wenn der Benutzer versucht, einzufügen (über Strg-V-Hotkey, Kontextmenü oder auf andere Weise). |

Ich denke, das wichtigste Feature für mich wäre die Möglichkeit, problemlos eine Million Zeilen oder mehr zu verarbeiten, ohne Millionen Zeilen in den Speicher laden zu müssen. Dafür ist die ISupportIncrementalLoading-Schnittstelle nicht gut genug, da die Bildlaufleiste nur anzeigt, wie viele Zeilen Sie bisher geladen haben (nicht die Gesamtzahl), und um zu Zeile 1 Million zu gelangen, müssten Sie bis zum Ende weiterscrollen und über und lade immer mehr Daten und hoffe, dass mir der Speicher nicht ausgeht. Aber wenn ich weiß, dass ich 1 Million Datensätze habe, lass mich das dem Datagrid mitteilen, und wenn ich schnell scrolle oder zum Ende springe, kann ich aufgefordert werden, nur die letzten paar Zeilen anzugeben.
Stellen Sie sich vor, Sie scrollen durch eine Liste von Zeilen in einer Datenbank, die ich dynamisch einziehe.

Ich denke, das wichtigste Feature für mich wäre die Möglichkeit, problemlos eine Million Zeilen oder mehr zu verarbeiten, ohne Millionen Zeilen in den Speicher laden zu müssen. Dafür ist die ISupportIncrementalLoading-Schnittstelle nicht gut genug, da die Bildlaufleiste nur anzeigt, wie viele Zeilen Sie bisher geladen haben (nicht die Gesamtzahl), und um zu Zeile 1 Million zu gelangen, müssten Sie bis zum Ende weiterscrollen und über und lade immer mehr Daten und hoffe, dass mir der Speicher nicht ausgeht. Aber wenn ich weiß, dass ich 1 Million Datensätze habe, lass mich das dem Datagrid mitteilen, und wenn ich schnell scrolle oder zum Ende springe, kann ich aufgefordert werden, nur die letzten paar Zeilen anzugeben.
Stellen Sie sich vor, Sie scrollen durch eine Liste von Zeilen in einer Datenbank, die ich dynamisch einziehe.

Dies.

„Modern“ bedeutet leicht und schnell, und bei Unternehmensanwendungen geht es im Allgemeinen darum, Tonnen von internen Daten zu sortieren, um die entsprechenden Datensätze zu finden und zu durchsuchen. Paging, Sortieren, asynchrones inkrementelles Laden, endloses Scrollen – all dies sind Grundnahrungsmittel von Desktop-Apps, die Datenraster nutzen.

MS sollte eine Beispiel-App erstellen, die diese Funktionen im neuen Raster hervorhebt, und im Laufe der Zeit Feedback von Unternehmensentwicklern sammeln, um diese Erfahrungen zu verbessern. Lassen Sie es von einem großen Datensatz wie World Wide Importers ausführen, um seine Wirksamkeit zu demonstrieren.

@dotMorten

Ich denke, das wichtigste Feature für mich wäre die Möglichkeit, problemlos eine Million Zeilen oder mehr zu verarbeiten, ohne Millionen Zeilen in den Speicher laden zu müssen.

Das wünsche ich mir auch. Um bei der Unterstützung einer Million Zeilen zu helfen (und ich meine unterstützen, nicht unbedingt die vollständige Lösung), schlage ich vor, dass DataGrid seine aktuelle Datenbindungstechnik optional machen sollte. Ich halte derzeit eine Datenbindung für obligatorisch (es sei denn, mein Wissen ist mit der neuesten Version von DataGrid nicht mehr aktuell). DataGrid sollte nicht die Verwendung von Windows.UI.Xaml.Data.Binding als einzige unterstützte Methode zum Abrufen der Werte für jede Zelle/Spalte in jeder sichtbaren Zeile erfordern.

Ich schlage vor, dass DataGrid Apps erlaubt, DataGrid eine Delegat- oder Schnittstelleninstanz zu geben, die DataGrid aufruft, wenn DataGrid den Wert einer Zelle/Spalte in einer Zeile abrufen muss (alternativ könnte dieser Delegat oder diese Schnittstelle die gesamte Zeile abrufen – alle Spaltenwerte). für eine bestimmte Zeile).

Im Idealfall (wenn möglich) würde DataGrid diesem Delegat oder dieser Schnittstelle ermöglichen, asynchron zu arbeiten. Beispielsweise kann der Delegat oder die Schnittstelle Task oder IAsyncOperation<TResult> anstatt sofort den angeforderten Wert zurückzugeben.

Alternativ ist eine asynchrone Unterstützung auch ohne Task und IAsyncOperation<TResult> , wenn DataGrid ähnlich wie folgt vorgeht:

1. DataGrid entscheidet, dass es den Wert von Zelle/Spalte 5 in Zeilen-ID 50001 abrufen muss. Alternativ entscheidet DataGrid, alle Spaltenwerte für Zeilen-ID 50001 abzurufen.
2. DataGrid ruft eine Delegat- oder Schnittstelleninstanz oder einen Ereignishandler auf, der die App benachrichtigt, dass DataGrid das Laden der Datenwerte der angegebenen Spalte/Zeile oder der gesamten Zeile angefordert hat.
3. Die App ruft die angeforderten Zeilendaten asynchron ab. Es könnte beispielsweise asynchron eine SQL-Datenbankabfrage ausführen.
4. Die App beendet den Abruf der angeforderten Zeilendaten. Die App ruft eine Methode in DataGrid auf, die die Zeilendaten an DataGrid übergibt.
5. DataGrid zeigt die Zeilendaten an oder führt alles andere aus, um die Daten zu verwenden.

Erstmal, wow!! Vielen Dank an alle, die ihre Ideen einbringen. Ich habe unten ein paar konkrete Antworten, aber insgesamt wollte ich sagen, dass ich eine Menge dieser Kommentare aufspare und es wirklich genieße, zu hören, wie wir ein fantastisches modernes DataGrid aufbauen können. Weiter so!

@Pinox vielen Dank für diese ausführliche Antwort und die Screenshots. Ihre Wunschliste ist großartig (besonders diese coolen Animationen!) - Ich stimme zu, dass diese Funktionen in HTML eine gute Inspirationsquelle sind und einfach sind, aber die Lebensqualität erheblich verbessern würden. Werde diesen Kommentar auf jeden Fall zum späteren Nachschlagen speichern!

@verelpode , @robloo , @duke7553 JA zu DataGrid-spezifischen Ereignissen! Ich danke Ihnen allen für die Details, die Sie in diese gesteckt haben. Da wir für Touch-First und für eine Vielzahl von Eingaben konzipieren, sollten solche Events unbedingt umgesetzt werden!

@dotMorten , @jkewley , @verelpode Leistung ist definitiv eine der Hauptmotivationen für dieses Projekt und eine der wichtigsten Verbesserungen, die wir durch eine neue Datenvirtualisierungsgeschichte und den Einsatz moderner Steuerelemente wie ItemsRepeater implementieren möchten. Wir werden Sie alle auf dem Laufenden halten, sobald wir mehr Details haben - aber nochmals vielen Dank für diese Details, die Sie vorgeschlagen haben.

@Laz3rPanth3r , @robloo , @keeganatorr Wir hören Ihnen laut und deutlich, dass Sie die DataGrids mögen, die zu WPF und anderen UI-Frameworks gehören - wir berücksichtigen dies definitiv in diesem Refresh!

Danke für die tolle Arbeit an DataGrid und die Bitte um Feedback! Hier sind einige weitere Verbesserungsvorschläge.

Benötigen Sie weitere Unterklassen von DataGridColumn

Die aktuellen Unterklassen/Implementierungen von DataGridColumn reichen nicht aus. Ich schlage vor, die folgenden neuen Unterklassen von DataGridColumn :

| Vorgeschlagene Unterklasse | Beschreibung |
| :--- | :--- |
| DataGridIconColumn | Eine allgemeine Anforderung besteht darin, in jeder Zeile einer Liste ein Symbol anzuzeigen, daher empfehle ich, eine DataGridColumn Unterklasse namens DataGridIconColumn erstellen, die den abgerufenen Zellenwert in Windows.UI.Xaml.Controls.IconSource umwandelt und die IconSource Instanz (in jeder Zelle wird eine andere IconSource Instanz gerendert). |
| DataGridImageColumn | DataGridImageColumn sollte genauso funktionieren wie das vorgeschlagene DataGridIconColumn außer dass es Windows.UI.Xaml.Media.ImageSource anstelle von Windows.UI.Xaml.Controls.IconSource rendern sollte. |
| DataGridDateTimeColumn | Zeigt je nach Einstellung Datum und/oder Uhrzeit an. Wandelt den Zellenwert in System.DateTimeOffset oder System.DateTime (beide unterstützt) um und wandelt ihn in Text um, der in der Zelle angezeigt werden soll. Die Konvertierung in Text sollte durch Formatierungseinstellungen/Eigenschaften in der Klasse DataGridDateTimeColumn gesteuert werden. Natürlich muss auch die Sortierung nach Datum/Uhrzeit unterstützt werden. |
| DataGridTimeSpanColumn | Wandelt den Zellenwert in System.TimeSpan und wandelt ihn in Text um, der in der Zelle angezeigt werden soll. Die Konvertierung in Text sollte durch die Formatierungseinstellungen/Eigenschaften in der Klasse DataGridTimeSpanColumn gesteuert werden. Natürlich muss auch das Sortieren unterstützt werden, und es muss die TimeSpan Instanzen sortieren, nicht den angezeigten Text. |
| DataGridDataSizeColumn | Wandelt den Zellenwert in System.Int64 , UInt64 , Int32 oder UInt32 (alle unterstützt) und wandelt ihn in eine Größe in Bytes (als Text) um ) Angezeigt werden. Beispielsweise würde 1572864 als "1,5 MB" angezeigt, weil 1572864/1024/1024 = 1,5. Die Konvertierung in Text sollte durch Einstellungen/Eigenschaften in der Klasse DataGridDataSizeColumn gesteuert werden. Die Sortierung muss mit dem ursprünglichen ganzzahligen Wert und nicht mit dem angezeigten Text durchgeführt werden. |
| DataGridCustomColumn | Dies sollte ähnlich wie das bereits vorhandene DataGridTemplateColumn funktionieren, außer ohne das Windows.UI.Xaml.DataTemplate . Es sollte einen Delegaten/Callback oder ein Ereignis aufrufen, um den angezeigten GUI-Element-Unterbaum zu generieren und/oder zu aktualisieren. |
| DataGridTextColumn | Existiert bereits, aber erwägen Sie das Hinzufügen von Eigenschaften oder Ereignissen, die es Apps ermöglichen, die Objekt-zu-Text-Konvertierung und die Vergleichsfunktion zum Sortieren zu überschreiben. Ich erkläre dies später in meiner Nachricht genauer. |

DataGridCustomColumn würde so aussehen:

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
}

Wenn das Ereignis DataGridCustomColumn.DisplayingCell ausgelöst wird, sollte der Ereignishandler seinen eigenen UIElement Unterbaum generieren oder aktualisieren, um DataGridDisplayingCellEventArgs.CellValue anzuzeigen, und die Eigenschaft DataGridDisplayingCellEventArgs.CellUIElement darauf setzen UIElement Unterbaum, und dann zeigt DataGrid ihn an.

Wenn DataGrid dieses Ereignis das nächste Mal auslöst, sollte DataGrid die Eigenschaft DataGridDisplayingCellEventArgs.CellUIElement auf die UIElement Instanz setzen, die zuvor vom Ereignishandler generiert wurde, damit der Ereignishandler wiederverwenden/recyceln und aktualisieren kann der gleiche UIElement Unterbaum (möglicherweise mit einem anderen Wert in DataGridDisplayingCellEventArgs.CellValue ). Der Ereignishandler darf entweder denselben UIElement Unterbaum wiederverwenden ODER die Eigenschaft DataGridDisplayingCellEventArgs.CellUIElement auf einen neu erstellten UIElement Unterbaum setzen.

Ziehen Sie auch die Möglichkeit in Betracht, das neue DisplayingCell -Ereignis direkt in der Basisklasse DataGridColumn , anstatt die Unterklasse DataGridCustomColumn . Somit könnte das Ereignis DataGridColumn.DisplayingCell eine Anpassung oder Überschreibung der generierten UIElement für jede Unterklasse von DataGridColumn .

Im bereits existierenden DataGridTextColumn wird der Zellenwert/das Objekt derzeit in Text zur Anzeige umgewandelt, indem System.Object.ToString . Erwägen Sie, einen Delegaten/Rückruf oder ein Ereignis zu erstellen, das es Apps ermöglicht, diese Wert-zu-Text-Konvertierung zu überschreiben. Denken Sie auch an eine Eigenschaft, die es Apps ermöglicht, eine System.Collections.IComparer Instanz anzugeben, um das Sortierverhalten zu überschreiben.

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

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

Alternativ können Sie, anstatt die Eigenschaft Comparer in DataGridTextColumn erstellen, die Möglichkeit in Betracht ziehen, die Eigenschaft Comparer direkt in der Basisklasse DataGridColumn zu erstellen, um dies zu ermöglichen Apps, um das Sortierverhalten für alle Unterklassen von DataGridColumn zu steuern.

Ebenso könnte die Eigenschaft CellValueToToStringConverter auch in der Basisklasse DataGridColumn da es nützlich wäre, jeden Zellenwert in Text umwandeln zu können, unabhängig von der Unterklasse von DataGridColumn wird genutzt. Wenn Sie beispielsweise eine Zeile in die Zwischenablage kopieren, könnte jeder Zellenwert in Text umgewandelt werden. (Sowohl Text- als auch Nicht-Text-Formate können gleichzeitig in der Zwischenablage abgelegt werden – Apps tun dies normalerweise, um die Kompatibilität mit anderen Apps zu erhöhen.)

Neu sortieren, wenn ein DataGridIconColumn oder DataGridImageColumn ausgewählt ist: Offensichtlich kann DataGrid keine Symbole oder Bilder sortieren, daher könnte es eine dieser Lösungen verwenden:

• Verbieten Sie Endbenutzern einfach, eine Spaltenüberschrift vom Typ DataGridIconColumn oder DataGridImageColumn auszuwählen (zu sortieren).
• Erstellen Sie eine Eigenschaft AlternativeText in der Klasse IconSource . Wenn DataGridIconColumn die Zeilen sortiert oder die Zelle in Text für die Zwischenablage/Kopie umwandelt, wird die Eigenschaft AlternativeText .
• Erstellen Sie eine einstellbare Comparer Eigenschaft (vom Typ System.Collections.IComparer ) in entweder DataGridColumn oder DataGridIconColumn .

Zugriff auf ausgewählte Zeilen/Elemente

Bitte erwägen Sie, die Funktionalität zum Abrufen und Festlegen der ausgewählten Zeilen/Elemente zu verbessern, da die aktuelle Funktionalität nicht ausreicht. Derzeit existieren diese Eigenschaften:

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

Ich habe festgestellt, dass ich manchmal Zugriff auf die DataGridRow-Instanzen der ausgewählten Zeilen benötige, daher hoffe ich, dass die folgenden Eigenschaften zu DataGrid hinzugefügt werden können:

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

Wenn das oben Genannte zu schwierig zu implementieren ist, ist die folgende schreibgeschützte Variante weniger leistungsfähig, aber dennoch hilfreich:

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

Wenn DataGridRow-Instanzen recycelt werden dürfen, sollte die Dokumentation zu den obigen Eigenschaften warnen, dass die zurückgegebenen Informationen nur vorübergehend gültig sind, also sofort gelesen/verwendet und nicht für längere Zeit aufbewahrt werden sollten.

Außerdem ermöglicht die bereits vorhandene Eigenschaft SelectedIndex Zugriff auf einen ausgewählten Index, aber wie sieht es mit dem Zugriff auf alle ausgewählten Elemente aus? Daher schlage ich vor, die folgende Eigenschaft SelectedIndexes erstellen:

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

Ich persönlich finde den Namen "SelectedIndex" verwirrend, da DataGrid oft in Verbindung mit einer Datenbank verwendet wird und der Begriff "Index" in einer Datenbank eine ganz andere Bedeutung hat, daher schlage ich vor, die Eigenschaften wie folgt umzubenennen, erwarte aber, dass mein Namensvorschlag wird abgelehnt:

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

Ich wünsche mir auch die Möglichkeit, die angegebene DataGridRow und/oder DataGridColumn in die Ansicht zu scrollen. Derzeit existiert diese Methode:

public void ScrollIntoView(object item, DataGridColumn column);

Ich schlage vor, die bereits vorhandene Methode ScrollIntoView durch diese beiden Methoden zu ersetzen:

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

Abrufen und Festlegen der Sortierreihenfolge mit einem Treffer

Wenn Apps geöffnet und geschlossen werden, müssen sie die Endbenutzerkonfiguration des DataGrid speichern und wiederherstellen können, einschließlich der Sortierreihenfolge und anderer Einstellungen. Sortierreihenfolge bedeutet die Liste der Spalten, die vom Benutzer ausgewählt wurden. Beachten Sie, dass dies eine Liste ist, keine einzelne Spalte. Es können mehrere Spalten gleichzeitig ausgewählt werden, d. h. die primäre Spalte zum Sortieren und die sekundäre Spalte zum Sortieren und die tertiäre Spalte zum Sortieren usw.

Daher könnte die folgende Eigenschaft in DataGrid erstellt werden, aber eigentlich ist dies nur die erste Idee und nicht ideal:

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

Das Obige ist nicht ideal, da es das Speichern und Wiederherstellen von DataGridColumn.SortDirection jeder Spalte in einem Treffer nicht unterstützt . Mir ist klar, dass Apps dies in mehreren Schritten tun können:

1. Setzen Sie die vorgeschlagene Eigenschaft SortOrder auf die Liste der ausgewählten Spalten.
2. Legen Sie die Eigenschaft SortDirection für jede der ausgewählten Spalten fest (wiederholen Sie diesen Schritt für jede Spalte).

Das ist immer noch problematisch, da es sich um mehrere Treffer handelt, was bedeutet, dass es mehrere zeitaufwändige Umwege des DataGrids verursacht. Endbenutzer könnten eine erhebliche Verzögerung in einem DataGrid mit einer großen Anzahl von Zeilen bemerken und erleiden, wenn das DataGrid unnötigerweise mehrmals umsortiert wird. Um dieses Problem zu beseitigen, schlage ich die folgende Lösung vor, die es Apps ermöglicht, die vollständige Sortierreihenfolge mit einem Treffer wiederherzustellen und nicht mehr als einen einzigen Ausweg zu verursachen.

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

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

Beachten Sie, dass ich oben absichtlich IReadOnlyList<DataGridColumnAndDirection> nicht IList<DataGridColumnAndDirection> da Apps nicht in der Lage sein sollten, die von der Eigenschaft SortOrder Liste zu ändern. Anstatt die Liste zu ändern, sollten Apps die Eigenschaft SortOrder auf eine Liste setzen, die DataGrid kopiert und verwendet, um die gesamte Sortierreihenfolgeliste vollständig zu ersetzen. Somit würde es mit einem Schlag funktionieren und mehrere teure Resorts vermeiden.

Wenn DataGrid.SortOrder auf eine neue Liste gesetzt wird, würde DataGrid auch die entsprechende DataGridColumn.SortDirection Eigenschaft in jeder Spalte in der neuen SortOrder Liste festlegen, ohne jedoch mehrere Umsortierungen zu verursachen. Somit entspricht DataGrid.SortOrder[i].SortDirection DataGridColumn.SortDirection .

Abrufen und Festlegen der angezeigten Spaltenreihenfolge in einem Treffer

Wenn Apps geöffnet und geschlossen werden, müssen sie die Spaltenreihenfolge des Endbenutzers speichern und wiederherstellen können, vorzugsweise mit einem Schlag. Ich weiß, dass die bereits vorhandene Eigenschaft DataGridColumn.DisplayIndex einstellbar ist, daher könnten Apps theoretisch die Konfiguration des Endbenutzers wiederherstellen, indem sie alle Spalten in DataGrid.Columns durchlaufen und jeweils die DisplayIndex festlegen, aber Dies kann zu Fehlern führen. Beispielsweise kann DisplayIndex fehlschlagen oder sich unerwartet verhalten, wenn eine App die DisplayIndex einer Spalte vorübergehend auf die gleichen DisplayIndex einer anderen Spalte setzen muss. Wenn es nicht in einem Treffer ausgeführt wird, kann es mehrere teure Neuzeichnungen und/oder Neuberechnungen auslösen.

Daher schlage ich vor, eine ColumnDisplayOrder Eigenschaft in DataGrid zu erstellen:

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

Das gleiche wie ich zuvor für SortOrder , ist ColumnDisplayOrder absichtlich IReadOnlyList<DataGridColumn> nicht IList<DataGridColumn> weil es mit einem Schlag funktionieren sollte.
Wenn DataGrid.ColumnDisplayOrder auf eine neue Liste gesetzt wird, aktualisiert DataGrid die DataGridColumn.DisplayIndex jeder Spalte entsprechend.

Endbenutzern erlauben, Spalten auszublenden/einzublenden

In Übereinstimmung mit den bereits vorhandenen Eigenschaften DataGridColumn.CanUserReorder usw. schlage ich vor, eine Eigenschaft CanUserChangeVisibility in DataGridColumn . Wenn DataGridColumn.CanUserChangeVisibility wahr ist, kann der Endbenutzer Änderungen an der Eigenschaft DataGridColumn.Visibility vornehmen.

Unterstützung von GUI-Elementen, die zur Laufzeit dynamisch generiert werden

Erlauben Sie, dass die GUI mit Zeilendetails generiert wird, ohne dass DataGrid.RowDetailsTemplate ( Windows.UI.Xaml.DataTemplate ) verwendet werden muss. Um dies zu erreichen, müssen einige Gedanken in die API gesteckt werden, aber hier ist meine erste Idee, wie es geht: Vielleicht tun Sie es über das bereits vorhandene Ereignis DataGrid.LoadingRow indem Sie die Eigenschaft DataGridRowDetailsEventArgs.DetailsElement ändern einstellbar sein, damit der Ereignishandler das UIElement selbst generieren (oder aktualisieren) und an DataGrid übergeben kann, indem die Eigenschaft DetailsElement .

Der Grund, warum die obligatorische Verwendung von Windows.UI.Xaml.DataTemplate problematisch ist: Obwohl Templates ein gutes Feature sind, erwartet das Template-Konzept ein vorab erstelltes, unveränderliches XAML-Snippet/Dokument, das vom Entwickler im Voraus geschrieben wurde. Daher sind Vorlagen ein Problem, wenn die App die GUI zur Laufzeit dynamisch generieren muss. Daher wünsche ich mir die oben genannten Alternativen zu DataTemplate .

Drag-and-Drop von Reihen nach innen und außen

Ich schlage vor, die Möglichkeit bereitzustellen, ausgehendes Drag-and-Drop von Zeilen optional zu aktivieren. DataGrid würde das Ziehen implementieren, aber nicht das Ablegen. Wenn das Löschen auftritt, würde DataGrid ein Ereignis auslösen und die App antwortet auf das Ereignis, um die gewünschte Aktion auszuführen, wenn die Zeile außerhalb des DataGrid abgelegt wird.

Auch die Möglichkeit, eingehendes Drag-and-Drop von Zeilen oder Elementen/Objekten optional zu aktivieren. DataGrid akzeptiert eingehende Drag-and-Drop-Operationen, implementiert jedoch nicht das Ablegen. DataGrid würde ein Ereignis auslösen, wenn die Zeile/das Element/das Objekt gelöscht wird, und die App reagiert auf das Ereignis, um die gewünschte Aktion auszuführen, wenn die Zeile im DataGrid abgelegt wird.

Individuelle Zellhintergründe

Wir haben eine Funktionsanfrage von einem Kunden, der möchte, dass einzelne Zellen zu bestimmten Zeiten (durch Ändern der Hintergrundfarbe / des Pinsels der Zelle) hervorgehoben werden (z. B. wenn unsere App Änderungen oder wichtige Werte oder gefährliche Werte erkennt, die die Sicherheitsgrenzen überschreiten usw.).

Daher könnte ich eine DataGridCell.Background Eigenschaft (vom Typ Brush ) vorschlagen, aber ich denke, diese Vorgehensweise ist wahrscheinlich fehlerhaft, weil DataGrid DataGridCell Instanzen recycelt, nicht wahr? Daher denke ich, dass das Hervorheben einzelner Zellen durch Festlegen einer DataGridCell.Background Eigenschaft eine unzuverlässige Lösung wäre.

Ein besserer Weg könnte über das Ereignis DataGridColumn.DisplayingCell , das ich in meiner vorherigen Nachricht vorgeschlagen habe. Der Ereignishandler könnte eine Eigenschaft CellBackgroundBrush in DataGridDisplayingCellEventArgs .

Das Abrufen von Daten (Zellenwerte) durch Dumb-Down DataGrid

Ich weiß, dass "dumm" sehr schlecht klingt, aber in Wirklichkeit würde ich es lieben, wenn DataGrid im Bereich des Datenabrufs (Abrufen der von DataGrid anzuzeigenden Zellenwerte) dumm gemacht würde.

Derzeit versucht DataGrid, den Datenabruf auf bequeme automatische Weise über seine Eigenschaft DataGrid.ItemsSource plus Datenbindungstechniken (die Eigenschaft DataGridBoundColumn.Binding ) und Schnittstellen wie System.ComponentModel.INotifyPropertyChanged durchzuführen.

Ja, Datenbindung ist eine praktische Funktion, aber eigentlich würde ich DataGrid viel lieber _weniger_ in dieser Abteilung machen lassen! Mehrere Microsoft-Komponenten bereiten mir tatsächlich große Schwierigkeiten, weil sie versuchen, schlau zu sein, aber letztendlich zu schlau sind . Insgesamt hätte ich weniger Schwierigkeiten und weniger Arbeit, wenn diese Komponenten aufhören würden, so intelligent/automatisch/praktisch zu sein. Beim Entwerfen eines automatischen Verhaltens finde ich es lohnenswert, daran zu denken, dass sich die Automatik großartig anhört, aber das Potenzial hat, nach hinten loszugehen.

_"Lass es mich einfach alleine machen."_
Manchmal besteht die beste Lösung darin, Apps einfach die Aufgabe selbst ausführen zu lassen, anstatt sie in einer Komponente wie DataGrid "automatisch" auszuführen. Ich wünschte, DataGrid würde es mir ermöglichen, den Datenabruf vollständig selbst durchzuführen, anstatt zu versuchen, die Daten automatisch über die Eigenschaften DataGridBoundColumn.Binding und DataGrid.ItemsSource abzurufen.

Idealerweise möchte ich die Anforderung eliminieren, die Eigenschaft DataGrid.ItemsSource zu verwenden, um die Artikel bereitzustellen. @dotMorten erwähnte eine Million Zeilen. Derzeit macht es DataGrid für Apps obligatorisch, DataGrid.ItemsSource festzulegen, aber es ist unpraktisch, ein Listenobjekt zu erstellen, das eine Million Elemente enthält. Daher wünsche ich mir, dass DataGrid aufhört, in der Datenabrufabteilung schlau zu sein und mich stattdessen den Datenabruf vollständig selbst durchführen lässt, ohne DataGridBoundColumn.Binding und DataGrid.ItemsSource .

@anawishnoff schrieb:

Die Leistung ist definitiv eine der Hauptmotivationen für dieses Projekt und eine der wichtigsten Verbesserungen, die wir durch eine neue Datenvirtualisierungsgeschichte und den Einsatz moderner Steuerelemente wie ItemsRepeater implementieren möchten.

Ich sehe, Sie sagten, dass die neue Geschichte der Datenvirtualisierung die Leistung verbessern wird, und das sind gute Nachrichten, aber wird sie auch die Notwendigkeit beseitigen, die Eigenschaft DataGridBoundColumn.Binding zu verwenden, um die Zellenwerte bereitzustellen, die DataGrid anzeigt?

Wenn der gesamte Datenabrufauftrag an die App ausgelagert wird , die DataGrid verwendet, hat die App die volle Flexibilität, den Datenabruf auf jede benötigte Weise durchzuführen. Dies würde viele verschiedene Datenabrufszenarien ermöglichen, einschließlich der Millionen Zeilen, die @dotMorten erwähnt hat. Verstehe es bitte :smile:

Ein paar unnötige Funktionen in WPF DataGrid?

Die WPF-Version von DataGrid hat einige Funktionen, die unnötig oder unpraktisch erscheinen, und diese Funktionen könnten in WinUI DataGrid übersprungen werden, aber ich gehe davon aus, dass einige Leute wahrscheinlich eine andere Meinung zu diesen Funktionen haben.

Wie viele Personen würden Einwände erheben, wenn WinUI DataGrid die Funktion aufgibt, bei der Endbenutzer Zellenwerte inline/direkt im DataGrid bearbeiten können? In unserem Fall setzen wir an jedem Ort, an dem wir DataGrid verwenden, immer DataGrid.IsReadOnly auf true, um die Inline-/Direktbearbeitungsfunktion zu deaktivieren. Wir erlauben Benutzern, die ausgewählte Zeile in einem separaten Bereich oder Panel oder in RowDetails ( DataGrid.RowDetailsTemplate ) zu bearbeiten, jedoch nicht direkt im DataGrid selbst.

Es scheint, als ob WinUI DataGrid bereits die Unterstützung für die Inline-/Direktbearbeitung aufgegeben hat, da WPF DataGrid CanUserAddRows und CanUserDeleteRows , diese Eigenschaften jedoch in WinUI DataGrid nicht mehr vorhanden sind. Warum nicht die Inline-/Direktbearbeitungsfunktion ganz weglassen? Wie viele Leute haben Einwände gegen diese Idee?

Individuelle Zellenauswahl: WPF DataGrid verfügt über eine SelectionUnit Eigenschaft, die Sie auf Cell , FullRow oder CellOrRowHeader festlegen können. In unserem Fall haben wir es immer auf FullRow und nie eine Notwendigkeit gefunden, es auf Cell . Ich sehe jedoch, dass eine Person hier bereits den Einzelzellenauswahlmodus angefordert hat. Meine Frage ist, ob der Zellenauswahlmodus eine häufige oder seltene Anforderung ist.

Andererseits kann die Auswahl einzelner Zellen nützlich sein, wenn der Benutzer Zeilen/Zellen in die Zwischenablage kopiert. Es würde Benutzern ermöglichen, eine einzelne Zelle (oder mehrere zusammenhängende Zellen) in die Zwischenablage zu kopieren, anstatt die gesamte Zeile zu kopieren. Ich bin mir jedoch nicht sicher, ob diese Funktion wirklich wertvoll ist oder nicht.

| Zweifelhaftes Feature in WPF | Kommentare |
| :--- | :--- |
| DataGrid.IsReadOnly | Vielleicht ist es nicht wirklich nötig, IsReadOnly jemals auf false zu setzen? |
| DataGrid.CanUserAddRows | Ist in WinUI DataGrid nicht vorhanden. Bereits aufgegeben oder vielleicht noch nicht umgesetzt (ich kenne den Plan nicht). |
| DataGrid.CanUserDeleteRows | Ist in WinUI DataGrid nicht vorhanden. Bereits aufgegeben oder vielleicht noch nicht umgesetzt (ich kenne den Plan nicht). |
| DataGrid.SelectionUnit | Ist in WinUI DataGrid nicht vorhanden. |

Wow, unglaubliche Diskussion hier. ️

Ich stimme auch der WPF DataGrid-API zu. Das WPF DataGrid ist wirklich das DataGrid, das ich für WinUI 3.0 haben möchte.

Aber selbst dem WPF DataGrid fehlen einige Features. In der Vergangenheit haben die meisten meiner Kunden ein leistungsfähigeres DataGrid von Drittanbietern verwendet, um diese Funktionen zu erhalten:

• Filter in den Spaltenüberschriften
• Eine komplette Filterzeile oben im DataGrid
• Leistungsstarke Anzeige hierarchischer Daten. Einige DataGrids von Drittanbietern funktionieren wirklich wie eine leistungsstarke TreeView mit verschachtelten DataGrids. Während das WPF DataGrid es erlaubt, so etwas zu bauen, unterstützt es es nicht sofort
• Unterstützung für verschiedene Datentypen. Wie zum Beispiel eine DateTime-Spalte. Im DataGrid von WPF müssen Sie die DataGridTemplateColumn . verwenden

Aber egal, was immer Sie tun, ich denke, der Aufbau eines DataGrids ist ein starkes Statement und Engagement für WinUI 3.0. Für LOB-Anwendungen können Sie ein UI-Framework nicht ernst nehmen, das kein integriertes DataGrid enthält. Und es ist großartig zu sehen, dass diese Investition für WinUI getätigt wurde!

@thomasclaudiushuber

Für LOB-Anwendungen können Sie ein UI-Framework nicht ernst nehmen, das kein integriertes DataGrid enthält. Und es ist großartig zu sehen, dass diese Investition für WinUI getätigt wurde!

Einverstanden! In unserem Fall ist DataGrid eine entscheidende Komponente, die wir an mehreren Stellen verwenden und ohne die wir nicht leben können.

Leistungsstarke Anzeige hierarchischer Daten. Einige DataGrids von Drittanbietern funktionieren wirklich wie eine leistungsstarke TreeView mit verschachtelten DataGrids.

Ich bin bei diesem Thema hin- und hergerissen, weil ich – wie Sie – ein hierarchisches DataGrid in manchen Situationen nützlich finden würde, aber meine Sorge ist, dass wenn DataGrid hierarchische Funktionen implementiert, es übermäßig komplex und schwierig werden könnte, und die Veröffentlichung von DataGrid würde sich höchstwahrscheinlich erheblich verzögern. Es wäre schwierig, neue Funktionen hinzuzufügen, da es so komplex ist, neue Funktionen sowohl mit hierarchischen als auch mit nicht-hierarchischen Funktionen kompatibel zu machen.

Um das oben erwähnte Komplexitäts-/Verzögerungsproblem zu beseitigen, schlage ich diese Lösung vor: Erstellen Sie eine separate Klasse namens HierarchicalDataGrid , die intern eine Instanz von DataGrid verwendet/umhüllt. Alternativ könnte HierarchicalDataGrid DataGrid öffentlich erben, aber ich vermute, dass diese Vererbung unpraktisch ist, daher schlage ich vor, dass HierarchicalDataGrid Control erben und intern ein privates Feld von . haben Geben Sie DataGrid . Somit würde die hierarchische Funktionalität in der HierarchicalDataGrid Schicht implementiert, die eine interne nicht-hierarchische DataGrid Instanz leitet.

Der Hauptvorteil der obigen Lösung besteht darin, dass sie die gewünschten hierarchischen Funktionen liefern würde, _ohne_ DataGrid verzetteln, ohne DataGrid so komplex zu machen, dass es unüberschaubar und langsam in der Entwicklung wäre.

Unterstützung für verschiedene Datentypen. Wie zum Beispiel eine DateTime-Spalte.

Ich stimme zu. Sehen Sie sich die DataGridDateTimeColumn und DataGridTimeSpanColumn , die ich in einer vorherigen Nachricht vorgeschlagen habe.

@Pinox

Einfach die ganze Seite filtern

@thomasclaudiushuber

Filter in den Spaltenüberschriften; Eine vollständige Filterzeile oben im DataGrid;

Filter wären großartig, um Endbenutzern dabei zu helfen, schnell eine oder mehrere Zeilen zu finden, anstatt in der aktuellen Situation gezwungen zu sein, eine große Anzahl von Zeilen manuell durchsuchen zu müssen, um das Gesuchte zu finden.

Aber was ist mit dem Problem, den Filtertext des Benutzers mit Nicht-Text-Spalten abzugleichen? Bedeutung von anderen Spalten als DataGridTextColumn , z. B. Filtern mit DataGridTemplateColumn usw.? Ich schlage vor, dies mit etwa der folgenden Lösung zu lösen, die DataGridColumn (und Unterklassen) die Möglichkeit gibt, einen Zellenwert in Schlüsselwörter für die Verwendung beim Suchen/Filtern/Abgleichen umzuwandeln.

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

Hier ist ein Beispiel für die Verwendung der Methode 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);
    }
}

Alternativ könnte der Zellenwert in eine einzelne Zeichenfolge anstatt in eine Sammlung von Schlüsselwörtern umgewandelt werden, aber der Grund, warum ich eine Schlüsselwortsammlung vorgeschlagen habe, ist, dass Schlüsselwörter es ermöglichen, Suchalgorithmen zu verwenden, die selbst bei einer Anzahl von Zeilen mit hoher Geschwindigkeit ausgeführt werden sehr groß.

Einfaches Kopieren der Vergangenheit aus Excel
Jetzt gibt es keine Möglichkeit, Strg+V zu verwenden, um den Inhalt von Excel-Zellen in Datagrid zu kopieren. Jetzt kopiert es den Inhalt aller Zellen in eine Zelle im Datenraster.

Stellen Sie eine ordnungsgemäße Unterstützung für mehrere ausgewählte Elemente bereit, indem Sie SelectedItems als Abhängigkeitseigenschaft festlegen, um die Verwendung der Datenbindung beim Verwalten ausgewählter Zeilen zu ermöglichen.

@verelpode Ich kann sehen, dass die Auswahl einzelner Zellen für jede Anwendung vom Tabellenkalkulationstyp nützlich ist, nicht

@anawishnoff Ich denke, @Laz3rPanth3r würde zustimmen und die paar Probleme hier und hier aus dem Toolkit, dass die Möglichkeit, Daten einfach und einfach in das DataGrid aufzunehmen, eine wichtige Funktion ist. Sie sollten in der Lage sein, das Raster zu booten, indem Sie an eine Sammlung von Objekten oder Expando-Objekten in einer Liste binden. Wenn es Spalten für Zahlen und Zeichenfolgen und grundlegende Datentypen intelligent auswählen kann, wäre das großartig. Der Entwickler kann danach immer noch mehr Arbeit machen, um einzelne Spalten darüber hinaus anzupassen.

Ich kann sehen, dass die Auswahl einzelner Zellen für jede Anwendung vom Typ Tabellenkalkulation nützlich ist, nicht wahr?

In einer Tabellenkalkulation werden die Spaltenüberschriften mit aufsteigenden Buchstaben des Alphabets benannt, A, B, C, D, … und der Typ jeder Spalte ist gleich, als ob jede Spalte DataGridTextColumn und keine andere Spalte verwendet type wird benötigt, und Spaltennamen werden auch nicht wirklich benötigt, da sie automatisch aus dem Alphabet generiert werden.
Ein weiterer Unterschied zwischen DataGrid und einer Kalkulationstabelle besteht darin, dass eine Kalkulationstabelle die Zeilen nicht sortiert, wenn Sie auf eine der Spaltenüberschriften klicken.

Mein Punkt ist, dass zwischen DataGrid und einer Tabellenkalkulation nur eine oberflächliche Ähnlichkeit (meistens eine visuelle Ähnlichkeit) besteht. DataGrid funktioniert nicht wirklich wie eine Tabellenkalkulation. Die Zellendatenabruftechnik von DataGrid eignet sich auch schlecht für eine Tabellenkalkulation.

Ich liebe DataGrid, aber es würde schlecht funktionieren, wenn ich versuchen würde, es zum Implementieren einer Tabelle zu verwenden. Ich glaube nicht, dass DataGrid die richtige Wahl für alle ist, die eine Tabellenkalkulation implementieren möchten.

Das bestehende Design von DataGrid passt viel besser zu einer SQL-Datenbank als zu einer Tabellenkalkulation, und SQL-Datenbankentwickler würden laut schreien, wenn jemand behaupten würde, eine Datenbank sei "nur eine Tabellenkalkulation".

@verelpode Deine Beiträge sind so ausführlich und durchdacht, vielen Dank dafür! Ich möchte über die Idee sprechen, eine Datenquelle / die ItemsSource-Eigenschaft von DataGrid zu binden, wie Sie es erwähnt haben und @michael-hawker hat es auch getan.

Derzeit macht es DataGrid für Apps obligatorisch, DataGrid.ItemsSource festzulegen, aber es ist unpraktisch, ein Listenobjekt zu erstellen, das eine Million Elemente enthält. Daher wünsche ich mir, dass DataGrid in der Datenabrufabteilung aufhört, schlau zu sein und mich stattdessen den Datenabruf vollständig selbst durchführen lässt, ohne DataGridBoundColumn.Binding und DataGrid.ItemsSource zu verwenden.

Das ist interessant, und ich würde es gerne genauer untersuchen, da wir wirklich an der Leistung interessiert sind. Welche Art von Datensituation/Szenario suchen Sie konkret? Möchten Sie das DataGrid direkt mit einem SQL-Abfrageergebnis oder einer Datenbank oder ähnlichem verbinden?

@khoshroomahdi Mit Kopieren und Einfügen meinen Sie, dass Sie Excel-Zellen in ein DataGrid in einer laufenden App kopieren und auf diese Weise auffüllen möchten? Das ist ein interessanter Anwendungsfall, ich würde gerne mehr hören.

@alexyak , könntest du noch etwas erweitern? Mit der SelectedItems-Eigenschaft können Sie derzeit alle ausgewählten Elemente in einem DataGrid abrufen (allerdings über den erweiterten Auswahlmodus, nicht genau den Mehrfachauswahlmodus). Ich sehe aus einigen anderen Kommentaren hier, dass die Auswahl innerhalb eines DataGrids definitiv Arbeit braucht, aber ich möchte Ihre Anfrage besser verstehen.

@anawishnoff ja genau.
Ich habe einige Daten in Excel-Zellen und möchte sie in eine laufende App kopieren.

Für nicht datengebundene Szenarien sollten wir uns ansehen, wie das WinForms DataGridView-Steuerelement, das ich vor vielen Jahren geschrieben habe, einen virtuellen Modus unterstützt: https://docs.microsoft.com/en-us/dotnet/api/system. windows.forms.datagridview.virtualmode

Derzeit macht es DataGrid für Apps obligatorisch, DataGrid.ItemsSource festzulegen, aber es ist unpraktisch, ein Listenobjekt zu erstellen, das eine Million Elemente enthält. Daher wünsche ich mir, dass DataGrid in der Datenabrufabteilung aufhört, schlau zu sein und mich stattdessen den Datenabruf vollständig selbst durchführen lässt, ohne DataGridBoundColumn.Binding und DataGrid.ItemsSource zu verwenden.

Ich stimme zu, das wäre auch schön. Ich denke an so etwas wie ListBox, wo Sie entweder Elemente manuell hinzufügen oder die ItemsSource festlegen können. In der Vergangenheit habe ich jedoch nur eine neue DataTable generiert, die eine Teilansicht der vollständigen Datenbank darstellt, um das Paging zu implementieren (was ein guter Anwendungsfall dafür ist). Eine Ansicht dieser DataTable kann dann auf ItemsSource festgelegt werden. Obwohl ich dies definitiv für schön finde, scheint es für eine hohe Leistung nicht zwingend erforderlich zu sein.

In Bezug auf all die Kommentare, die das Steuerelement mehr oder weniger in eine Teilmenge von Excel (r) verwandeln, denke ich, dass das DataGrid die Zellenauswahl und die Bearbeitung pro Zelle unterstützen sollte. Dinge wie das Kopieren/Einfügen zwischen externen Anwendungen sollten jedoch vom Entwickler übernommen werden.

@alexyak In Bezug auf Ihre Anfrage, SelectedItems zu einer echten, bindbaren DependencyProperty zu machen, wäre dies auch großartig, um den Status wiederherzustellen (die meisten meiner Feature-Anforderungen bestehen bisher darin, den Ansichtsstatus wiederherzustellen). Ich denke, dies ist jedoch ein Framework-weites Problem, da es in keinem mir bekannten WinUI/UWP-Steuerelement unterstützt wird. Dies sollte wahrscheinlich eine allgemeine Funktionsanfrage sein. Siehe Diskussion hier

@anawishnoff schrieb:

Ihre Beiträge sind so ausführlich und durchdacht, vielen Dank dafür!

Danke, es freut mich zu hören, dass meine Beiträge dazu beitragen, DataGrid noch besser zu machen :)

Welche Art von Datensituation/Szenario suchen Sie konkret? Möchten Sie das DataGrid direkt mit einem SQL-Abfrageergebnis oder einer Datenbank oder ähnlichem verbinden?

Das ist noch zu schlau. Dieses intelligente Verhalten verhindert, dass verschiedene Apps den Datenabruf auf unterschiedliche Weise durchführen. Unterschiedliche Apps haben sehr unterschiedliche Umstände, daher ist das "beste" Datenabrufsystem für verschiedene Apps unterschiedlich - es gibt kein einzelnes "Bestes". Zum Beispiel zeigen einige Apps nie mehr als ein paar hundert Zeilen an, während einige andere Apps mit einer Million Zeilen arbeiten können, wie @dotMorten erwähnt, daher passt eine Schuhgröße nicht für alle.

Ich schlage vor, es wirklich auf diese Ebene zu verdummen:

1. DataGrid entscheidet, dass es den Wert anzeigen (oder anderweitig verwenden) muss, der in Spalte 5 von Zeile 9001 im externen Datenspeichersystem vorhanden ist.
2. DataGrid benachrichtigt die App, dass sie den Wert für Spalte 5 der Zeile 9001 benötigt.
3. Die App ruft den Wert für Spalte 5 der Zeile 9001 ab. Dies kann eine asynchrone SQL-Abfrage oder eine asynchrone C#-Aufgabe oder ein anderes Datensystem umfassen. Idealerweise sollte DataGrid zulassen, dass dieser Schritt asynchron ist.
4. Die App benachrichtigt DataGrid, dass das Abrufen des Werts für Spalte 5 der Zeile 9001 abgeschlossen ist. Die App übergibt diesen Wert an DataGrid.
5. DataGrid verwendet den Wert auf die erforderliche Weise, z. B. indem der Wert wie in Schritt 1 erwähnt angezeigt wird.

@RBrid schrieb:

Für nicht datengebundene Szenarien sollten wir uns ansehen, wie das WinForms DataGridView-Steuerelement, das ich vor vielen Jahren geschrieben habe, einen virtuellen Modus unterstützt:

Ja Ja Ja! Ich habe WinForms DataGridView noch nie verwendet, aber ich habe gerade die Dokumentation gelesen und glaube, dass Sie den Nagel auf den Kopf getroffen haben. Auf der verlinkten Seite steht:
_"Der virtuelle Modus ist für die Verwendung mit sehr großen Datenbeständen konzipiert."_

Ich sehe, dass die WinForms DataGridViewCellValueEventArgs diese Eigenschaften enthält:

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

Das ist ausgezeichnet, außer dass es idealerweise aktualisiert werden sollte, um die modernen C#-Schlüsselwörter async und await oder das UWP-Äquivalent ( IAsyncOperation<TResult> ) oder vielmehr jede Art von Zeitverzögerung zu unterstützen zwischen DataGrid, das den Zellenwert anfordert, und der App, die den Zellenwert an DataGrid liefert. Um es so zu aktualisieren, dass es asynchron unterstützt, gehen Sie wie folgt vor:

1. Behalten Sie das Ereignis CellValueNeeded bei .
2. Entfernen Sie die Eigenschaft DataGridViewCellValueEventArgs.Value .
3. Erstellen Sie in DataGrid eine Methode mit dem Namen SupplyCellValue , die die App aufruft, anstatt die Eigenschaft DataGridViewCellValueEventArgs.Value sofort/synchron festlegen zu müssen.

Die Methode SupplyCellValue könnte wie folgt definiert werden:

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

Zur Laufzeit lautet die Prozedur also:

1. DataGrid entscheidet, dass es den Wert anzeigen (oder anderweitig verwenden) muss, der in Spalte 5 von Zeile 9001 im externen Datenspeichersystem vorhanden ist.
2. DataGrid löst das Ereignis CellValueNeeded aus und setzt DataGridViewCellValueEventArgs.RowIndex auf 9001 und DataGridViewCellValueEventArgs.ColumnIndex auf 5.
3. Der Ereignishandler (die App) beginnt mit der Ausführung einer asynchronen Aufgabe, die den Wert für Spalte 5 der Zeile 9001 abruft.
4. Wenn die Ausführung der asynchronen Aufgabe abgeschlossen ist, d. h. wenn die App den Wert abgerufen hat, ruft die App die Methode DataGrid.SupplyCellValue .

Diese abgespeckte Technik ist leistungsfähiger und flexibler als die intelligente automatisierte Technik von DataGridBoundColumn.Binding und DataGrid.ItemsSource .

@alexyak , könntest du noch etwas erweitern? Mit der SelectedItems-Eigenschaft können Sie derzeit alle ausgewählten Elemente in einem DataGrid abrufen (allerdings über den erweiterten Auswahlmodus, nicht genau den Mehrfachauswahlmodus). Ich sehe aus einigen anderen Kommentaren hier, dass die Auswahl innerhalb eines DataGrids definitiv Arbeit braucht, aber ich möchte Ihre Anfrage besser verstehen.

Wir brauchen eine richtige Zwei-Wege-Datenbindung für Ansichtsmodelle, um Mehrfachauswahlen zu verwalten

@verelpode , wir hatten das WinForms DataGridView-Modell nach den noch älteren Win32 ComCtl32-Steuerelementen modelliert. Insbesondere denke ich darüber nach, wie das Listenansichtssteuerelement die LVN_GETDISPINFO-Nachricht im virtuellen Modus verwendet hat (siehe https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview #handling-virtual-list-view-control-notification-codes und https://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo). Altes Zeug aus den 90er Jahren.

Wie auch immer, ich glaube, der asynchrone Datenabrufaspekt sollte durch "verzögerte Ereignisse" gehandhabt werden.
WinUI-Steuerelemente verwenden verzögerte Ereignisse bereits zweimal:

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

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

Dies ist das Muster, das das CellValueNeeded-Ereignis des neuen DataGrid übernehmen möchte. Es ermöglicht dem Ereignishandler, Daten asynchron bereitzustellen und dem Steuerelement mitzuteilen, wann dies erledigt ist. Siehe https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferral.

@RBrid
Guter Punkt, dass GetDeferral() das neue Standardmuster ist. In diesem speziellen Fall von CellValueNeeded scheint es viel schwieriger zu sein, Deferral als in anderen Fällen/Ereignissen. Korrigieren Sie mich, wenn ich falsch liege, aber ich denke, das Problem bei der Verwendung von GetDeferral() in diesem speziellen Fall besteht darin, dass GetDeferral() jedes Mal ein neues Objekt erstellt, wenn es aufgerufen wird, und dies würde zu einer übermäßigen riesige Menge an Objekterstellung und -bereinigung, die für jede Zelle jeder Zeile einer potenziell großen Anzahl von Zeilen wiederholt wird. Ich habe den Quellcode verschiedener GetDeferral() Implementierungen nicht gesehen, daher könnte ich mich darin irren.

Mit anderen Worten, es sei denn, Deferral unterstützt Recycling oder hat auf andere Weise eine Möglichkeit, GetDeferral() viel effizienter zu machen, dann ist es immer noch zu schlau. Mein abgespeckter Vorschlag mit der Methode SupplyCellValue vermeidet den Aufwand für das Erstellen, Vervollständigen und Verwerfen einer neuen Deferral Instanz für jede Zelle jeder anwendbaren Zeile.

1. GetDeferral()
2. Aufschub.Vollständig
3. Aufschub.Entsorgen
4. Wiederholen Sie die obigen Schritte viele Male.

Das Abrufen eines Zellenwerts ist nicht die einzige Datenverwaltungsaufgabe, die an die App ausgelagert werden kann. Auch die Sortierung kann ausgelagert werden. Daher könnte es sich lohnen, an eine Schnittstelle statt an ein einzelnes Ereignis CellValueNeeded zu denken. Eine App würde DataGrid ein Datenverwaltungsmodul in Form eines Objekts geben, das eine bestimmte Schnittstelle implementiert. DataGrid würde diese Schnittstelle aufrufen, um Zellwerte abzurufen, aber auch möglicherweise andere Aufgaben wie das Sortieren.

Um die Millionen Zeilen zu unterstützen, die @dotMorten erwähnt hat, würde CellValueNeeded allein das andere Problem nicht lösen, das auftritt, wenn der Benutzer auf eine Spaltenüberschrift klickt und das DataGrid versucht, eine Million Zeilen zu sortieren. So könnte der Zellenabruf UND das Sortieren über das oben genannte Modul/Interface in die App ausgelagert werden.

Wenn die App DataGrid kein Datenverwaltungsmodul/Objekt bereitstellt, verwendet DataGrid idealerweise ein Standard-Datenverwaltungsmodul. Daher würde der gesamte vorhandene Datenbindungscode in DataGrid aus DataGrid in eine separate neue Klasse verschoben – die Klasse, die das Standarddatenverwaltungsmodul implementiert, indem sie mit DataGridBoundColumn.Binding usw. arbeitet.

dh wenn die Sortierung auch an die App oder deren Datenverwaltungsmodul ausgelagert wird, dann öffnet dies die Tür zu verschiedenen Lösungen, die eine Million Zeilen unterstützen, wie zum Beispiel das Schreiben eines Datenverwaltungsmoduls, das den SQL-Server anweist, die Sortierung durchzuführen, anstatt es zu versuchen. und-das Sortieren einer Million Zeilen innerhalb von DataGrid in weniger als 10 oder 20 Stunden nach dem Klicken des Benutzers auf die Spaltenüberschrift, um mit der Sortierung zu beginnen, fehlschlägt.

@verelpode , ja, das ist ein

Nachdem wir uns vom Windows Community Toolkit DataGrid abhängig gemacht haben, das Zeilendetails als Funktion enthält (wenn auch mit einem schwerwiegenden Leistungsfehler, aber mit einer Problemumgehung), möchten wir wirklich, dass dieses neue Datagrid dies auch als Funktion hat - mit der gleichen Option um mehrere Zeilendetails gleichzeitig zu haben. Verwenden Sie es für ein Server-zu-Client-Streaming-Datenszenario.

Bezüglich einer Million Zeilen im Vergleich zu einer Paging- GUI schrieb @robloo :

Ich stimme zu, dass [eine Million Zeilen unterstützen] auch schön wäre. .... Das heißt, in der Vergangenheit habe ich nur eine neue DataTable generiert, die eine Teilansicht der vollständigen Datenbank darstellt, um das Paging zu implementieren (was ein guter Anwendungsfall dafür ist). Eine Ansicht dieser DataTable kann dann auf ItemsSource festgelegt werden. Obwohl ich dies definitiv für schön finde, scheint es für eine hohe Leistung nicht zwingend erforderlich zu sein.

Paging ist eine nützliche und erwähnenswerte Technik, die jedoch erhebliche Nachteile hat: Sie macht die Sortierfunktion von DataGrid praktisch nutzlos. Ebenso für eine Filterfunktion in der nächsten Version von DataGrid. Paging macht das Sortieren und Filtern nutzlos oder zumindest viel weniger nützlich.

Stellen Sie sich beispielsweise vor, dass 2 oder 3 Spalten Datumsspalten sind und der Benutzer die Zeilen mit dem neuesten (oder ältesten) Datum in der zweiten Datumsspalte anzeigen möchte. Somit klickt der Benutzer auf die zweite Datumsspaltenüberschrift, um das DataGrid nach dieser Spalte zu sortieren, und klickt auch, um die Sortierrichtung von absteigend in aufsteigend oder umgekehrt zu ändern. Dies funktioniert hervorragend, wenn kein Paging verwendet wird oder wenn die Gesamtanzahl der Zeilen klein genug ist, um eine einzelne Seite nicht zu überschreiten, aber es bricht ab, wenn mehrere Seiten vorhanden sind.

Der Benutzer muss das neueste (oder älteste) Datum über alle Zeilen hinweg finden, aber eine ausgelagerte DataGrid-GUI zeigt nur das neueste (oder älteste) Datum auf der aktuellen Seite, nicht über alle Zeilen hinweg, daher macht das Paging das Sortieren (und Filtern) praktisch nutzlos.

Damit stellt sich die Frage, welche Zeilen auf welcher Seite landen. Die Antwort ist, dass jede Seite normalerweise eine praktisch zufällige Teilmenge der Zeilen enthält, wenn die Seiten/Zeilen über eine SQL-Abfrage SELECT abgerufen werden, die ORDER BY . (Ich meine zufällig aus der Sicht des Benutzers, nicht wirklich zufällig.)

Pseudozufällig ist für Endbenutzer nicht hilfreich. Um diese problematische Zufälligkeit zu beseitigen, könnten wir darüber nachdenken, SQL ORDER BY (zusammen mit dem ASC oder DESC Schlüsselwort zur Steuerung der Sortierrichtung) zu verwenden, und dann ja, die Seiten sind nein länger zufällig, aber es ist immer noch kaputt, weil diese Verwendung von ORDER BY immer nach derselben Spalte und derselben Sortierrichtung sortiert, was bedeutet, dass sich die Sortierreihenfolge häufig von der Sortierreihenfolge unterscheidet, die der Endbenutzer beim Klicken auf eine Spalte wählt Header im DataGrid.

Um dies zu beheben, müssten Sie jedes Mal, wenn der Benutzer auf eine andere Spaltenüberschrift klickt, eine andere SQL-Abfrage verwenden. Die SQL ORDER BY ... ASC/DESC müsste der Sortierreihenfolge entsprechen, die der Endbenutzer von DataGrid wählt. DataGrid unterstützt dies derzeit nicht.

Eine vorgeschlagene Lösung finden Sie in meiner vorherigen Nachricht : Ich habe vorgeschlagen, dass DataGrid die Auslagerung der Sortierung an die App (oder an ein "Datenverwaltungsmodul") zulassen sollte. Diese Idee würde es der App (oder dem "Datenverwaltungsmodul") ermöglichen, die SQL ORDER BY ... ASC/DESC zu ändern, wenn der Endbenutzer die Sortierreihenfolge von DataGrid ändert, indem er auf Spaltenüberschriften usw. klickt.

Es könnte sich auch lohnen, dem bereits existierenden Ereignis DataGrid.Sorting eine einstellbare Eigenschaft in den Ereignisargumenten zu geben, die es Apps (dem Ereignishandler) ermöglicht , die Sortierung DataGrid.Sorting in einen weniger eindeutigen Namen umzubenennen denn derzeit ist die Absicht und der Zweck des Sorting Events unklar. Siehe auch das vorgeschlagene Ereignis SortOrderChanged in meiner anderen Nachricht .

Abhängigkeit vom Windows Community Toolkit DataGrid mit Row
Details als Feature (wenn auch mit einem schwerwiegenden Performance-Bug, aber mit einem Workaround) würden wir
Ich mag dieses neue Datagrid sehr, wenn es das auch als Feature hat - mit der gleichen Option
mehrere Zeilendetails gleichzeitig. Verwenden Sie es für ein Server-zu-Client-Streaming-Datenszenario.

Link zum Leistungsproblem der Zeilendetails: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2842
Repro: https://github.com/observito/DataGridRowDetailsPerfTest

Ein guter Ausgangspunkt ist Ihr Partner Telerik mit seinem RadDataGrid (UWP Open Source). Bei einem meiner Kunden habe ich es verwendet und es funktioniert tatsächlich gut. Es ist hyperschnell und vielseitig. Das einzige, was schwierig ist, ist ihr Code, es gibt keine Möglichkeit, etwas von ihrer Engine zu ändern, ohne die Architektur zu verstehen.

Ich würde erwarten, dass das neue DataGrid genauso leistungsfähig ist wie Telerik.

Die Syncfusion-Grid-Funktionen sind großartig, aber sie sind nicht mvvm-freundlich. Du könntest es also besser machen.

Hey nochmal alle! Lassen Sie uns dieses Gespräch am Laufen halten. Was denken Sie über die derzeit vorhandene DataGrid-Dokumentation?

Hier ist ein Link zur Hauptdokumentationsseite, die auf alle anderen relevanten Seiten verweist.

Wenn wir ein neues DataGrid erstellen, möchten wir sicherstellen, dass die begleitende Dokumentation erstklassig und leicht verständlich ist und alle Probleme und Szenarien berücksichtigt, die für unsere Entwickler wichtig sind.

_Welche Themen hätten Sie gerne? Welche Themen könnten geklärt werden?_

Hey nochmal alle! Lassen Sie uns dieses Gespräch am Laufen halten. Was denken Sie über die derzeit vorhandene DataGrid-Dokumentation?

Hier ist ein Link zur Hauptdokumentationsseite, die auf alle anderen relevanten Seiten verweist.

Wenn wir ein neues DataGrid erstellen, möchten wir sicherstellen, dass die begleitende Dokumentation erstklassig und leicht verständlich ist und alle Probleme und Szenarien berücksichtigt, die für unsere Entwickler wichtig sind.

_Welche Themen hätten Sie gerne? Welche Themen könnten geklärt werden?_

Bilder, die typische DataGrid-Setups zusammen mit dem xaml und dem Code zeigen, um sie zu erstellen, wären nützlich.

Bilder, die typische DataGrid-Setups zusammen mit dem xaml und dem Code zeigen, um sie zu erstellen, wären nützlich.

@mdtauk Gibt es bestimmte DataGrid-Setups, die Sie für "typisch" halten, oder Anwendungsfälle, in denen DataGrid Ihrer Meinung nach immer die beste Wahl ist?

Bilder, die typische DataGrid-Setups zusammen mit dem xaml und dem Code zeigen, um sie zu erstellen, wären nützlich.

@mdtauk Gibt es bestimmte DataGrid-Setups, die Sie für "typisch" halten, oder Anwendungsfälle, in denen DataGrid Ihrer Meinung nach immer die beste Wahl ist?

Ich denke für den WinUI 3.0-Zeitrahmen, der gängige WPF-, Win32-Datenraster-/Symbolansichtsszenarien zeigt. Sowie das, was Microsoft für fließende/moderne DataGrid-UI-Designs hält.

Das heißt, die Idee hinter dem Steuerelement besteht darin, den Wechsel von alten Benutzeroberflächen zu WinUI 3 zu fördern

@anawishnoff Ich denke, einige der Fragen, die wir aus dem Toolkit hatten, in Bezug auf Dinge, die die Leute nach einer Dokumentation suchten, wo weitere dieser Szenarien auch waren:

• Theming/Re-Templating/Ausrichtung
• Datenbindung (allgemein und in XAML)
• Ereignis-/Auswahlbehandlung/Gehäuse
• Bearbeiten von Verhaltensweisen (insbesondere Bearbeiten bei Klick)
• Multi-Paging (das gut mit #60 und #268 harmonieren sollte)
  
  
  
  • Die Animationskoordination wird geladen, während die Daten geladen werden
  
  
• Kopieren/Einfügen/Formatieren
• Verschiedene Spaltendatentypen (und benutzerdefinierte) (z. B. Aufzählungen)
• Kontextmenüs
• Barrierefreiheit

Mir ist aufgefallen, dass das vorhandene Toolkit DataGrid ein IEnumerable für seine ItemsSource-Eigenschaft erfordert. Dies scheint zwar eine logische Entscheidung zu sein, macht es jedoch unmöglich, das von Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector() zurückgegebene Objekt als diese Eigenschaft festzulegen. (Es sei denn, es gibt eine Möglichkeit, das zurückgegebene Objekt umzuwandeln.) Darüber hinaus unterstützen andere Steuerelemente wie ListView und GridView das Festlegen ihrer ItemsSource-Eigenschaft auf einen Wert des Objekttyps. Ich bin mir nicht sicher, aber die Unterstützung dieser Option würde wahrscheinlich eine reaktionsschnellere Benutzeroberfläche während der Speichervorgänge ermöglichen.

@mdtauk Gibt es bestimmte DataGrid-Setups, die Sie für "typisch" halten, oder Anwendungsfälle, in denen DataGrid Ihrer Meinung nach immer die beste Wahl ist?

Ich denke für den WinUI 3.0-Zeitrahmen, der gängige WPF-, Win32-Datenraster-/Symbolansichtsszenarien zeigt. Sowie das, was Microsoft für fließende/moderne DataGrid-UI-Designs hält.

Das heißt, die Idee hinter dem Steuerelement besteht darin, den Wechsel von alten Benutzeroberflächen zu WinUI 3 zu fördern

Win32-Beispiel (Datei-Explorer)

WPF-Beispiel

Fabric Web-Beispiel

UWP-Beispiel

@mdtauk Danke für diese Screenshots! Ich halte es definitiv für wichtig, die Schlüsselelemente hervorzuheben, die in früheren Versionen des Steuerelements funktioniert haben, und zu dokumentieren, wie sie mit dem neuen Steuerelement erreicht werden können.

@michael-hawker Super. Ich sehe dort bereits einige Themen, die mehrmals in diesem Thread angesprochen wurden, also sind diese definitiv ein guter Ausgangspunkt.

@duke7553 Ich bin mir nicht 100% sicher, ob es eine Lösung dafür gibt oder ob die Unterstützung eines Objekttyps sinnvoll wäre. Vielleicht kann sich @RBrid einklinken ?

@anawishnoff & @duke7553 , ich würde das neue DataGrid-Steuerelement auf dem neuen WinUI ItemsRepeater-Steuerelement aufbauen. Und dieses Steuerelement macht seine ItemsSource als Objekt verfügbar:
Object ItemsSource { get; set; };

Ich hoffe, es unterstützt CellDecorationStyleSelector wie in Telerik.

@anawishnoff

Wir sind daran interessiert, es zu einem nativen WinUI-Steuerelement zu erweitern

hmmmm, wenn Sie "graduieren" sagen, würde das ein Downgrade auf C++ beinhalten? Derzeit ist das DataGrid von WinUI in C# geschrieben. Ich hoffe, dass "Absolvent" nicht "Herabstufung" bedeutet. Wichtig ist, dass WinUI einen Punkt erreichen muss, an dem das WinUI-Team sagen kann, dass WinUI in jeder Hinsicht besser ist als WPF, aber dieses Ziel ist schrecklich überfällig. Dieses Ziel wird noch überfälliger, wenn Zeit/Ressourcen durch unnötige Downgrades von Code wie DataGrid von C# auf C++ verschwendet werden.

Obwohl es ursprünglich einen Grund gab, WinRT/UWP/WinUI in C++ zu schreiben, hat dieser Grund leider keine Früchte getragen und Google/Android hat den größten Teil des Smartphone-Marktanteils eingenommen, daher ist der ursprüngliche Grund für die Verwendung von C++ nicht mehr anwendbar (einfach im Nachhinein gesagt, aber früher nicht so leicht zu sagen). Wenn WinUI von Anfang an in C# geschrieben wäre, wäre das Besser-als-WPF-Ziel vor 3 Jahren erreicht worden, aber jetzt sind es 8 Jahre und immer noch nicht erreicht, und niemand kann genau sagen, wann das Ziel erreicht wird. Hoffentlich werden das Besser-als-WPF-Ziel und die "Abschluss"-Ziele von WinUI DataGrid nicht durch eine unnötige Konvertierung in eine ältere und weniger produktive Programmiersprache verzögert.

Ich bin zugunsten von C++ voreingenommen, weil ich mit dem Programmieren in C++ begonnen habe, bevor es überhaupt C# gab, und die Leute ziehen es vor, bei dem zu bleiben, was sie ursprünglich gelernt haben, und erinnern sich gerne an _"die guten alten Zeiten"_. Trotz meiner Vorliebe für C++ habe ich aufgehört, C++ zu schreiben, und ich denke, DataGrid sollte nicht auf C++ herabgestuft und verzögert werden. Belassen Sie es bei C# und konzentrieren Sie sich auf wichtigere Dinge, wie die verschiedenen von den Leuten in dieser Ausgabe vorgeschlagenen Verbesserungen und das Erreichen des Besser-als-WPF-Ziels, bevor 1 Jahrzehnt erreicht ist.

Ich liebe viele Aspekte von WinUI und schätze die vielen cleveren Verbesserungen darin, und ich schreibe App-Code für WinUI, aber möchten Sie die ehrliche Wahrheit wissen? Die Wahrheit ist, dass ich leider noch nie eine WinUI-App für Benutzer freigegeben

Aus Sicht von Microsoft ist WinRT/UWP Software in Releasequalität, die seit dem Jahr 2012 für Benutzer veröffentlicht wird, aber aus meiner Sicht ist UWP immer noch ein großes Experiment. Für mich ist UWP (einschließlich WinUI) alles eine große Beta-Testversion , mit der ich seit Jahren

In den ersten Jahren von UWP dachte ich jedes Jahr: _"ähm… ich warte bis nächstes Jahr. Es gibt immer noch zu viele Dinge in WPF, die in UWP fehlen. Nächstes Jahr wird sicher besser."_
Dann kam das nächste Jahr und ich wiederholte den gleichen Gedanken. Dann kam das nächste Jahr und ich wiederholte den gleichen Gedanken. Hoffentlich ist dieses Jahr das letzte Jahr, in dem ich das sage, oder zumindest ist das meine Absicht.

WinUI kann sich keine weiteren Verzögerungen leisten. Belassen Sie das DataGrid von WinUI als C#-Code. Beginnen Sie mit dem Schreiben von mehr WinUI-Code in C#, um die Produktivität zu steigern. Es ist jetzt 8 Jahre her und Android hat massive Marktanteile erobert. Das ist eine ernste Situation.

Übrigens war ich eigentlich nett/großzügig, als ich sagte, dass UWP immer noch eine Beta-Version ist, weil UWP technisch gesehen der Definition einer Alpha-Version entspricht, nicht der Beta. Um eine echte Betaversion zu sein, muss sie mit allen Funktionen ausgestattet sein, aber UWP hat noch nicht den Status der vollständigen Funktion erreicht, daher ist UWP noch Alpha. Im Wikipedia-Artikel "Software-Release-Lebenszyklus" heißt es beispielsweise:

"Die Beta-Phase beginnt im Allgemeinen, wenn die Funktion der Software vollständig ist, aber wahrscheinlich eine Reihe bekannter oder unbekannter Fehler enthält."
"Alpha-Software enthält möglicherweise nicht alle Funktionen, die für die endgültige Version geplant sind."

Wikipedia definiert "Feature komplett" wie folgt:

"Eine vollständige Version einer Software mit allen Funktionen hat alle geplanten oder primären Funktionen implementiert, ist jedoch aufgrund von Fehlern, Leistungs- oder Stabilitätsproblemen noch nicht endgültig. Dies geschieht am Ende des Alpha-Tests der Entwicklung."

Es wäre unvernünftig, UWP als funktionsvoll zu bezeichnen, denn wenn es wirklich funktionsvoll ist, muss UWP alle Fähigkeiten von Windows '95 und mehr haben, aber das tut es nicht – UWP übertrifft Windows 95 noch nicht in allen Bereichen . Windows 95 wurde vor 25 Jahren veröffentlicht. Als UWP/WinRT vor 7-8 Jahren veröffentlicht wurde, erlitt Microsoft einen Verlust von 900 Millionen US-Dollar und einen lähmenden Mangel an Apps im Windows Store. Es war eine Alpha-Version, die als Release-Version gekennzeichnet war, daher warteten und beobachteten App-Entwickler. Heute, fast 8 Jahre später, ist es immer noch eine Alpha-Version und sehr überfällig, und ich warte immer noch und schaue und warte.

Es wäre für Microsoft und Entwickler sehr vorteilhaft, wenn Microsoft eine ernsthafte Entscheidung/Verpflichtung treffen würde, der Produktion einer echten Beta-Version von UWP Priorität einzuräumen, der schnell eine echte Release Candidate-Version folgen sollte. Dies wäre sehr zu empfehlen und eine sehr vernünftige Vorgehensweise. Es wäre für alle ausgezeichnet.

UWP ist aus mehreren Gründen immer noch alpha/unvollständig, zum Beispiel: Vor 25 Jahren war es einfach, die Funktion "MoveFile" in Windows 95 zu verwenden, um eine Datei oder einen Ordner zu verschieben (obwohl die Funktion "MoveFile" hieß, unterstützte sie beide Dateien) und Ordner). Kann UWP Ordner verschieben? Nein noch nicht. Offensichtlich ist die Möglichkeit, Ordner zu verschieben, eine der grundlegenden grundlegenden Funktionen, aber UWP fehlt diese wesentliche Funktion und andere noch, daher wäre es unvernünftig, UWP als vollständig zu bezeichnen, daher hat UWP noch keinen Beta-Status erreicht, trotz wurde vor 7-8 Jahren veröffentlicht. Microsoft muss einer echten Betaversion von UWP Priorität einräumen.

Ein öffentliches GitHub-Repository zum Verfolgen von UWP-Problemen (außer UI-Problemen) existiert meines Wissens noch nicht (oder wenn ein UWP-Repository existiert, konnte ich es nicht finden). Dies entspricht wiederum der Definition einer Alpha-Version, da ein öffentliches Issue-Tracking-Repo während einer Alpha-Phase oft unerwünscht ist. Wenn es sich um eine echte Beta- oder Release-Version handelte, wäre bereits ein öffentliches Issue-Tracking-Repository geöffnet worden, und UWP würde alle Funktionen von Windows 95 und Windows 7 und mehr enthalten.

Wie wirkt sich diese Situation auf DataGrid aus ? In Anbetracht der Tatsache, dass eine Betaversion von UWP mit vollem Funktionsumfang so schrecklich überfällig ist, und angesichts der Schwere dieser Situation und des dadurch erlittenen Schadens in Höhe von mehreren Milliarden Dollar, wäre es nicht vertretbar und vernünftig, noch mehr Zeit zu verschwenden indem Sie WinUI DataGrid in nicht verwalteten Code und eine ältere Programmiersprache konvertieren. Microsoft hat wiederholt gesagt, dass ein großer Vorteil von C# und „Managed Code“ die gesteigerte Produktivität ist, und ich kann sagen, dass Microsofts Behauptungen über „Managed Code“ in meinen Erfahrungen mit C++ und C# definitiv zutrafen. UWP hätte vor einigen Jahren den echten Beta-Status erreicht, wenn es ab Version 1.0 hauptsächlich mit verwaltetem Code geschrieben worden wäre. Ich hoffe also, dass die Situation nicht noch schlimmer wird, wenn noch mehr dieser unnötigen Downgrades von verwaltetem Code zu nicht verwaltetem Code durchgeführt werden.

Zum Vergleich: Der größte Teil von WPF wurde in den 4 Jahren von 2006 bis 2010 erfolgreich abgeschlossen. WPF ist im Gegensatz zu UWP hauptsächlich verwalteter Code. UWP ist nicht verwalteter Code und nach 8 Jahren Entwicklung übertrifft Windows 95 UWP immer noch in einigen Bereichen. Microsoft hatte also eindeutig Recht, als Microsoft behauptete, dass verwalteter Code die Produktivität steigert. Dieses Problem muss so schnell wie möglich gelöst werden. WinUI sollte viel einfacher/schneller zu erstellen sein als WPF, da beide Projekte den gleichen Besitzer (Microsoft) haben, sodass WinUI frei Code aus WPF kopieren darf. Damit hätte WinUI ungefähr die Hälfte der Entwicklungszeit von WPF benötigt. Eigentlich hätte WinUI nie gestartet werden sollen, sondern Microsoft hätte die Funktionen von WinUI in neuen Versionen von WPF entwickeln sollen -- WinUI hätte WPF 5.0 sein sollen. Die Situation war also ein großes Durcheinander und es wäre sehr von Vorteil für Microsoft, die verbleibende Bereinigung dieses Durcheinanders zu priorisieren und Dinge einzustellen, die den Multi-Milliarden-Dollar-Fehler noch schlimmer machen, als er bereits war (und immer noch ist, wenn Sie hinschauen .) bei der heutigen Smartphone-Marktsituation).

Das bedeutet, um noch mehr Verluste zu vermeiden, würde Microsoft davon profitieren, sich an das zu erinnern, was Microsoft in der Vergangenheit bereits gesagt/gewusst hat:

• Verwalteter Code steigert die Produktivität nach eigenen Angaben von Microsoft. Wenn man sich die 8 Jahre von UWP im Vergleich zu den 4 Jahren von WPF ansieht, muss man feststellen, dass Microsoft mit den Vorteilen von verwaltetem Code richtig lag.
• Skriptsprachen sind zum Skripten da und Programmiersprachen zum Programmieren. JavaScript und PowerShell sind für ihre beabsichtigten Zwecke (Scripting) gut, aber für die Programmierung von Apps sind sie offensichtlich ungeeignet.
• Um erfolgreich zu sein, muss Microsoft von der Alpha über die Beta bis zur Veröffentlichung fortschreiten, und dies gelingt nur, wenn es sich um eine echte Release-Version handelt, nicht um eine unvollständige Alpha, die als "Release" gekennzeichnet ist. Somit war der Microsoft Store zu lange meist leer.
• Software-Ingenieure und andere Mitarbeiter arbeiten am besten, wenn sie gegen eine angemessene Vergütung und eine angemessene Anzahl von Arbeitsstunden sowie ein gesundes Arbeitsumfeld arbeiten. Offensichtlich wird Microsofts Verlust von mehreren Milliarden Dollar niemals durch den Einsatz von unbezahlten Fanatikern/Eiferern und ihren sogenannten „Tagesjobs“ und „Nachtjobs“ und ihren nicht nachhaltigen/ungesunden Arbeitsbedingungen rückgängig gemacht.
• Der enorme Marktanteilsgewinn von Android war nicht den unbezahlten Fanatikern zu verdanken. Wenn unbezahlte Fanatiker der Grund für den Sieg gewesen wären, dann wäre Linux nicht gescheitert. Die Erklärung ist viel einfacher: Der Preis von Android-Tablets und -Smartphones ist VIEL niedriger als der von Windows-Tablets und -Smartphones. Offensichtlich interessieren sich die Endbenutzer nicht für "Open Source"-Religionen / -Ideologien (Benutzer wissen nicht einmal, was das ist), sondern lieben einfach die günstigen Preise von Android-Geräten.
• Win16 ist extrem veraltet. Es ist Technologie von vor 20-30 Jahren, aus den frühen "Wilden Westen"-Tagen der Programmierung. Hören Sie daher auf, neuen Code basierend auf Win16 zu schreiben. Es "Win32" zu nennen, ändert nicht wirklich die Tatsache, dass es im Grunde immer noch Win16 ist. Win32 ist dasselbe wie Win16, außer dass die Zeiger in der Größe von 16 Bit auf 32 Bit erweitert wurden. Zu viele Gruppen bei Microsoft schreiben weiterhin neuen Code basierend auf Win16/32. Dies ist sehr ineffizient und eine große Ressourcenverschwendung.

@anawishnoff

Wir sind daran interessiert, es zu einem nativen WinUI-Steuerelement zu erweitern

Siehe auch Wikipedia-Artikel "Sunk cost" :

Der Sunk-Cost-Effekt (oder Concorde-Effekt) ist die Tatsache, dass das Verhalten oft dem Trugschluss der Sunk-Costs folgt; Menschen zeigen "eine größere Tendenz, ein Unterfangen fortzusetzen, sobald eine Investition in Geld, Mühe oder Zeit getätigt wurde". Dieses Verhalten kann als „gutes Geld schlechtem hinterher werfen“ beschrieben werden, und die Weigerung, diesem nachzugeben, kann als „Verluste begrenzen“ beschrieben werden.

Und ähnlich "Plan-Fortsetzungs-Bias" :

Plan-Continuation-Bias, Get-There-itis oder Press-on-itis sind eine unkluge Tendenz, an einem fehlgeschlagenen Plan festzuhalten. Dies ist eine gefährliche Gefahr für Schiffskapitäne oder Flugzeugpiloten, die einen geplanten Kurs auch dann einhalten können, wenn es zu einer tödlichen Katastrophe führt, und sie stattdessen abbrechen sollten. ..... Projekte erleiden häufig Kostenüberschreitungen und Verzögerungen aufgrund von Planungsfehlern und damit verbundenen Faktoren wie übermäßigem Optimismus, mangelnder Bereitschaft, Misserfolge einzugestehen, Gruppendenken und Abneigung gegen den Verlust versunkener Kosten.

WinRT/UWP verursachte bei Microsoft im ersten oder zweiten Jahr einen Verlust von 900 Millionen US-Dollar und einen viel zu lange leeren App-Store. WinRT/UWP war ein katastrophaler Misserfolg, daher hätte es im zweiten Jahr abgebrochen werden sollen, wurde aber wegen des "Plan Continuation Bias" und der Abneigung gegen den Verlust von versunkenen Kosten fortgesetzt. Dieses Zeug wird in Managementkursen gelehrt. Hat die Fortsetzung des Plans den katastrophalen Fehler von WinRT/UWP schließlich gelöscht oder rückgängig gemacht? Nein, es ist auch heute noch ein katastrophaler Misserfolg, wenn man sich den Smartphone-Marktanteil ansieht. Diese Beschreibungen in Wikipedia beschreiben die Situation von UWP genau.

Heute müssen wir uns alle einig sein, dass es zum jetzigen Zeitpunkt, 7-8 Jahre nach der Veröffentlichung von WinRT/UWP, zu spät ist, UWP abzubrechen, aber damit fallen wir erneut dem "Plan Continuation Bias" zum Opfer " und Abneigung gegen den Verlust versunkener Kosten.

Was kann also vernünftigerweise getan werden, um die Situation zu retten? Wir können die Situation nicht retten, indem wir UWP absagen, obwohl es definitiv schon vor Jahren hätte abgesagt werden sollen. Was wir tun können, ist Folgendes: Akzeptieren Sie den gigantischen Schaden, den WinRT angerichtet hat, aber richten Sie keinen weiteren Schaden an und nehmen Sie Änderungen an den Verfahren/Richtlinien des Projekts vor. Das heißt, hören Sie auf, dieselben katastrophalen Fehler von WinRT zu wiederholen/fortzusetzen. Hören Sie beispielsweise auf, so große Mengen an verwaltetem Code auf unproduktiven alten, nicht verwalteten "nativen" Code herunterzustufen. Die Verzögerung beim Erreichen des echten Beta-Status ist bereits sehr groß – warum die Verzögerung noch schlimmer machen?

Der Fehler "Plan Continuation Bias"/Sunk Cost wird fortgesetzt, wenn DataGrid auf nicht verwalteten "nativen" Code herabgestuft wird. Wenn ein katastrophaler Fehler wie WinRT/UWP gemacht wird, wird es viel schlimmer, wenn dieser Fehler immer und immer wieder wiederholt wird. Um den Schaden zu begrenzen, ist es notwendig, den gleichen Fehler nicht mehr zu wiederholen. Es ist wirklich an der Zeit, aus dem katastrophalen Versagen von WinRT zu lernen und mit dem Anlegen von Verbänden zu beginnen, um den anhaltenden Blutverlust zu stoppen.

DataGrid in nicht verwalteten Code zu konvertieren ist dasselbe, als würde man in eine Bibliothek gehen und sich die besten Projektmanagement-Bücher von den besten Autoren mit den meisten Kenntnissen/Erfahrungen ausleihen und dann all diese exzellenten Management-Bücher in ein Lagerfeuer werfen und zusehen, wie sie brennen.

@verelpode Ich bin gespannt, was Sie hier mit Ihren beiden sehr großen Beiträgen bezüglich DataGrid meinen. Ich persönlich verstehe nicht wirklich, was das obige Feedback speziell in Bezug auf die Verbesserung eines OOB-DataGrid-Steuerelements bedeutet. Das einzige, was ich bekam, war, dass Sie befürchten, es wäre Zeitverschwendung, es in nativen Code zu konvertieren, aber das richtet sich nicht an diejenigen, die WinUI von C++ verwenden. Es steht Ihnen weiterhin frei, die aktuelle verwaltete Implementierung zu verwenden, wenn Sie mit dem Aufwand zum Laden der verwalteten Laufzeit einverstanden sind. Alles andere scheint sich um WinRT und das UWP-App-Modell zu drehen, was beides nicht wirklich auf WinUI zutrifft, da es mit v3 völlig losgelöst davon wird.

@dotMorten - Der Grund, warum ich in diesen Nachrichten zusätzliche Details geschrieben habe, ist, dass die Leute es nicht verstehen werden, wenn ich das Problem nicht angemessen erkläre. Aber leider sehe ich jetzt, dass das zusätzliche Detail fehlgeschlagen ist und es trotzdem nicht verstanden wurde. Das ist sehr frustrierend. Dies ist der Grund, warum sich viele Leute nicht einmal die Mühe machen, Feedback zu schreiben, weil sie es für sinnlos halten, zu versuchen, den Leuten solche Probleme zu erklären, und selbst wenn die Botschaft erfolgreich verstanden wird, liegt es in der Natur des Menschen, dies zu erschießen Person, die die schlechte Nachricht überbringt, also lieber gar nichts sagen oder einfach nur "höflich" lächeln und das Gegenteil denken.

da es mit v3 völlig ungebunden wird.

Diese v3-Entbindung verhindert nicht die Wiederholung der gleichen Fehler. Der „Plan Continuation Bias“ besteht weiterhin.

Rufen Sie die Startseite von Microsoft auf:
https://www.microsoft.com/en-us/
Scrollen Sie nun auf der Startseite nach unten, bis Sie Windows Phone sehen. Oh! Sieh dir das an! Wir sind am Ende der Homepage angelangt und Windows Phone wird NIRGENDWO auf der Homepage von Microsoft erwähnt! Was bedeutet das? Es bedeutet, aufwachen. Es bedeutet, dass UWP wie gesagt ein katastrophaler Fehler war. Das bedeutet, dass es wichtig ist, nicht mehr dieselben Fehler zu wiederholen, die zum Scheitern von UWP geführt haben. Es bedeutet, den Plan zu ändern, um die Katastrophe zu retten und sich zu erholen.
Es wäre ein Managementfehler, wenn WinUI und DataGrid weiterhin dieselben Fehler wie beim Scheitern von UWP wiederholen würden.

"Im Mai 2016 entkernte Microsoft sein Mobilfunkgeschäft, .... 2017 gab Microsoft-Manager Joe Belfiore bekannt, dass Microsoft die Entwicklung neuer Windows-Telefone und neuer Funktionen für Windows 10 Mobile eingestellt hatte, unter Berufung auf den Verlust von Marktanteilen und das Fehlen von App-Entwicklung."
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

Ana listet 5 Punkte auf, um Feedback zu DataGrid zu geben. Welche dieser Punkte kommentieren Sie? Ich denke, das ist der Teil, den ich aus dem, was du schreibst, nicht mitbekomme. UWP befriedigt nicht die Bedürfnisse aller, aber WinUI3 schreibt nicht die Verwendung des UWP-App-Modells vor, und Sie scheinen hauptsächlich gegen UWP zu sein? Da sollte es dir also gut gehen.

Sie haben erwähnt, dass DataGrid nicht weiterhin die gleichen Fehler machen sollte, die es gemacht hat. Welches sind diese Fehler speziell in Bezug auf das vorhandene DataGrid, und wie schlagen Sie vor, dass sie korrigiert werden sollten? (abgesehen davon, dass Sie es aus irgendeinem Grund nicht in C++ implementieren möchten)

@dotMorten

Ana listet 5 Punkte auf, um Feedback zu DataGrid zu geben. Welche dieser Punkte kommentieren Sie?

Der Teil, in dem ich Ana am Anfang meiner Nachricht zitiert habe. Ich kommentiere den Teil von Anas Nachricht, den ich am Anfang meiner Nachricht zitiert habe.

WinUI3 schreibt nicht vor, dass das UWP-App-Modell verwendet wird

Das hat nichts mit meiner Nachricht zu tun. Die Ungebundenheit und Verfügbarkeit von WinUI 3 über das Nuget-Paket ist irrelevant für die Frage, ob WinUI 3 die gleichen Managementfehler fortsetzt, die zum Scheitern von UWP und Windows Phone und Microsofts Milliardenverlusten geführt haben.

Wie schlagen Sie vor, dass sie korrigiert werden sollten?

Die 6 Aufzählungspunkte am Ende meiner früheren Nachricht . Der zweite Aufzählungspunkt (Skripterstellung) bezieht sich auf WinUI und UWP im Allgemeinen, bezieht sich jedoch nicht auf DataGrid. Der erste Aufzählungspunkt ist der wichtigste, wenn Sie speziell nach DataGrid fragen.
Ich habe auch geschrieben: Hören Sie auf, so große Mengen verwalteten Codes auf unproduktiven alten, nicht verwalteten "nativen" Code herunterzustufen. Die Verzögerung beim Erreichen des echten Beta-Status ist bereits sehr groß – warum die Verzögerung noch schlimmer machen?

@anawishnoff schrieb:

Wir sind daran interessiert, es zu einem nativen WinUI-Steuerelement zu erweitern

„Die Abstufung zu einem nativen WinUI-Steuerelement“ stellt praktisch eine Fortsetzung / Wiederholung einiger der gleichen Fehler dar, die zu den in Wikipedia erwähnten „Verlusten von Marktanteilen und fehlender App-Entwicklung“ führten:

"Im Mai 2016 entkernte Microsoft sein Mobilfunkgeschäft, .... 2017 gab Microsoft-Manager Joe Belfiore bekannt, dass Microsoft die Entwicklung neuer Windows-Telefone und neuer Funktionen für Windows 10 Mobile eingestellt hatte, unter Berufung auf den Verlust von Marktanteilen und das Fehlen von App-Entwicklung."
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

Warum sollte DataGrid denselben Weg fortsetzen, der das mobile Geschäft von Microsoft zerstört hat?

@verelpode

WinUI 3 setzt die gleichen Managementfehler fort, die zum Scheitern von UWP und Windows Phone und zum Milliardenverlust von Microsoft geführt haben.

Ich arbeite nicht für Microsoft, aber ich bin neugierig, warum Sie sagen, dass WinUI Managementfehler macht.
Aus meiner Sicht trägt die Tatsache, dass WinUI Open Source ist und jeder zu Gesprächen und Entscheidungen beitragen kann, tatsächlich dazu bei, zu definieren, was WinUI ist, und sollte Fehler vermeiden.
Sie erwähnen, dass das DataGrid auf dem gleichen Weg wie mobile weitergeht, aber nirgendwo im Pitch habe ich gesehen, dass es mobile erwähnt wird. Vielleicht können Sie direkt Feedback zu diesem Thema geben.
Wenn Sie der Meinung sind, dass es bei WinUI Missmanagementschritte gibt, können Sie möglicherweise ein separates Problem mit Ihren Bedenken erstellen, aber ich glaube wirklich nicht, dass Ihre Kommentare etwas mit dem DataGrid-Steuerelement zu tun haben.

@verelpode Bitte halten Sie Ihr Feedback hier zum Thema. Wenn Sie Bedenken bezüglich WinUI oder UWP im Allgemeinen haben, starten Sie bitte ein neues Diskussionsthema oder kontaktieren Sie mich direkt (E-Mail oder DM auf Twitter). Oder Sie könnten erwägen, über ein bestehendes Thema wie #717 oder #1531 zu diskutieren.

Sie teilten Bedenken, dass DataGrid in C++ neu geschrieben wird, aber der ursprüngliche Vorschlag erwähnte nichts davon. @anawishnoff versucht, Feedback zum DataGrid-Feature-Set zu sammeln. Wenn es hinsichtlich der Implementierung am sinnvollsten ist, es in C# zu belassen, würden wir dies tun (und es könnte immer noch aus C++ aufrufbar sein, wenn wir es als WinRT-Komponente verwenden würden).

@jevansaks -- Mein Feedback war

@verelpode Niemand hat hier "den Boten erschossen, der die schlechten Nachrichten überbringt". @jevansaks hat Sie eingeladen, eine neue Ausgabe zu eröffnen, um Ihre allgemeinen Bedenken zu UWP/WinUI/WinRT in diesem Repository zu teilen. Bei diesem Problem geht es wirklich nur um das DataGrid, und obwohl eines Ihrer Bedenken tatsächlich DataGrid betraf, ging es in der überwiegenden Mehrheit um UWP/WinUI/WinRT im Allgemeinen. Ich bin sicher, wenn Sie sich diese Diskussion noch einmal ansehen, werden Sie feststellen, dass das WinUI-Team Sie nur darum bittet, dieses Problem ausschließlich auf den DataGrid-Vorschlag zu konzentrieren und ein neues / ein bestehendes Problem für Ihre allgemeineren Bedenken bezüglich der zu öffnen Plattform.

Die von Ihnen erwähnten Bedenken können die Grundlage für eine interessante Diskussion sein, an der sowohl das WinUI-Team als auch die Community beteiligt sind, aber dieses spezielle Thema ist für eine solche Diskussion nicht geeignet.

@anawishnoff
Ich bin mir ziemlich sicher, dass das Microsoft Pivot Viewer-Steuerelement kein HTML war. Bitte schauen Sie es sich noch einmal an. Die Möglichkeit, große Datenmengen mit so etwas zu visualisieren, war etwas, was wir manchmal tun wollten. Ich glaube, es war in Silverlight verfügbar. https://www.microsoft.com/silverlight/pivotviewer/default# Es hat Deep Zoom für seine Funktionalität verwendet. Das Hinzufügen der Deep Zoom-Funktion zu WinUI 3.0 wäre fabelhaft! Nicht wirklich das Datagrid, sondern ein Data Display Control. Es gibt viele "aufgegebene" Ideen aus den frühen Tagen von WPF wie Deep Zoom, die es nie in ein produktives WPF-Steuerelement geschafft haben, das im Laufe der Zeit in WinUI 3.0 wunderbar zum Leben erweckt werden könnte. Verdammt, hol Dr. WPF aus dem Keller und lass ihn wieder posten!!! Wir brauchen ihn zurück. Wir müssen eine Bewegung starten. BRINGEN Dr. WPF ZURÜCK !!!!! Wo bist du hingegangen? Dr. WinUI!!!

@PaulMontgomerySP klingt so, als ob Sie ein neues Problem öffnen sollten, um das Pivot-Steuerelement zu besprechen. Fühlen Sie sich frei, auf die vorherige Diskussion im Windows Community Toolkit hier zu verweisen: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/770

Das auswahlgeänderte Ereignis wird für jede Zeile ausgelöst, zu der ich mit der Tastatur gehe.
Es wäre schön, ein Ereignis nur für einen Mausklick oder Zelltipp zu haben, anstatt nur das auswahlgeänderte Ereignis.

Die durch die Auswahl geänderte Ereignisauslösung wird sowohl für Klick als auch für Tastatur ausgelöst. Es wäre sehr von Vorteil, ein Ereignis nur zum Klicken zu haben.

@Going-Gone Ich bin neugierig, was der Anwendungsfall dafür ist? Warum müssen Sie den Unterschied kennen? Können Sie das getappte Ereignis auch nicht verwenden?

Eine Einschränkung, die ich gerade mit dem DataGrid des UWP-Toolkits getroffen habe, ist, dass DataGridTemplateColumn ein CellTemplate hat, aber kein CellTemplateSelector (und dasselbe fehlt für CellEditingTemplate ). Es würde die Anpassung der Benutzeroberfläche in jeder Zelle mithilfe des Selektoransatzes an die Daten vereinfachen, anstatt dies mit einer zusätzlichen Ebene von UI-Steuerelementen darunter tun zu müssen, um dies zu handhaben.

Bitte machen Sie es auch möglich, Zeilen nicht nur in fortlaufender Reihenfolge auszuwählen, wie ich es hier ausführlich erläutert habe:
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

In keiner bestimmten Reihenfolge der Dinge, die von Kunden oft angefordert werden, die ein Grid unterstützen sollte

1. Möglichkeit zum Speichern, Laden und Erstellen von Filtern. ZB nach Linq-Ausdruck filtern, nach SQL-Abfrage filtern, nach Ausdrucksbaum filtern und umgekehrt. Beispiel – https://querybuilder.js.org/demo.html

1. Hochgeschwindigkeits-Echtzeitdatenfunktionen, Leistung zählt. Aktualisierungsraten von unter 1 ms für Handelsanwendungen im Vergleich zu > 1 Million Zeilen haben unterschiedliche Leistungsaspekte.
2. Möglichkeit, die Sortierreihenfolge anzugeben, z. B. i. Sortieren hoch/niedrig, ii. Sortieren niedrig/hoch und iii. keine Sorte oder ich. niedrig/hoch sortieren, ii. Sortiere hoch/niedrig und iii. keine sorte
3. Excel-ähnliches Filtern
4. Möglichkeit, CSS-Formatierung auf Zellen anzuwenden, bedingte Formatierung
5. Möglichkeit zum einfachen Speichern/Laden von Rastereinstellungen, z. B. Filter, Spaltenbreiten, Sortierung usw.
6. Scrollen was funktioniert, zB nach Datenupdate nicht zurückgesetzt, ruckelfrei.
7. Datensammlungsereignisse sollten Optionen zum Auslösen von Ereignissen nach dem Laden von Bereichen anstelle einzelner Objekte haben. Ich glaube beispielsweise, dass ObservableCollection eine Unterklasse erfordert, um zu verhindern, dass INotifyPropertyChange für jedes einzelne hinzugefügte Objekt ausgelöst wird.
8. Bessere Ereignisse für das Laden/Laden von Daten, das Starten von Daten, das Laden von Daten, das Laden von Daten, insbesondere bei Verwendung des asynchronen Ladens.
9. Raster sind oft mit anderen Steuerelementen wie Datenfiltern, Bereichsauswahl, Kreuzfilter (zB https://github.com/dc-js/dc.js), Diagrammen, Pivot-Tabellen usw. verknüpft
10. Intelligente Sortierung, die alphanumerische Daten verarbeitet, zB Sortierreihenfolge ABC11, ABC12, ABC111 statt ABC11, ABC111, ABC12
11. Unbegrenzte Ebenen hierarchischer Raster, zB https://docs.telerik.com/devtools/wpf/controls/radgridview/hierarchical-gridview/hierachy-overview

Nützliche Ressourcen: - Entwerfen Sie bessere Datentabellen
https://news.ycombinator.com/item?id=21460966
https://uxdesign.cc/design-better-data-tables-4ecc99d23356

Ich kann nicht direkt aus dem Header an die Spaltenbreite binden. In WPF muss ich in diesem Fall ein BindingProxy-Objekt verwenden.

Praktische dynamische Größenänderung der aktiven Zeile für eine einfachere Bearbeitung.
Volle Kontrolle über Kontextmenüs im Bearbeitungsmodus.

Ich hoffe, es unterstützt CellDecorationStyleSelector wie in Telerik.

Barrierefreiheit!
Erwähnen Sie es, damit es dokumentiert ist, aber dieses Steuerelement muss vollständig zugänglich sein.
Die aktuelle Toolkit-Version weist in diesem Bereich einige Einschränkungen auf: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3400 & https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079
Auch wenn das Telerik RadDataGrid einige großartige Funktionen hat, scheint es die Zugänglichkeit nicht zu unterstützen .

Angesichts des großen D&I-Ansatzes von Microsoft überrascht es mich, dass nicht überall die Forderung nach vollständiger Zugänglichkeit aller Steuerelemente angegeben wird.

Vielleicht ist dies bereits möglich, und ich weiß nur noch nicht, wie ich es bewerkstelligen soll ... aber wie wäre es mit: benutzerdefinierter Zeilen- oder Zellengestaltung?

Die Möglichkeit, auf eine bestimmte Zeile abzuzielen, den Hintergrund und die Textfarbe zu ändern, wäre großartig.

Im Vergleich zum WCT UWP DataGrid:
1) Leistung
2) Mehr integrierte Spaltentypen (ich gehe davon aus, dass diese eine bessere Leistung haben als Vorlagenspalten)
3) Möglichkeit, Mausereignisse pro Zelle einzuhaken, dh Tippen, Tippen mit der rechten Maustaste und Schweben (oder Zeiger nach unten oder was auch immer)
4) Tastaturereignisse pro Zelle
5) Wenn (3) nicht praktikabel ist, könnten wir emulieren, wenn wir Hit-Testing-Funktionalität hätten
6) Leistung

Wie viele Personen würden Einwände erheben, wenn WinUI DataGrid die Funktion aufgibt, bei der Endbenutzer Zellenwerte inline/direkt im DataGrid bearbeiten können?

Erinnert sich jemand an VB6? Das VB6 DataGrid unterstützt standardmäßig Bearbeiten, Löschen und AddNew. Hinzufügen war als leere Zeile verfügbar, die automatisch am Ende der Liste hinzugefügt wurde. Vervollständigen Sie die Zeile und eine weitere leere Zeile wird angezeigt.

Ein DataGrid sollte die Möglichkeit haben, die Dateneingabe zu unterstützen, auch wenn die meisten Entwickler es vorziehen, dass diese Funktion standardmäßig deaktiviert ist.

Beim Portieren einer VB6-App auf UWP mussten wir unser eigenes Datengrid schreiben, um das Hinzufügen/Bearbeiten/Löschen zu unterstützen.

Es scheint, dass die meisten, die hier beitragen, WPF/Xaml-Leute sind, das sind zwei Cent wert von jemandem, der kein Xaml-Typ ist.

Ich verwende in meiner Software häufig DataGrid-Steuerelemente. Bearbeitung ist Platz ist wichtig! Einige meiner Wünsche/Schmerzpunkte sind:

1. Möglichkeit, das Kontextmenü im Bearbeitungsmodus anzupassen.
2. Bessere Leistung und mehr Kontrolle bei der automatischen Größenanpassung von Spalten. Ich möchte, dass der Benutzer die Größen bei Bedarf steuern kann, dies jedoch meistens nicht muss. Ich möchte nicht, dass sich die Spaltengrößen ständig ändern, aber ich möchte, dass sie irgendwie auf Daten basieren, ohne dass Daten im Wert von einer Million Zeilen gemessen werden müssen.
3. Beim Bearbeiten möchte ich in der Lage sein, auf ein anderes Steuerelement / eine andere Schaltfläche zu klicken, die etwas mit (oder mit) den bearbeiteten Daten macht, ohne die Bearbeitung zu beenden. (Dies wäre weniger notwendig, wenn # 1 implementiert würde - obwohl es immer noch nützlich ist.)
4. Die derzeitige Art und Weise, wie Ausnahmen mit dem DataError-Ereignis behandelt werden, ist grob. (Entschuldigung, ich habe Schwierigkeiten, mich darauf zu spezialisieren, aber ich weiß, dass es mir in der Vergangenheit mehrmals Schmerzen bereitet hat.)
5. Eingebaute Auto-Scrolling-Funktion wäre schön: http://stackoverflow.com/questions/2567809/how-to-autoscroll-a-datagridview-during-drag-and-drop
6. Möglichkeit, ein "Wasserzeichen" anzuzeigen, das anzeigt, wenn die Daten "schmutzig" sind (siehe BetterGrid für einige zusätzliche nützliche Verbesserungen von DataGridView.
7. Möglichkeit, eine Zeile (ohne Validierungsfehler) abzubrechen, wenn die erforderliche "Schlüssel"-Zelle leer bleibt.
8. Eingebaute Möglichkeit, kein Bild (anstelle eines roten X) für eine vom Benutzer hinzugefügte Zeile anzuzeigen. Siehe: https://stackoverflow.com/questions/937919/datagridviewimagecolumn-red-x
9. Lassen Sie zu, dass eine Kontrollkästchenspalte bei Änderung sofort festgeschrieben wird: https://stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

Wann wird die Alpha voraussichtlich veröffentlicht? Wird es für Beiträge offen sein? Ich versuche, ein veraltetes Datenraster abzulegen und freue mich sehr darauf, insbesondere auf die Virtualisierungsfunktion.

Entschuldigung für den sehr späten Input zu diesem Thread, aber für mich ist er "neu" ;)
_bearbeitet, nachdem ich ein bisschen mehr über das Verhalten des Steuerelements herausgefunden habe_

Bei der Arbeit mit DataGrid an der Entwicklung einer Explorer-ähnlichen Schnittstelle für Cloud-Laufwerke stellte ich fest, dass die Bestimmung der angezapften Zeile und Zelle etwas komplexer sein kann, als sie "sollte" (IMHO)

Im Design meiner App stellen die Zeilen Dateien oder Ordner (DriveItems) dar. Die Detailansicht zeigt weitere Details zum Artikel.

Ich wollte eine Möglichkeit schaffen, auf ein Ordnerelement zu klicken und die Benutzeroberfläche zu überspringen und eine Liste dieser Elemente zu erstellen, um die Navigation durch das Laufwerk zu ermöglichen.

Wenn ich beispielsweise auf den Spalteneintrag "Parent" des Elements, /drive/root:/Documents/Vital%20Documents hier, tippe, würde die Schnittstelle auf diesen Ordner zurückgesetzt und die Dateien dort aufgelistet.

Obwohl man ein angeklicktes Ereignis für die Zelle erhalten kann, scheint dieses Ereignis nicht den Kontext für den Handler zu haben, um die angetippte Zelle zu bestimmen (Zeile, ja, aber nicht Spalte), und ich bin mir nicht sicher, ob dies derzeit der Fall ist control würde es mir ermöglichen, sowohl das Verhalten der Zellen anzutippen als auch das Verhalten des automatischen Öffnens von Details (immer noch untersuchen, was ich "Hacks" nennen könnte, die dies ermöglichen würden, aber wir müssen uns daran erinnern, dass, wenn Designer beginnen, die normale Funktion des Steuerelements außer Kraft zu setzen, besonders Es handelt sich nicht um dokumentierte Verhaltensweisen, sondern es besteht die Gefahr, dass das Design durch Änderungen im Verhalten des Steuerelements beschädigt wird.

Alles in allem scheint DataGrid mein Szenario zu unterstützen, indem das Ereignis, das derzeit das DriveItem als CurrentItem zurückgibt, auch ein CurrentColumn , das das gesamte DataGridColumn Objekt darstellen würde, auf das geklickt wurde, durch die es möglich wäre, den Spaltennamen zu extrahieren. Mir ist jetzt klar, dass wir das CurrentColumn-Objekt haben, das wir vom Ereignis aus untersuchen können. Obwohl es mir als Ereignisargumente besser gefallen würde, sollte dies funktionieren.

Eine strengere Kontrolle des Detailverhaltens könnte auch darin bestehen, dass die Details nur automatisch erweitert werden, wenn auf eine bestimmte Spalte geklickt wird, anstatt jedes Mal erweitert zu werden, wenn irgendwo in der Zeile geklickt wird.

Vielleicht könnte die Basisklasse des DataGridColumn Objekts eine ExpandDetails Eigenschaft haben, die standardmäßig für jede Spalte auf true gesetzt werden kann, was bedeuten würde, dass beim Klicken auf eine bestimmte Spalte die Zeile erweitert wird. Andere, bei denen die Eigenschaft falsch ist, wären dies nicht.

In meinem Design ist die erste Spalte zum Beispiel der Elementtyp, wie in Datei oder Ordner oder Bild oder Foto, Audio usw. Ich könnte mir vorstellen, dass diese Spalte die einzige ist, die das automatische Erweiterungsverhalten verursacht. und dann könnte ein Klick auf die Pfadspalte das oben beschriebene Verhalten "Eine Liste dieses Pfads abrufen" verursachen.

Was die Sortierung angeht, scheint es logisch wichtig zu sein, genügend Kontrolle zu implementieren, damit Designer eine Sortierung auf mehreren Ebenen erhalten. Ich habe keine Untersuchungen durchgeführt, um festzustellen, wie das aktuelle Steuerelement dies durch das Einhängen/Überschreiben von Ereignissen und Rückrufen unterstützen könnte, aber es sieht nicht einfach aus.

Schließlich weiß ich, dass Sie sich dessen bewusst sind, aber (auch wenn ich nach mehr Funktionalität verlange), vermeiden wir BITTE den Versuch, eine Reihe komplexer Verhaltensweisen hinzuzufügen, die Benutzer selbst über das DataGrid implementieren können. Unter diesen, die ich nicht in DataGrid implementieren würde, sind solche, die mit dem externen Speichern von Filtern oder Sortierungen usw. zu tun haben. Ich würde auch vermeiden, dieses Steuerelement in einen Excel-Klon zu verwandeln.

-danke, tolle arbeit!
-e

Sticky Groups: Beim Durchsuchen von Datensätzen mit großen Gruppen sollte es einen Kontext dazu geben, welche Gruppe (oder Gruppen, dh Breadcrumb) angezeigt wird. Dies scheint ein wesentliches Usability-Feature für alle hierarchischen listenbasierten Ansichten zu sein: gruppierte Listenansichten, Datagrids und Baumansichten.

Ich würde das neue DataGrid-Steuerelement auf dem neuen WinUI ItemsRepeater-Steuerelement aufbauen. Und dieses Steuerelement macht seine ItemsSource als Objekt verfügbar:
Object ItemsSource { get; set; };

@RBrid Zurück zu diesem

• ISupportIncrementalLoading
• IIemsRangeInfo
• IAuswahlInfo

-Wie wäre es jetzt mit einem MVP, damit wir ein Datagrid von c++ verwenden können.