その他のビューモード。 ファイルエクスプローラーとそのアイコンビューを見てください。 DataGridは、グループ化されたグリッド内のアイコン/アイテム、および見出しの行と列を表示できる必要があります。

これは不可能であるか、範囲外である可能性があることを私は知っていますが、これはWinUIとWin32の側面であり、1：1ほど簡単ではありません。また、最新バージョンのファイルエクスプローラーまたは共通ファイルダイアログには必要がある場合があります。そのようなコントロールの。 これは、内部カスタムコントロールではなく、そのコントロールである可能性があります。

私のウィッシュリスト：私にとって、優れたデータグリッドには、デフォルトで次のすべての機能が含まれています。 私はhtmlの世界からいくつかのスクリーンショットを借りています。

優先行数でページ全体を簡単にフィルタリングします。

表示列の選択/選択解除、列の並べ替え、コピー、印刷

データを特定の形式にエクスポートします。

列をドラッグして列を並べ替えます。

列フィルタリング

固定ヘッダー-スクロールしてもヘッダーが上にとどまる場所

詳細については、XAMLテンプレートを使用した行の詳細。

行のグループ化

行の順序をドラッグアンドドロップします

私の意見では、上記の機能はすべてのデータグリッドで標準である必要があります。

datagridをhtmlの世界で目立たせたい場合は、以下も含めます。 データグリッドにはこれらの機能がないため、データグリッドを何度も見てからリストビューに落ち着きます。

行をサイドスワイプして、編集、削除、フラグなどの機能を含めます。

上記の機能は主に「データの表示」を処理しますが、WinUIにまだ欠けているのは、 Microsoft Pivot ControlのようなネイティブのWinUI機能（コントロール）であると私が信じていること

MSにはすでにこのためのソースコードがあり、当時は絶対に素晴らしいコントロールでした。

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

ここで、WinUIをそこにあるすべての基本機能と区別するために最低限必要なデータの表示と視覚化について説明します。

最も重要なことは、それは本当に素晴らしいアニメーションと強力で本当にクールに見える視覚的に魅力的なコントロールを含むべき「ネイティブアプリ」の力を実際に表示することです。

これをさらに一歩進めて、上記の機能（視覚化）の後に、データに深さの概念を作成し、別の成層圏に連れて行く2D / 3Dアニメーションを含めることができると言うことができますが、それは別の日だと思います; ））

良い出発点は、RadDataGrid（UWPオープンソース）を使用してパートナーのTelerikを調べることです。 私のクライアントの1つで、私はそれを使用しました、そしてそれは実際にうまくいきます。 超高速で用途が広いです。 難しいのはコードだけです。アーキテクチャを十分に理解していなければ、エンジンから何かを変更する方法はありません。

新しいDataGridはTelerikと同じくらいパフォーマンスが高いと思います。

WinUIチームがDataGridコントロールを検討しているのを見てとてもうれしく思います。

ToolkitDataGridを置き換える新しいコントロールから見たい最も実質的な改善：

• インデックスでDataGridRowを取得する機能
• DataGridRows自体に固有のイベント。 たとえば、DoubleTappedとRightTappedです。
• スムーズなスクロール
• セルの名前変更の入力検証
• 行アイコン用に特別に設計されたDataGridColumn
• 色などの簡単なカスタマイズ。

順序を移動するために各行の横にドラッグ可能なアイコンを配置する編集ボタンを持つオプションは、便利な機能です。 また、列の後ろにあるいくつかの影が持ち上げられて移動するのを見るのも素晴らしいでしょう（主なFluent属性の1つは深さであるため）。 ドラッグアイコンの横にある小さな上下の矢印は、マウス入力で行をより簡単に移動するのに適している場合があります。 矢印を使用して行を移動する場合は、微妙なスライドアニメーションがいい感じになります。 タッチ入力では、編集ボタンを押さなくても行を保持して移動するオプションも適切に機能する可能性があります。 これがすでにサポートされているかどうかはわかりませんが、ファイルエクスプローラーのように選択チェックボックスが表示され、どのDataGridが行選択をサポートしているかがわかり、UX全体が向上します。 iOSリマインダーアプリには、これらのアイデアのいくつかが含まれています（下の写真の例）。 iOS Stocksアプリにも、移動可能な行を処理する同様の種類があります。 これらのアイデアのほとんどは、カラムにも最適です。

@NoahFellerこのタイプのアクションは、リストビューの方が理にかなっています。 グリッドビューでは、順序を並べ替えていないので、並べ替えオプションが必要ですが、ユーザーは物をドラッグしていません。

*編集
もう少し考えてみると、そのようなオプションがどのように役立つかがわかります。 ただし、これがデフォルトの動作であるべきではないと私は確信しています。

@NoahFellerこのタイプのアクションは、リストビューの方が理にかなっています。 グリッドビューでは、順序を並べ替えていないので、並べ替えオプションが必要ですが、ユーザーは物をドラッグしていません。

*編集
もう少し考えてみると、そのようなオプションがどのように役立つかがわかります。 ただし、これがデフォルトの動作であるべきではないと私は確信しています。

ええ、あなたはおそらく正しい@yaichenbaumです。 私はそれらの提案をカスタムソートを実行する機能として想定していましたが、ドラッグがそのために役立つかもしれないと思いました。 だから私は同意します、間違いなくデフォルトではありませんが、それはオプションとしてかなり役立つかもしれません。 フィードバックをお寄せいただきありがとうございます！

データグリッド機能に対するWPFデータテーブルの単純さ。 私は実際にこの1週間ほど戦ってきましたが、UWPデータグリッドをWPFでの動作に合わせて、DatagridをDataviewにバインドし、SQLからのDataviewにdatatable.defaultviewを入力することができました。 次に、グリッドにデータテーブルが表示されました。 実行するのは驚くほど簡単で、これまでのところUWPはこれを途方もなく複雑にしました。

クロスプラットフォームにする

単一セル選択モード、Excelスタイルをリクエストしたいと思います。
最終的な目標は、WinFormsDataGridViewとまったく同じ動作をするモードです。

さまざまなユースケースをサポートできるさまざまな仮想化オプションを用意する（リサイクルなどの単純なスクロール仮想化オプションから、データページングなどの他の概念まで）
多くの場合（これをサポートする同様のデスクトップコントロールでは）、これらのオプションの一部は、一意のデータを持つ列のカスタムテンプレートで使用すると失敗し始めます。 そのような場合にサポートできるものが多ければ多いほど、より良いものになります。

可能であれば、ページングコントロール＃268の提案を同期し、必要なフックをDataGridコントロールに追加する必要があります。

これは良い知らせです！ コミュニティツールキットに登場してからしばらくの間、DataGridのフロントで公式なものを待っていました。 これは、WinUI 3.0に欠けている最後のコントロールであり、コミュニティツールキットには適切な代替手段がありません。

まず、車輪の再発明をしないでください。 基本として、DataGridのWPF実装から始めます（コードを使用できないことはわかっていますが、APIを100％使用してください）-Silverlightのものではありません。 WPF DataGridははるかに機能が充実しており、テストでのバグが少なくなっています。

コミュニティツールキットDataGridを使用する際に、さまざまなユースケースで使用される次のAPIの追加もリクエストしました。

• RowPressed：上記のとおり。 行が押されたため、さらに処理またはコンテキストメニューが発生する可能性があることを示します。
• RowDoublePressed：RowPressedと同じですが、ダブルクリックバージョンです。
• ColumnHeaderPressed：列ヘッダーが押されるたびに発生します。 ソート方向の内部更新よりも優先する必要があります。 これにより、カスタムフィルタリングメニューまたは右クリックオプションで列のオン/オフを切り替えることができます。
• ColumnHeaderDoublePressed：ColumnHeaderPressedと同じですが、ダブルクリックバージョンです。
• ColumnHeaderWidthChanged：ユーザーが列ヘッダーの幅のサイズを変更するたびに発生します。 これにより、この情報をクリーンな方法で保存できます。 これは通常、UIの状態を復元するときに必要です。

また、ItemsSourceが変更された後、コミュニティのtakeitDataGridがスクロール位置を一番上にリセットすることに関して多くの問題が発生し続けています。 WPFのようにオフセットが保持されるように、これを修正する必要があります。 ただし、これを制御できる必要もあります。そのため、次のAPIも提案します。

• FirstRowInView（）：状態の復元に使用されるDataGridに表示される最初の行を返します。
• VerticalOffset：スクロールバーの状態を復元するために再度取得/設定します
• 水平オフセット：スクロールバーの状態を復元するための取得/設定

@RBridここでいくつかの分析にも役立ちまし

提案された新しいイベント、および既存のイベントに対するいくつかの改善：

| イベント| コメント|
| ：--- | ：--- |
| ContextRequestedForColumnHeader | 列ヘッダーが右クリックされたときのコンテキストメニュー（または他のフライアウト）の表示をサポートするため。 Windows.UI.Xaml.UIElement.ContextRequestedと同じですが、DataGrid全体ではなく列ヘッダー用です。 |
| ContextCanceledForColumnHeader | Windows.UI.Xaml.UIElement.ContextCanceledと同じですが、DataGrid全体ではなく列ヘッダー用です。 |
| ContextRequestedForRow | 行が右クリックされたときのコンテキストメニュー（または他のフライアウト）の表示をサポートするため。 Windows.UI.Xaml.UIElement.ContextRequestedと同じですが、DataGrid全体ではなく行用です。 |
| ContextCanceledForRow | Windows.UI.Xaml.UIElement.ContextCanceledと同じですが、DataGrid全体ではなく行用です。 |
| RowTapped | すでに選択されている行をタップする場合にも注意してください。 |
| RowDoubleTapped | Windows.UI.Xaml.UIElement.DoubleTappedと同じですが、DataGrid全体ではなく行用です。 |
| RowRightTapped | Windows.UI.Xaml.UIElement.RightTappedと同じですが、DataGrid全体ではなく行用です。 ContextRequestedForRowも参照してください。 |
| PointerPressedInRow | Windows.UI.Xaml.UIElement.PointerPressedと同じですが、DataGrid全体ではなく行用です。 |
| PointerReleasedInRow | Windows.UI.Xaml.UIElement.PointerReleasedと同じですが、DataGrid全体ではなく行用です。 |
| PointerMovedInRow | Windows.UI.Xaml.UIElement.PointerMovedと同じですが、DataGrid全体ではなく行用です。 おそらくPointerMovedInRowは、ポインタがキャプチャされている間だけトリガーされます。 |
| ColumnHeaderTapped | すでに選択されている列ヘッダーをタップする場合にも注意してください。 |
| ColumnHeaderDoubleTapped | Windows.UI.Xaml.UIElement.DoubleTappedと同じですが、DataGrid全体ではなく列ヘッダー用です。 |
| ColumnHeaderRightTapped | Windows.UI.Xaml.UIElement.RightTappedと同じですが、DataGrid全体ではなく列ヘッダー用です。 ContextRequestedForColumnHeaderも参照してください。 |
| ColumnHeaderWidthChanged | または、 ColumnHeaderResizedという名前を付けることもできます。 イベント引数には、ユーザーが変更したのか、プログラムで変更したのかを指定するブールプロパティを含めます。 明らかに、イベント引数は、どの列ヘッダーがサイズ変更/変更されたかを指定する必要があります。 |
| SortOrderChanged | 選択した列ヘッダーのリストが変更されたときにトリガーする必要があります。 また、選択した列のいずれかが昇順と降順の間で切り替えられたときにもトリガーされます。 イベント引数に、ソート順がユーザーによって変更されたか、プログラムによって変更されたかを指定するブールプロパティを含めます。 既存のイベントSortingも参照してください。 並べ替えがキャンセルされない場合、 Sortingイベントがトリガーされた後、新しいイベントSortOrderChangedがトリガーされると思います。 |
| Sorting | すでに存在しますが、並べ替え要求をキャンセルできるようにする設定可能なブールプロパティをイベント引数に追加することを検討してください。 たとえば、並べ替えが無効であるか実行できない可能性があり、キャンセルする必要があります。 また、ブールプロパティを追加して、並べ替えがユーザーによって要求されたか、プログラムによって要求されたかを指定します。 |
| ColumnSortDirectionChanged | このイベントは作成できますが、前述のSortOrderChangedイベントが作成され、ソート方向が変更されたときにSortOrderChangedもトリガーされる場合は、不要になる可能性があります。 |
| ColumnDisplayIndexChanged | すでに存在しますが、ユーザーが変更したのか、プログラムで変更したのかを指定するブールプロパティ（イベント引数）を追加することを検討してください。 また、 ColumnDisplayIndexChanged ColumnReorderedイベントと
| ColumnReordered | すでに存在しますが、ユーザーが変更したのか、プログラムで変更したのかを指定するブールプロパティを追加することを検討してください。 |
| SelectionChanged | すでに存在しますが、ユーザーが変更したのか、プログラムで変更したのかを指定するブールプロパティ（イベント引数）を追加することを検討してください。 |
| CopyingRowClipboardContent | すでに存在しますが、コピーではなく操作をカットするかどうかを指定するブールプロパティをイベント引数に追加することを検討してください。 または、カット用に別のイベントを作成します。 |
| CuttingRowClipboardContent | 存在しません。 ユーザーが行を切り取ろうとしたときにトリガーされるイベントを作成することを検討してください（control-Xホットキー、コンテキストメニューなどを使用）。 または、コピーとカットの両方の操作に対してCopyingRowClipboardContentをトリガーできる前述のブールプロパティを作成します。
| PastingRowClipboardContent | 存在しません。 ユーザーが貼り付けようとしたときにトリガーされるイベントを作成することを検討してください（control-Vホットキー、コンテキストメニューなどを使用）。 |

私にとって最も重要な機能は、100万行をメモリにロードしなくても、100万行以上を簡単に処理できることだと思います。 ISupportIncrementalLoadingインターフェイスは、これには十分ではありません。スクロールバーは、これまでにロードした行数（合計数ではない）のみを反映し、100万行に到達するには、最後までスクロールし続ける必要があるためです。そして、ますます多くのデータをロードして、メモリが不足しないことを願っています。 しかし、100万のデータレコードがあることがわかっている場合は、データグリッドにそのことを伝えます。高速でスクロールするか、最後にジャンプすると、最後の数行だけを指定するように求められます。
動的にプルするデータベース内の行のリストをスクロールすることを考えてください。

私にとって最も重要な機能は、100万行をメモリにロードしなくても、100万行以上を簡単に処理できることだと思います。 ISupportIncrementalLoadingインターフェイスは、これには十分ではありません。スクロールバーは、これまでにロードした行数（合計数ではない）のみを反映し、100万行に到達するには、最後までスクロールし続ける必要があるためです。そして、ますます多くのデータをロードして、メモリが不足しないことを願っています。 しかし、100万のデータレコードがあることがわかっている場合は、データグリッドにそのことを伝えます。高速でスクロールするか、最後にジャンプすると、最後の数行だけを指定するように求められます。
動的にプルするデータベース内の行のリストをスクロールすることを考えてください。

この。

「モダン」とは、軽量で迅速であることを意味します。エンタープライズアプリは通常、大量の内部データを並べ替えて適切なレコードを見つけて探索することを目的としています。 ページング、並べ替え、非同期増分読み込み、無限スクロール-これらはすべて、データグリッドを活用するデスクトップアプリの定番です。

MSは、新しいグリッドでこれらの機能を強調するサンプルアプリを作成し、これらのエクスペリエンスを向上させるために、時間の経過とともにエンタープライズ開発者からフィードバックを収集する必要があります。 その有効性を実証するために、World WideImportersのような大規模なデータセットから実行してもらいます。

@dotMorten

私にとって最も重要な機能は、100万行をメモリにロードしなくても、100万行以上を簡単に処理できることだと思います。

私もそれを望みます。 100万行のサポートを支援するために（つまり、必ずしも完全なソリューションではなく、支援を意味します）、DataGridは現在のデータバインディング手法をオプションにする必要があることをお勧めします。 現在、データバインディングは必須であると思います（私の知識が最新バージョンのDataGridで最新でない場合を除く）。 DataGridは、表示されている各行の各セル/列の値を取得するためにサポートされている唯一の方法として、 Windows.UI.Xaml.Data.Bindingを使用する必要はありません。

DataGridを使用すると、DataGridが行のセル/列の値を取得する必要があるときにDataGridが呼び出すデリゲートまたはインターフェイスインスタンスをアプリがDataGridに提供できるようにすることをお勧めします（または、このデリゲートまたはインターフェイスは行全体（すべての列の値）を取得できます指定された行の場合）。

理想的には（可能であれば）、DataGridはこのデリゲートまたはインターフェースが非同期で動作できるようにしTaskまたはIAsyncOperation<TResult>を返す場合があります。

または、DataGridが次の手順のように動作する場合、 TaskおよびIAsyncOperation<TResult>なしで非同期サポートも可能です。

1. DataGridは、行ID 50001のセル/列5の値を取得する必要があると判断します。あるいは、DataGridは、行ID50001のすべての列値を取得することを決定します。
2. DataGridは、指定された列/行または行全体のデータ値のロードを要求したことをアプリに通知するデリゲートまたはインターフェイスインスタンスまたはイベントハンドラーを呼び出します。
3. アプリは、要求された行データを非同期で取得します。 たとえば、SQLデータベースクエリを非同期的に実行できます。
4. アプリは、要求された行データの取得を終了します。 アプリは、行データをDataGridに提供するDataGridのメソッドを呼び出します。
5. DataGridは行データを表示するか、データを処理するために必要なその他のことを行います。

まず、すごい！ アイデアを提供してくれたすべての人に感謝します。 以下にいくつか具体的な回答がありますが、全体として、これらのコメントを大量に保存しており、すばらしい最新のDataGridを構築する方法を聞いて本当に楽しんでいます。 来てください！

@Pinoxは、その詳細な応答とスクリーンショットに感謝します。 あなたのウィッシュリストは素晴らしいです（特にそれらのクールなアニメーション！）-htmlにあるこれらの機能は良いインスピレーションポイントであり、シンプルですが、生活の質を大幅に向上させることに同意します。 今後の参考のために、このコメントを確実に保存します！

@verelpode、@robloo、@ duke7553 YES DataGridの特定のイベントに！ あなたがこれらに入れた詳細に感謝します。 タッチファーストおよびさまざまな入力用に設計しているため、このようなイベントは確実に実装する必要があります。

@ dotMorten 、 @ jkewley 、 @ verelpodeパフォーマンスは、間違いなくこのプロジェクトの主な動機の1つであり、新しいデータ仮想化ストーリーとItemsRepeaterなどの最新のコントロールの使用を通じて実装したい主な改善の1つです。 詳細がわかり次第、最新情報をお届けしますが、ご提案いただいたこれらの詳細に改めて感謝いたします。

Laz3rPanth3r @、@robloo、私たちはあなたを大声で聞いて、WPFや他のUIフレームワークに属しているデータグリッドを程好くクリア@keeganatorr -私たちは間違いなくこのリフレッシュではこれを考慮しています！

DataGridのすばらしい作業とフィードバックのリクエストに感謝します！ ここにいくつかの提案された拡張機能があります。

DataGridColumnのサブクラスがさらに必要

DataGridColumnの現在のサブクラス/実装は不十分です。 DataGridColumnの次の新しいサブクラスを作成することをお勧めします。

| 提案されたサブクラス| 説明|
| ：--- | ：--- |
| DataGridIconColumn | 一般的な要件は、リストの各行にアイコンを表示することです。したがって、取得したセル値をWindows.UI.Xaml.Controls.IconSourceタイプキャストし、レンダリングするDataGridIconColumnという名前のDataGridColumnサブクラスを作成することをお勧めします。 IconSourceインスタンス（各セルに異なるIconSourceインスタンスがレンダリングされます）。 |
| DataGridImageColumn | DataGridImageColumnは、 Windows.UI.Xaml.Controls.IconSource代わりにWindows.UI.Xaml.Media.ImageSourceをレンダリングする必要があることを除いて、提案されたDataGridIconColumnと同じように動作する必要があります。 |
| DataGridDateTimeColumn | 設定に応じて、日付や時刻を表示します。 セルの値をSystem.DateTimeOffsetまたはSystem.DateTime （両方ともサポート）にタイプキャストし、セルに表示されるテキストに変換します。 テキストへの変換は、 DataGridDateTimeColumnクラスのフォーマット設定/プロパティによって制御する必要があります。 もちろん、日付/時刻による並べ替えもサポートされている必要があります。 |
| DataGridTimeSpanColumn | セルの値をSystem.TimeSpanタイプキャストし、それをテキストに変換してセルに表示します。 テキストへの変換は、 DataGridTimeSpanColumnクラスのフォーマット設定/プロパティによって制御する必要があります。 もちろん、並べ替えもサポートされている必要があり、表示されているテキストではなく、 TimeSpanインスタンスを並べ替える必要があります。 |
| DataGridDataSizeColumn | セルの値をSystem.Int64 、 UInt64 、 Int32 、またはUInt32 （すべてサポート）にタイプキャストし、バイト単位のサイズ（テキストとして）に変換します）表示されます。 たとえば、1572864/1024/1024 = 1.5であるため、1572864は「1.5MB」と表示されます。 テキストへの変換は、 DataGridDataSizeColumnクラスの設定/プロパティによって制御する必要があります。 ソートは、表示されたテキストではなく、元の整数値を使用して実行する必要があります。 |
| DataGridCustomColumn | これは、 Windows.UI.Xaml.DataTemplateないことを除いて、既存のDataGridTemplateColumnと同様に動作するはずです。 デリゲート/コールバックまたはイベントを呼び出して、表示されたGUI要素サブツリーを生成および/または更新する必要があります。 |
| DataGridTextColumn | すでに存在しますが、アプリがオブジェクトからテキストへの変換と並べ替えの比較機能をオーバーライドできるようにするプロパティまたはイベントを追加することを検討してください。 これについては、メッセージの後半で詳しく説明します。 |

DataGridCustomColumnは次のようになります：

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

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

イベントDataGridCustomColumn.DisplayingCellがトリガーされると、イベントハンドラーは独自のUIElementサブツリーを生成または更新してDataGridDisplayingCellEventArgs.CellValueを表示し、プロパティDataGridDisplayingCellEventArgs.CellUIElementをそれに設定する必要がありますUIElementサブツリーを入力すると、DataGridがそれを表示します。

次回DataGridがこのイベントをトリガーするとき、DataGridはプロパティDataGridDisplayingCellEventArgs.CellUIElementをイベントハンドラーによって以前に生成されたUIElementインスタンスに設定して、イベントハンドラーが再利用/リサイクルおよび更新できるようにする必要があります同じUIElementサブツリー（ DataGridDisplayingCellEventArgs.CellValue値が異なる可能性があります）。 イベントハンドラーは、同じUIElementサブツリーをリサイクルするか、プロパティDataGridDisplayingCellEventArgs.CellUIElementを新しく作成されたUIElementサブツリーに設定することができます。

また、サブクラスDataGridCustomColumnを作成する代わりに、新しいDisplayingCellイベントを基本クラスDataGridColumnで直接作成する可能性も検討してください。 したがって、イベントDataGridColumn.DisplayingCellを使用すると、 DataGridColumnすべてのサブクラスに対して生成されたUIElementをカスタマイズまたはオーバーライドできます。

既存のDataGridTextColumnでは、現在、セル値/オブジェクトはSystem.Object.ToStringを呼び出すことによって表示用のテキストに変換されています。 アプリがこの値からテキストへの変換をオーバーライドできるようにするデリゲート/コールバックまたはイベントの作成を検討してください。 アプリがSystem.Collections.IComparerインスタンスを指定して、並べ替え動作をオーバーライドできるようにするプロパティも検討してください。

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

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

または、 DataGridTextColumnでComparerプロパティを作成する代わりに、基本クラスDataGridColumnでComparerプロパティを直接作成する可能性を検討してください。 DataGridColumnすべてのサブクラスの並べ替え動作を制御するアプリ。

同様に、 CellValueToToStringConverterプロパティも基本クラスDataGridColumnで作成できます。これは、 DataGridColumnサブクラスに関係なく、任意のセル値をテキストに変換できると便利だからです。使用されている。 たとえば、行をクリップボードにコピーする場合、各セルの値をテキストに変換できます。 （テキスト形式と非テキスト形式の両方をクリップボードに同時に配置できます。アプリは通常、他のアプリとの互換性を高めるためにこれを行います。）

DataGridIconColumnまたはDataGridImageColumnが選択された場合の再並べ替え：明らかに、DataGridはアイコンや画像を並べ替えることができないため、次のいずれかの解決策を使用できます。

• エンドユーザーがタイプDataGridIconColumnまたはDataGridImageColumn列ヘッダーを選択（並べ替え）できないようにするだけです。
• IconSourceクラスでAlternativeTextプロパティを作成します。 DataGridIconColumnが行を並べ替えるとき、またはセルをクリップボード/コピー用のテキストに変換するとき、 AlternativeTextプロパティを使用します。
• DataGridColumnまたはDataGridIconColumnいずれかで設定可能なComparerプロパティ（タイプSystem.Collections.IComparer ）を作成します。

選択した行/アイテムへのアクセス

現在の機能が不十分なため、選択した行/アイテムの取得と設定の機能を改善することを検討してください。 現在、これらのプロパティが存在します。

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

選択した行のDataGridRowインスタンスにアクセスする必要がある場合があるため、次のプロパティをDataGridに追加できることを願っています。

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

または、上記の実装が難しすぎる場合は、次の読み取り専用のバリエーションはそれほど強力ではありませんが、それでも役立ちます。

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

DataGridRowインスタンスがリサイクルされる

また、既存のSelectedIndexプロパティは、選択された1つのインデックスへのアクセスを提供しますが、選択されたすべてのアイテムへのアクセスを取得するのはどうでしょうか。 したがって、次のSelectedIndexesプロパティを作成することをお勧めします。

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

個人的には、DataGridはデータベースと組み合わせて使用​​されることが多く、データベースでは「インデックス」という用語の意味がまったく異なるため、「SelectedIndex」という名前はわかりにくいと思います。したがって、プロパティの名前を次のように変更することをお勧めしますが、名前の提案は拒否されます：

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

また、指定したDataGridRowやDataGridColumnをスクロールして表示できるようにしたいと思います。 現在、このメソッドが存在します：

public void ScrollIntoView(object item, DataGridColumn column);

既存のScrollIntoViewメソッドを次の2つのメソッドに置き換えることをお勧めします。

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

1回のヒットでソート順を取得および設定

アプリを開いたり閉じたりするときは、並べ替え順序やその他の設定など、エンドユーザーのDataGridの構成を保存および復元する機能が必要です。 ソート順とは、ユーザーが選択した列のリストを意味します。 これはリストであり、単一の列ではないことに注意してください。 複数の列を同時に選択することができます。つまり、並べ替え用の1番目の列、並べ替え用の2番目の列、並べ替え用の3番目の列などです。

したがって、DataGridで次のプロパティを作成できますが、実際にはこれは最初のアイデアにすぎず、理想的ではありません。

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

上記は、1回のヒットで各列のDataGridColumn.SortDirectionの保存と復元をサポートしていないため、理想的ではありません。 私は、アプリが複数のステップでそれを実行できることを認識しています。

1. 提案されたSortOrderプロパティを選択した列のリストに設定します。
2. 選択した各列のSortDirectionプロパティを設定します（列ごとにこの手順を繰り返します）。

複数のヒットがあるため、これは依然として問題があります。つまり、DataGridの複数の時間のかかる手段が発生します。 エンドユーザーは、DataGridが不必要に複数回再利用されると、多数の行を含むDataGridで大幅な遅延が発生することに気付く可能性があります。 この問題を解決するために、アプリが1回のヒットで完全な並べ替え順序を復元し、単一の手段しか発生させないようにする次のソリューションを提案します。

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

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

アプリはSortOrderプロパティによって返されるリストを変更できないため、上記のIList<DataGridColumnAndDirection> IReadOnlyList<DataGridColumnAndDirection>ではなくSortOrderプロパティを、DataGridがコピーして並べ替え順序リスト全体を完全に置き換えるために使用するリストに設定する必要があります。 したがって、1回のヒットで動作し、複数の高価なリゾートを回避します。

DataGrid.SortOrderが新しいリストに設定されると、DataGridは新しいSortOrderリストの各列に対応するDataGridColumn.SortDirectionプロパティも設定しますが、複数のリゾートを発生させることはありません。 したがって、 DataGrid.SortOrder[i].SortDirectionはDataGridColumn.SortDirectionと同等です。

表示された列の順序を1回のヒットで取得および設定します

アプリを開いたり閉じたりするときは、エンドユーザーの列の順序を、できれば1回のヒットで保存および復元する機能が必要です。 既存のプロパティDataGridColumn.DisplayIndexは設定可能であることがわかっているため、理論的には、アプリはDataGrid.Columnsすべての列を繰り返し処理し、それぞれのDisplayIndexを設定することで、エンドユーザーの構成を復元できますが、これはバグを引き起こす可能性があります。 たとえば、アプリが一時的に1つの列のDisplayIndex DisplayIndexを別の列の同じDisplayIndexが失敗したり、予期しない動作をしたりする可能性があります。 また、1回のヒットで実行されない場合、複数の高額な再描画や再計算がトリガーされる可能性があります。

したがって、DataGridでColumnDisplayOrderプロパティを作成することをお勧めします。

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

SortOrderについて前述したのと同じように、 ColumnDisplayOrderは、1回のヒットで動作するため、意図的にIReadOnlyList<DataGridColumn>ではなくIList<DataGridColumn>なります。
DataGrid.ColumnDisplayOrderが新しいリストに設定されると、DataGridは各列のDataGridColumn.DisplayIndexを更新して一致させます。

エンドユーザーが列を非表示/表示できるようにする

既存のプロパティDataGridColumn.CanUserReorderなどと一致して、 DataGridColumn CanUserChangeVisibilityプロパティを作成することをお勧めします。 DataGridColumn.CanUserChangeVisibilityがtrueの場合、エンドユーザーはプロパティDataGridColumn.Visibility変更を加えることができます。

実行時に動的に生成されるGUI要素をサポートする

DataGrid.RowDetailsTemplate （ Windows.UI.Xaml.DataTemplate ）を使用せずに、行詳細GUIを生成できるようにします。 これを実現するには、APIにいくつかの考慮事項を含める必要がありますが、これを行う方法についての私の最初のアイデアは次のとおりです。プロパティDataGridRowDetailsEventArgs.DetailsElement変更して、既存のイベントDataGrid.LoadingRowを介して行うことができます。イベントハンドラーがUIElementを単独で生成（または更新）し、 DetailsElementプロパティを設定してDataGridに渡すことができるように設定可能にする必要があります。

Windows.UI.Xaml.DataTemplate必須使用が問題になる理由：テンプレートは優れた機能ですが、テンプレートの概念では、開発者が事前に作成した、事前に作成された変更されていないXAMLスニペット/ドキュメントが必要です。 したがって、アプリが実行時にGUIを動的に生成する必要がある場合、テンプレートは問題になります。 したがって、私は前述のDataTemplate代替案を望んでいます。

行を内側と外側にドラッグアンドドロップします

オプションで行の送信ドラッグアンドドロップを有効にする機能を作成することをお勧めします。 DataGridはドラッグを実装しますが、ドロップは実装しません。 ドロップが発生すると、DataGridはイベントをトリガーし、アプリはイベントに応答して、行がDataGridの外にドロップされたときに目的のアクションを実行します。

また、オプションで、行またはアイテム/オブジェクトの着信ドラッグアンドドロップを有効にする機能。 DataGridは着信ドラッグアンドドロップを受け入れますが、ドロップを実装しません。 DataGridは、行/アイテム/オブジェクトがドロップされたときにイベントをトリガーし、アプリは、行がDataGrid内にドロップされたときに目的のアクションを実行するために、イベントに応答します。

個々のセルの背景

特定の時間（アプリが変更や重要な値、または安全限界を超える危険な値を検出した場合など）に個々のセルを（セルの背景色/ブラシを変更して）ハイライト表示することを希望するお客様からの機能リクエストがあります。

したがって、 DataGridCell.Backgroundプロパティ（タイプBrush ）を提案できますが、DataGridがDataGridCellインスタンスをリサイクルするため、この方法はおそらく欠陥があると思いますね。 したがって、 DataGridCell.Backgroundプロパティを設定して個々のセルをハイライトすることは、信頼性の低いソリューションになると思います。

より良い方法は、前のメッセージで提案したイベントDataGridColumn.DisplayingCellを使用することです。 イベントハンドラーは、 DataGridDisplayingCellEventArgs CellBackgroundBrushプロパティを設定できます。

ダムダウンDataGridによるデータ（セル値）の取得

「ダム」は非常に悪い音に聞こえますが、実際には、DataGridがデータ取得（DataGridによって表示されるセル値の取得）の領域でダムにされた場合、私はそれが大好きです。

現在、DataGridは、プロパティDataGrid.ItemsSource加えて、データバインディング手法（プロパティDataGridBoundColumn.Binding ）、およびSystem.ComponentModel.INotifyPropertyChangedなどのインターフェイスを介して、便利な自動方法でデータ取得を実行しようとしています。

はい、データバインディングは便利な機能ですが、実際には、その部門でDataGridに_less_を実行させたいと思っています。 いくつかのMicrosoftコンポーネントは、スマートにしようとする動作によって実際に大きな問題を引き起こしますが、実際にはスマートになりすぎて

_「自分でやらせてください。」_
最善の解決策は、DataGridなどのコンポーネント内で「自動的に」タスクを実行しようとして失敗するのではなく、アプリがタスクを実行できるようにすることです。 プロパティDataGridBoundColumn.BindingおよびDataGrid.ItemsSource介してデータを自動的に取得しようとするのではなく、DataGridで完全に自分でデータ取得を実行できるようにしたいと思います。

理想的には、アイテムを供給するためにプロパティDataGrid.ItemsSourceを使用する必要をなくしたいと思います。 @dotMortenは100万行について言及しました。 現在、DataGridではアプリがDataGrid.ItemsSourceを設定することが必須になっていますが、100万個のアイテムを含むリストオブジェクトを作成することは現実的ではありません。 したがって、DataGridがデータ取得部門で賢くなるのをやめ、代わりにDataGridBoundColumn.BindingとDataGrid.ItemsSourceを使用せずに、自分でデータ取得を完全に実行できるようにしたいと思います。

@anawishnoffは書いた：

パフォーマンスは間違いなくこのプロジェクトの主な動機の1つであり、新しいデータ仮想化ストーリーとItemsRepeaterなどの最新のコントロールの使用を通じて実装したい主な改善の1つです。

新しいデータ仮想化ストーリーによってパフォーマンスが向上するとおっしゃっていましたが、それは朗報ですが、DataGridが表示するセル値を提供するためにプロパティDataGridBoundColumn.Bindingを使用する必要もなくなりますか？

データ取得ジョブ全体がDataGridを使用するアプリにアウトソーシングされている場合、アプリは必要な方法でデータ取得を実行するための完全な柔軟性を備えています。 これにより、 @ dotMortenが言及した数百万行を含む、さまざまなデータ取得シナリオが可能になります。 ばかげてください：smile：

WPF DataGridのいくつかの不要な機能？

WPFバージョンのDataGridには、不要または非実用的と思われる機能がいくつかあり、これらの機能はWinUI DataGridでスキップできますが、これらの機能について異なる意見を持っている人もいると思います。

WinUI DataGridが、エンドユーザーがDataGrid内でセル値をインライン/直接編集できる機能を放棄した場合、何人の人が異議を唱えるでしょうか。 この場合、DataGridを使用するすべての場所で、インライン/直接編集機能を無効にするために、常にDataGrid.IsReadOnlyをtrueに設定します。 ユーザーは、選択した行を別のペインまたはパネル、またはRowDetails（ DataGrid.RowDetailsTemplate ）で編集できますが、DataGrid自体の内部で直接編集することはできません。

WPFDataGridにはCanUserAddRowsとCanUserDeleteRowsがあったため、WinUI DataGridはインライン/直接編集のサポートを終了する方向にすでに動いているようですが、これらのプロパティはWinUIDataGridにはもう存在しません。 インライン/ダイレクト編集機能を完全に削除してみませんか？ この考えに反対する人は何人いますか？

個々のセルの選択：WPF DataGridにはSelectionUnitプロパティがあり、 Cell 、 FullRow 、またはCellOrRowHeaderます。 この場合、常にFullRowに設定し、 Cellに設定する必要はありません。 ただし、ここで1人の人がすでに単一セル選択モードを要求していることがわかります。 私の質問は、セル選択モードが一般的な要求なのか、まれな要求なのかということです。

一方、個々のセルの選択は、ユーザーが行/セルをクリップボードにコピーするときに役立つ場合があります。 これにより、ユーザーは、行全体をコピーする代わりに、個々のセル（またはいくつかの隣接するセル）をクリップボードにコピーできます。 ただし、この機能が本当に価値があるかどうかはわかりません。

| WPFの疑わしい機能| コメント|
| ：--- | ：--- |
| DataGrid.IsReadOnly | たぶん、IsReadOnlyをfalseに設定する必要はありませんか？ |
| DataGrid.CanUserAddRows | WinUIDataGridには存在しません。 すでに放棄されているか、まだ実装されていない可能性があります（計画はわかりません）。 |
| DataGrid.CanUserDeleteRows | WinUIDataGridには存在しません。 すでに放棄されているか、まだ実装されていない可能性があります（計画はわかりません）。 |
| DataGrid.SelectionUnit | WinUIDataGridには存在しません。 |

うわー、ここで信じられないほどの議論。 ❤️

また、WPF DataGridAPIにも同意します。 WPF DataGridは、実際にはWinUI3.0に必要なDataGridです。

ただし、WPFDataGridでさえいくつかの機能が欠けています。 これまで、私の顧客のほとんどは、これらの機能を取得するために、より強力なサードパーティのDataGridを使用していました。

• 列ヘッダーのフィルター
• DataGridの上部にある完全なフィルター行
• 階層データの強力な表示。 一部のサードパーティのDataGridは、ネストされたDataGridを備えた強力なTreeViewのように機能します。 WPF DataGridはそのようなものを構築できますが、そのままではサポートしていません
• さまざまなデータ型のサポート。 たとえば、DateTime列のように。 WPFのDataGridでは、DataGridTemplateColumnを使用する必要があります

しかし、とにかく、あなたが何をするにしても、DataGridの構築は強力なステートメントであり、WinUI3.0へのコミットメントだと思います。 LOBアプリケーションの場合、組み込みのDataGridを含まないUIフレームワークを真剣に受け止めることはできません。 そして、この投資がWinUIのために行われたのを見るのは素晴らしいことです！

@thomasclaudiushuber

LOBアプリケーションの場合、組み込みのDataGridを含まないUIフレームワークを真剣に受け止めることはできません。 そして、この投資がWinUIのために行われたのを見るのは素晴らしいことです！

同意しました！ 私たちの場合、DataGridは、複数の場所で使用する非常に重要なコンポーネントであり、それなしでは生きていけません。

階層データの強力な表示。 一部のサードパーティのDataGridは、ネストされたDataGridを備えた強力なTreeViewのように機能します。

私はそのトピックに夢中になっています。なぜなら、あなたのように、状況によっては階層型DataGridが役立つと思うからですが、DataGridが階層型機能を実装すると、非常に複雑で困難になる可能性があり、 DataGridはおそらく大幅に遅延します。 新しい機能を階層的機能と非階層的機能の両方と互換性があるようにすることは複雑であるため、新しい機能を追加するのは困難です。

前述の複雑さ/遅延の問題を排除するために、次の解決策を提案します。 DataGridインスタンスを内部的に使用/ラップするHierarchicalDataGridという名前の別のクラスを作成します。 あるいは、 HierarchicalDataGridは公にDataGrid継承できますが、この継承は実用的ではないと思われるため、 HierarchicalDataGrid Controlを継承し、内部にDataGridます。 したがって、階層機能は、内部の非階層DataGridインスタンスを指示するHierarchicalDataGridレイヤーに実装されます。

上記のソリューションの主な利点は、 DataGrid非常に複雑にして管理できなくなり、開発に時間がかかることなく、 DataGrid詰まらせることなく目的の階層機能を提供できることです。

さまざまなデータ型のサポート。 たとえば、DateTime列のように。

同意します。 前のメッセージで提案したDataGridDateTimeColumnとDataGridTimeSpanColumnをチェックしてください。

@Pinox

ページ全体を簡単にフィルタリング

@thomasclaudiushuber

列ヘッダーのフィルター。 DataGridの上部にある完全なフィルター行。

フィルタは、エンドユーザーが探しているものを見つけるために多数の行を手動で調べることを余儀なくされる現在の状況ではなく、1つまたは複数の行をすばやく見つけるのに役立ちます。

しかし、ユーザーのフィルターテキストを非テキスト列と一致させる問題についてはどうでしょうか。 以外の意味の列DataGridTextColumnなどによるフィルタリングなど、 DataGridTemplateColumnなど？ DataGridColumn （およびサブクラス）にセル値をキーワードに変換して検索/フィルタリング/マッチングで使用できるようにする次のソリューションのようなものでこれを解決することをお勧めします。

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

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

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

ConvertCellValueToKeywordsメソッドの使用例を次に示します。

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

または、セル値をキーワードのコレクションではなく単一の文字列に変換することもできますが、キーワードコレクションを提案した理由は、キーワードを使用すると、行数が少ない場合でも高速で実行される検索アルゴリズムを使用できるようになるためです。非常に大きい。

Excelから過去を簡単にコピー
現在、ctrl + vを使用してExcelセルのコンテンツをdatagridにコピーする方法はありません。 これで、すべてのセルのコンテンツがデータグリッドの1つのセルにコピーされます。

SelectedItemsを依存関係プロパティとして作成し、選択した行を管理するときにデータバインディングを使用できるようにすることで、適切な複数の選択されたアイテムのサポートを提供してください。

@verelpode個々のセルの選択が、スプレッドシートタイプのアプリケーションに役立つことがわかります。 編集シナリオよりもビューシナリオの方が重要だと思います。 編集せずにデータグリッド内のデータを表示する場合、個々のセル選択の使用は見られず、常に完全な行選択があることに同意します。

@anawishnoff @ Laz3rPanth3rは同意すると思います。ツールキットのこことここにあるいくつかの問題は、データを簡単かつ簡単にDataGridに取り込むことができることが重要な機能です。 リスト内のオブジェクトのコレクションまたはexpandoオブジェクトにバインドすることで、グリッドをブートストラップできるはずです。 数値や文字列、基本的なデータ型の列をインテリジェントに選択できれば、それは素晴らしいことです。 開発者は、それを超えて個々の列をカスタマイズした後、いつでもより多くの作業を行うことができます。

個々のセルの選択がスプレッドシートタイプのアプリケーションに役立つことがわかりますね。

スプレッドシートでは、列ヘッダーはアルファベットの昇順文字A、B、C、D、…で名前が付けられ、すべての列がDataGridTextColumnを使用し、他の列を使用していないかのように、すべての列のタイプは同じです。タイプが必要であり、列名もアルファベットから自動的に生成されるため、実際には必要ありません。
DataGridとスプレッドシートのもう1つの違いは、列ヘッダーのいずれかをクリックしても、スプレッドシートは行を並べ替えないことです。

私のポイントは、DataGridとスプレッドシートの間には表面的な類似性（ほとんどは視覚的な類似性）しか存在しないということです。 DataGridは実際にはスプレッドシートのようには機能しません。 DataGridのセルデータ取得手法も、スプレッドシートにはあまり適していません。

私はDataGridが大好きですが、それを使用してスプレッドシートを実装しようとすると、機能が低下します。 スプレッドシートを実装したい人にとって、DataGridは正しい選択ではないと思います。

DataGridの既存の設計は、スプレッドシートよりもSQLデータベースとの整合性がはるかに高く、データベースが「単なるスプレッドシート」であると誰かが主張しようとすると、SQLデータベース開発者は大声で叫ぶでしょう。

@verelpodeあなたの貢献はとても詳細で考え抜かれたものです、そのすべてに本当に感謝します！ ご指摘のとおり、DataGridのデータソース/ ItemsSourceプロパティをバインドするというアイデアについてお話ししたいと思います。@ michael-hawkerも同様です。

現在、DataGridではアプリがDataGrid.ItemsSourceを設定することが必須になっていますが、100万個のアイテムを含むリストオブジェクトを作成することは実用的ではありません。 したがって、DataGridがデータ取得部門で賢くなるのをやめ、代わりにDataGridBoundColumn.BindingとDataGrid.ItemsSourceを使用せずに、自分でデータ取得を完全に実行できるようにしたいと思います。

これはおもしろいですが、パフォーマンスにとても興味があるので、もっと調べてみたいと思います。 具体的には、どのようなデータ状況/シナリオを探していますか？ DataGridをSQLクエリ結果、データベース、またはそれらの線に沿ったものに直接接続しますか？

@khoshroomahdiコピーアンドペーストとは、実行中のアプリのDataGridにExcelセルをコピーして、そのように入力することを意味しますか？ これは興味深いユースケースです。もっと聞きたいです。

@alexyak 、もう少し拡張してもらえますか？ SelectedItemsプロパティを使用すると、現在、DataGridで選択されたすべてのアイテムを取得できます（ただし、拡張選択モードを使用しますが、正確には複数選択モードではありません）。 ここにある他のいくつかのコメントから、DataGrid内での選択には間違いなく作業が必要であることがわかりますが、あなたの要求をよりよく理解したいと思います。

@anawishnoffはい。
エクセルセルにいくつかのデータがあり、実行中のアプリにそれらをコピーしたいと思います。

データにバインドされていないシナリオでは、何年も前に作成したWinForms DataGridViewコントロールが仮想モードをどのようにサポートしているかを確認する必要があります： https ：

現在、DataGridではアプリがDataGrid.ItemsSourceを設定することが必須になっていますが、100万個のアイテムを含むリストオブジェクトを作成することは実用的ではありません。 したがって、DataGridがデータ取得部門で賢くなるのをやめ、代わりにDataGridBoundColumn.BindingとDataGrid.ItemsSourceを使用せずに、自分でデータ取得を完全に実行できるようにしたいと思います。

それもいいと思います。 アイテムを手動で追加するか、ItemsSourceを設定できるListBoxのようなものを考えています。 とは言うものの、過去には、ページングを実装するためにデータベース全体の部分的なビューを表す新しいDataTableを生成するだけでした（これはこのための良いユースケースです）。 次に、そのDataTableのビューをItemsSourceに設定できます。 ですから、これは確かに良いことだと思いますが、高性能のために必須ではないようです。

コントロールを多かれ少なかれExcel（r）のサブセットに変えるすべてのコメントに関して、DataGridはセルの選択とセルごとの編集をサポートする必要があると思います。 ただし、外部アプリケーション間のコピー/貼り付けなどは、開発者が処理する必要があります。

@alexyak SelectedItemsを実際のバインド可能なDependencyPropertyにするリクエストに関しては、これは状態を復元するのにも最適です（これまでの私の機能リクエストのほとんどは、ビューステートを復元することです）。 これはフレームワーク全体の問題だと思いますが、私が知っているWinUI / UWPコントロールではサポートされていません。 これはおそらく一般的な機能要求であるはずです。 ここでの議論を参照してください

@anawishnoffは書いた：

あなたの貢献はとても詳細で考え抜かれたものです、そのすべてに本当に感謝します！

おかげで、私の貢献がDataGridをさらに良くするのに役立つと聞いてうれしいです:)

具体的には、どのようなデータ状況/シナリオを探していますか？ DataGridをSQLクエリ結果、データベース、またはそれらの線に沿ったものに直接接続しますか？

それはまだ賢すぎる。 このスマートな動作により、さまざまなアプリがさまざまな方法でデータ取得を実行できなくなります。 アプリが異なれば状況も大きく異なるため、「最良の」データ検索システムはアプリごとに異なります。単一の「最良の」データは存在しません。 たとえば、一部のアプリは数百行を超えて表示されませんが、他のアプリは@dotMortenのように百万行で動作する可能性があるため、1つの靴のサイズですべてに対応できるわけではありません。

私は本当にそれをこのレベルまで下げることを提案します：

1. DataGridは、外部データストレージシステムの行9001の列5に存在する値を表示する（または使用する）必要があると判断します。
2. DataGridは、行9001の列5の値が必要であることをアプリに通知します。
3. アプリは、行9001の列5の値を取得します。これには、非同期SQLクエリ、非同期C＃タスク、またはその他のデータシステムが含まれる場合があります。 理想的には、DataGridはこのステップを非同期にする必要があります。
4. アプリは、行9001の列5の値の取得が終了したことをDataGridに通知します。アプリはこの値をDataGridに渡します。
5. DataGridは、手順1で説明したように値を表示するなど、必要な方法で値を使用します。

@RBridは書いた：

データにバインドされていないシナリオでは、何年も前に作成したWinFormsDataGridViewコントロールが仮想モードをどのようにサポートしているかを確認する必要があります。

はいはいはい！ WinForms DataGridViewを使用したことはありませんが、今すぐドキュメントを読んだだけで、頭に釘付けになったと思います。 リンクしたウェブページには次のれています。
_ "仮想モードは、非常に大規模なデータストアで使用するように設計されています。" _

私は、WinFormsのことを見DataGridViewCellValueEventArgsは、これらのプロパティが含まれています。

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

これは優れていますが、理想的には、最新のC＃ asyncおよびawaitキーワード、または同等のUWP（ IAsyncOperation<TResult> ）、または任意の種類の時間遅延をサポートするように更新する必要があります。セル値を要求するDataGridと、セル値をDataGridに配信するアプリの間。 したがって、非同期をサポートするように更新するには、次のようにします。

1. イベントCellValueNeededを保持し
2. プロパティDataGridViewCellValueEventArgs.Valueを削除し
3. プロパティDataGridViewCellValueEventArgs.Valueをすぐに/同期的に設定する必要はなく、アプリが呼び出すSupplyCellValueような名前のメソッドをDataGridに作成します。

SupplyCellValueメソッドは、次のように定義できます。

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

したがって、実行時の手順は次のとおりです。

1. DataGridは、外部データストレージシステムの行9001の列5に存在する値を表示する（または使用する）必要があると判断します。
2. DataGridはイベントCellValueNeededをトリガーし、 DataGridViewCellValueEventArgs.RowIndexを9001に設定し、 DataGridViewCellValueEventArgs.ColumnIndexを5に設定します。
3. イベントハンドラー（アプリ）は、行9001の列5の値を取得する非同期タスクの実行を開始します。
4. 非同期タスクの実行が終了すると、つまりアプリが値を取得すると、アプリはメソッドDataGrid.SupplyCellValue呼び出します。

この易しく書き直さダウン技術は、スマート自動化技術よりも強力で柔軟性のあるDataGridBoundColumn.BindingとDataGrid.ItemsSource 。

@alexyak 、もう少し拡張してもらえますか？ SelectedItemsプロパティを使用すると、現在、DataGridで選択されたすべてのアイテムを取得できます（ただし、拡張選択モードを使用しますが、正確には複数選択モードではありません）。 ここにある他のいくつかのコメントから、DataGrid内での選択には間違いなく作業が必要であることがわかりますが、あなたの要求をよりよく理解したいと思います。

複数の選択を管理するために、ビューモデルに適切な双方向のデータバインディングが必要です

@verelpode 、さらに古いWin32ComCtl32コントロールの後にWinFormsDataGridViewモデルをモデル化しました。 特に、リストビューコントロールが仮想モードでLVN_GETDISPINFOメッセージをどのように使用したかを考えています（https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overviewを参照） ＃handling-virtual-list-view-control-notification-codesおよびhttps://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo）。 90年からの古いもの。

とにかく、非同期データ取得の側面を処理する方法は、「遅延イベント」によるものだと思います。
WinUIコントロールは、すでに2回遅延イベントを使用しています。

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

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

これは、新しいDataGridのCellValueNeededイベントが採用したいパターンです。 これにより、イベントハンドラーはデータを非同期的に提供し、それが完了したときにコントロールに通知できます。 https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferralを参照して

@RBrid
GetDeferral()が新しい標準パターンであることの良い点。 CellValueNeededこの特定のケースでは、他のケース/イベントよりもDeferralを使用するのがはるかに難しいようです。 私が間違っている場合は訂正してください。ただし、この特定のケースでGetDeferral()を使用する場合の問題は、 GetDeferral()が呼び出されるたびに新しいオブジェクトを作成することであり、これにより過度につながると思います。潜在的に多数の行のすべての行のすべてのセルに対して、大量のオブジェクトの作成とクリーンアップが繰り返されます。 さまざまなGetDeferral()実装のソースコードを見たことがないので、これについて誤解される可能性があります。

言い換えれば、 Deferralがリサイクルをサポートするか、そうでなければGetDeferral()はるかに効率的にする方法がない限り、それはまだ賢すぎます。 SupplyCellValueメソッドを使用した私のばかげた提案は、該当するすべての行のすべてのセルに対して新しいDeferralインスタンスを作成、完了、および破棄するオーバーヘッドの発生を回避します。

1. GetDeferral()
2. Deferral.Complete
3. Deferral.Dispose
4. 上記の手順を何度も繰り返します。

セル値を取得するタスクは、アプリにアウトソーシングできる唯一のデータ管理タスクではありません。 仕分けも外部委託される場合があります。 したがって、単一のイベントCellValueNeededではなく、インターフェースを検討することを検討する価値があるかもしれません。 アプリは、特定のインターフェイスを実装するオブジェクトの形式でDataGridにデータ管理モジュールを提供します。 DataGridは、セル値を取得するためにこのインターフェイスを呼び出しますが、並べ替えなどの他のタスクも呼び出す可能性があります。

@dotMortenが言及した100万行をサポートするために、 CellValueNeededだけでは、ユーザーが列ヘッダーをクリックしてDataGridが100万行を並べ替えようとしたときに発生する他の問題を解決できません。 したがって、セルの取得と並べ替えは、前述のモジュール/インターフェースを介してアプリにアウトソーシングできます。

アプリがDataGridにデータ管理モジュール/オブジェクトを提供しない場合、理想的にはDataGridはデフォルトのデータ管理モジュールを使用します。 したがって、DataGridの既存のデータバインディングコードはすべて、DataGridから別の新しいクラス（ DataGridBoundColumn.Bindingなどを操作してデフォルトのデータ管理モジュールを実装するクラス）に移動されます。

つまり、並べ替えがアプリまたはそのデータ管理モジュールにもアウトソーシングされている場合、これにより、SQLサーバーに並べ替えを実行するように指示するデータ管理モジュールを作成するなど、100万行をサポートするさまざまなソリューションへの扉が開かれます。 -ユーザーが列ヘッダーをクリックして並べ替えを開始してから10時間または20時間以内に、DataGrid内の100万行の並べ替えを実行できなかった。

@verelpode 、はい、それは有効な懸念事項です。 DataGridがリサイクル可能なWindows.Foundation.Deferralオブジェクトのプールを所有していることを期待します。 実現可能性とパフォーマンスを確実に確認する必要があります。

行の詳細を機能として持つWindowsCommunity Toolkit DataGridに依存しているので（深刻なパフォーマンスバグがありますが、回避策があります）、この新しいデータグリッドにも同じオプションで機能としてそれを持たせたいと思います複数の行の詳細を同時に持つため。 サーバーからクライアントへのストリーミングデータシナリオに使用します。

@roblooは、ページングGUIに対して100万行を記録しました。

[100万行をサポートする]もいいと思います。 ....とはいえ、過去には、ページングを実装するためにデータベース全体の部分的なビューを表す新しいDataTableを生成するだけでした（これはこのための良いユースケースです）。 次に、そのDataTableのビューをItemsSourceに設定できます。 ですから、これは確かに良いことだと思いますが、高性能のために必須ではないようです。

ページングは​​便利な手法であり、言及する価値がありますが、かなりの欠点があります。それは、DataGridの並べ替え機能を実質的に役に立たないものにします。 同様に、DataGridの次のバージョンのフィルタリング機能についても同様です。 ページングにより、並べ替えとフィルタリングが役に立たなくなるか、少なくともあまり役に立たなくなります。

たとえば、2列または3列が日付列であり、ユーザーが2番目の日付列に最新（または最も古い）の日付を持つ行を表示したいとします。 したがって、ユーザーは2番目の日付列ヘッダーをクリックしてDataGridをその列で並べ替え、さらにクリックして並べ替え方向を降順から昇順、またはその逆に変更します。 これは、ページングが使用されていない場合、または行の総数が1ページを超えないほど小さい場合に最適ですが、複数のページが存在する場合は機能しません。

ユーザーはすべての行で最新（または最も古い）の日付を見つける必要がありますが、ページングされたDataGrid GUIは、すべての行ではなく、現在のページで最も新しい（または最も古い）日付のみを表示するため、ページングにより実質的に並べ替え（およびフィルタリング）が行われます。使い物にならない。

これにより、どの行がどのページに表示されるかという問題が発生します。 答えは、ページ/行がORDER BY使用しないSQL SELECTクエリを介して取得される場合、各ページには通常、行の実質的にランダムなサブセットが含まれるということです。 （私はユーザーの観点からランダムを意味し、真にランダムではありません。）

疑似ランダムはエンドユーザーには役に立ちません。 この問題のあるランダム性を排除するために、SQL ORDER BY （ソート方向を制御するためのASCまたはDESCキーワードとともに）使用することを検討できます。ランダムに長くなりますが、このORDER BY使用法は常に同じ列と同じ並べ替え方向で並べ替えられるため、まだ壊れています。つまり、並べ替え順序は、エンドユーザーが列をクリックして選択した並べ替え順序とは異なることがよくあります。 DataGridのヘッダー。

これを修正するには、ユーザーが別の列ヘッダーをクリックするたびに別のSQLクエリを使用する必要があります。 SQL ORDER BY ... ASC/DESCは、DataGridのエンドユーザーが選択した並べ替え順序と同じに保つ必要があります。 DataGridは現在これをサポートしていません。

提案された解決策は私の前のメッセージにあります：DataGridがソートをアプリ（または「データ管理モジュール」）にアウトソーシングできるようにすることを提案しました。 このアイデアにより、エンドユーザーが列ヘッダーなどをクリックしてDataGridの並べ替え順序を変更するたびに、アプリ（または「データ管理モジュール」）がSQL ORDER BY ... ASC/DESC変更できるようになります。

また、既存のイベントDataGrid.Sortingにイベント引数の設定可​​能なプロパティを指定して、アプリ（イベントハンドラー）が並べ替えをキャンセルして引き継ぐことができるようにすることも価値があります。 理想的には、イベント引数は、並べ替え順序の変更がプログラムで要求されたか、エンドユーザーが列ヘッダーなどをクリックして要求されたかを指定します。この場合、イベントDataGrid.Sorting名前をあいまいさの少ない名前に変更すると役立つ場合があります。現在、 Sortingイベントの意図と目的が明確でないためです。 他のメッセージで提案された

行を持つWindowsCommunity ToolkitDataGridに依存している
機能としての詳細（深刻なパフォーマンスバグがありますが、回避策があります）、
この新しいデータグリッドが機能としても機能するのが本当に好きです-同じオプションがあります
複数の行の詳細を同時に。 サーバーからクライアントへのストリーミングデータシナリオに使用します。

行の詳細のパフォーマンスの問題へのリンク： https ：
再現： https ：

良い出発点は、RadDataGrid（UWPオープンソース）を使用してパートナーのTelerikを調べることです。 私のクライアントの1つで、私はそれを使用しました、そしてそれは実際にうまくいきます。 超高速で用途が広いです。 難しいのはコードだけです。アーキテクチャを十分に理解していなければ、エンジンから何かを変更する方法はありません。

新しいDataGridはTelerikと同じくらいパフォーマンスが高いと思います。

syncfusionグリッド機能は素晴らしいですが、mvvmに対応していません。 だからあなたはもっとうまくやれるでしょう。

やあ、みんな！ この会話を続けましょう。 現在存在するDataGridドキュメントについてどう思いますか？

他のすべての関連ページにリンクしているメインドキュメントページへのリンクは次のとおりです。

新しいDataGridを作成する場合は、それに付随するドキュメントが一流で理解しやすく、開発者にとって重要なすべての問題とシナリオに対応していることを確認する必要があります。

_私たちが望んでいたトピックは何ですか？ 明確にできるトピックは何ですか？_

やあ、みんな！ この会話を続けましょう。 現在存在するDataGridドキュメントについてどう思いますか？

他のすべての関連ページにリンクしているメインドキュメントページへのリンクは次のとおりです。

新しいDataGridを作成する場合は、それに付随するドキュメントが一流で理解しやすく、開発者にとって重要なすべての問題とシナリオに対応していることを確認する必要があります。

_私たちが望んでいたトピックは何ですか？ 明確にできるトピックは何ですか？_

xamlとそれらを作成するためのコードとともに、典型的なDataGridセットアップを示す画像が役立ちます。

xamlとそれらを作成するためのコードとともに、典型的なDataGridセットアップを示す画像が役立ちます。

@mdtauk 「典型的」であると思われる特定のDataGridセットアップ、またはDataGridが使用するのに最適であると一貫して判断するユースケースはありますか？

xamlとそれらを作成するためのコードとともに、典型的なDataGridセットアップを示す画像が役立ちます。

@mdtauk 「典型的」であると思われる特定のDataGridセットアップ、またはDataGridが使用するのに最適であると一貫して判断するユースケースはありますか？

WinUI 3.0の時間枠については、一般的なWPF、Win32データグリッド/アイコンビューのシナリオを示していると思います。 マイクロソフトがFluent / Modern DataGridUIデザインと見なしているものと同様に。

つまり、コントロールの背後にある考え方が、古いUIからWinUI3への移行を促進することである場合です。

@anawishnoffこれらのシナリオの多くがどこにあるかについて、人々がドキュメントを探していたという点で、ツールキットからの質問のいくつかは

• テーマ設定/再テンプレート化/調整
• データバインディング（一般およびXAML）
• イベント/選択処理/ケーシング
• 動作の編集（特にクリックで編集）
• マルチページング（＃60および＃268とうまくペアリングする必要があります）
  
  
  
  • データの読み込み中にアニメーション調整を読み込む
  
  
• コピー/貼り付け/フォーマット
• さまざまな列データ型（およびカスタムデータ型）（列挙型など）
• コンテキストメニュー
• アクセシビリティ

既存のToolkitDataGridには、ItemsSourceプロパティにIEnumerableが必要であることに気付きました。 これは論理的な決定のように見えますが、Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector（）によって返されるオブジェクトをこのプロパティとして設定することは不可能です。 （返されたオブジェクトをキャストする方法がない限り）さらに、ListViewやGridViewなどの他のコントロールは、ItemsSourceプロパティをオブジェクトタイプの値に設定することをサポートしています。 確かではありませんが、これをサポートすることで、ストレージ操作中の応答性の高いユーザーインターフェイスが可能になる可能性があります。

@mdtauk 「典型的」であると思われる特定のDataGridセットアップ、またはDataGridが使用するのに最適であると一貫して判断するユースケースはありますか？

WinUI 3.0の時間枠については、一般的なWPF、Win32データグリッド/アイコンビューのシナリオを示していると思います。 マイクロソフトがFluent / Modern DataGridUIデザインと見なしているものと同様に。

つまり、コントロールの背後にある考え方が、古いUIからWinUI3への移行を促進することである場合です。

Win32の例（ファイルエクスプローラー）

WPFの例

ファブリックWebの例

UWPの例

@mdtaukこれらのスクリーンショットをありがとう！ 以前のバージョンのコントロールで機能していた主要な要素を強調し、新しいコントロールでそれらをどのように実現できるかを文書化することが重要だと思います。

@ michael-hawkerすごい。 このスレッドで何度も取り上げられているトピックをすでにいくつか見ているので、それらは間違いなく開始するのに適した場所です。

@ duke7553それに対する解決策について、またはオブジェクト型をサポートすることが賢明であるかどうかについて、100％確信が持てません。 たぶん@RBridはチャイムを

@ anawishnoff ＆ @ duke7553 、新しいWinUIItemsRepeaterコントロールの上に新しいDataGridコントロールを構築します。 そして、そのコントロールはそのItemsSourceをオブジェクトとして公開します。
Object ItemsSource { get; set; };

TelerikのようにCellDecorationStyleSelectorをサポートすることを願っています。

@anawishnoff

ネイティブのWinUIコントロールに移行することに関心があります

うーん、「卒業」と言うとき、それはC ++へのダウングレードを含みますか？ 現在、WinUIのDataGridはC＃で記述されています。 「卒業」が「格下げ」を意味しないことを願っています。 重要なことに、WinUIは、WinUIチームが重要なすべての点でWinUIがWPFよりも優れていると言えるようになる必要がありますが、この目標はひどく遅れています。 DataGridなどのコードをC＃からC ++に不必要にダウングレードするために時間/リソースが浪費されると、この目標はさらに遅れることになります。

WinRT / UWP / WinUIをC ++で作成する理由は元々存在していましたが、残念ながらその理由は実現せず、Google / Androidがスマートフォンの市場シェアの大部分を占めていたため、C ++を使用する本来の理由はもはや当てはまりません（簡単に）後から言ったが、先に言うのはそれほど簡単ではない）。 WinUIが最初からC＃で記述されていた場合、WPFよりも優れた目標は3年前に達成されていたはずですが、現在は8年でまだ達成されておらず、目標がいつ達成されるかを正確に言うことはできません。 うまくいけば、WPFよりも優れた目標とWinUI DataGridの「卒業」目標が、古くて生産性の低いプログラミング言語への不必要な変換によって遅れることはありません。

私はC＃が存在する前にC ++でプログラミングを始めたので、C ++に偏っています。人々は最初に学んだことを守り、_「古き良き時代」_を愛情を込めて覚えています。 C ++を好む傾向があるにもかかわらず、C ++の記述をやめたので、DataGridをC ++にダウングレードして遅延させるべきではないと思います。 それをC＃のままにして、この問題で人々によって提案されたさまざまな改善を行うことや、10年に達する前にWPFよりも優れた目標を達成することなどのより重要なことに焦点を当てます。

私はWinUIの多くの側面が大好きで、WinUIの多くの巧妙な改善に感謝しています。また、WinUIのアプリコードを作成していますが、正直な真実を知りたいですか？ 真実は悲しいことに、私はまだ今まで、ユーザーに任意のWinUIアプリをリリースしていませんでした、です。 ユーザーにリリースされるソフトウェアはWPFで記述されており、ソフトウェアが適切に機能し、GUIの最新化が含まれているため、ユーザーは気にしません。 私はWinUI用のアプリコードをたくさん書いてきましたが、それはすべて準備、計画、テスト、待機であり、ユーザーが実際に使用しているわけではありません。 来年、最初のWinUIコンポーネントがユーザーにリリースされることを願っていますが、この切り替えはユーザーよりもはるかに高く評価されます。 すべてが計画通りに進んだ場合、ユーザーは切り替えにほとんど気付かないでしょう。

Microsoftの観点からは、WinRT / UWPはリリース品質のソフトウェアであり、2012年からユーザーに公開されていますが、私の観点からは、UWPは依然として大きな実験です。 私にとって、 UWP（WinUIを含む）はすべて、私が何年も遊んでいる

UWPの最初の数年間、毎年私は次のように考えました。_ "エラー…来年まで待ちます。WPFにはまだUWPに欠けているものが多すぎます。きっと来年はもっと良くなるでしょう。" _
それから翌年になり、同じ考えを繰り返しました。 それから翌年になり、同じ考えを繰り返しました。 うまくいけば、今年はそれを言う最後の年であるか、少なくともそれが私の意図です。

WinUIはこれ以上の遅延を許容できません。 WinUIのDataGridをC＃コードのままにします。 生産性を向上させるために、C＃でさらにWinUIコードを書き始めます。 今では8年になり、Androidは大きな市場シェアを獲得しています。 それは厳しい状況です。

ちなみに、UWPはまだベータ版であると言ったとき、私は実際に親切で寛大でした。技術的には、UWPはベータ版ではなくアルファ版の定義と一致するからです。 真のベータ版であるためには、機能が完全である必要がありますが、UWPはまだ機能が完全なステータスに達していないため、UWPはまだアルファ版です。 たとえば、ウィキペディアの「ソフトウェアリリースライフサイクル」の記事には次のように書かれています。

「ベータフェーズは通常、ソフトウェアが機能を完了したときに始まりますが、既知または未知のバグが多数含まれている可能性があります。」
「Alphaソフトウェアには、最終バージョンで計画されているすべての機能が含まれているとは限りません。」

ウィキペディアでは、「フィーチャーコンプリート」を次のように

「ソフトウェアのフィーチャーコンプリートバージョンには、計画された機能または主要な機能がすべて実装されていますが、バグ、パフォーマンス、または安定性の問題のため、まだ最終版ではありません。これは、開発のアルファテストの最後に発生します。」

UWPを機能が完全であると説明するのは不合理です。なぜなら、それが本当に機能が完全である場合、UWPはWindows '95のすべての機能に加えてそれ以上の機能を備えている必要がありますが、そうではありません。UWPはまだすべての領域でWindows95を超えていません。 。 Windows95は25年前にリリースされました。 UWP / WinRTが7〜8年前にリリースされたとき、Microsoftは9億ドルの損失を被り、Windowsストアのアプリが大幅に不足していました。 これはリリースバージョンとしてラベル付けされたアルファバージョンであったため、アプリ開発者は待ち望んでいました。 ほぼ8年後の今日、それはまだアルファ版であり、非常に遅れています、そして私はまだ待っていて、見ていて、待っています。

マイクロソフトがUWPの真のベータ版の作成を優先し、その後すぐに真のリリース候補版を作成することを真剣に決定/コミットすることは、マイクロソフトと開発者にとって非常に有益です。 これは強く推奨され、非常に賢明な行動方針です。 それは誰にとっても素晴らしいことです。

UWPは、さまざまな理由でまだアルファ/不完全です。たとえば、25年前、Windows 95の「MoveFile」関数を使用してファイルまたはフォルダーを移動するのは簡単でした（関数の名前は「MoveFile」でしたが、両方のファイルをサポートしていました）。およびフォルダ）。 UWPはフォルダを移動できますか？ いいえ、まだです。 明らかに、フォルダーを移動する機能は基本的な基本的な必須機能の1つですが、UWPにはまだこの必須機能などが欠けているため、UWPを機能完了と説明するのは不合理です。したがって、UWPはまだベータ版のステータスに達していません。 7〜8年前にリリースされました。 Microsoftは、UWPの真のベータ版を優先する必要があります。

私の知る限り、UWPの問題（UIの問題を除く）を追跡するためのパブリックGitHubリポジトリはまだ存在していません（またはUWPリポジトリが存在する場合は見つかりませんでした）。 繰り返しますが、これはアルファバージョンの定義と一致します。これは、公開の問題追跡レポがアルファ段階では望ましくない場合が多いためです。 真のベータ版またはリリース版の場合、公開の問題追跡リポジトリが既に開かれており、UWPにはWindows 95、Windows7などのすべての機能が含まれています。

この状況はDataGridにどのように影響し

比較のために、ほとんどのWPFは2006年から2010年までの4年間で正常に完了しました。UWPとは異なり、WPFは主にマネージコードです。 UWPはアンマネージコードであり、8年間の開発後も、Windows 95はいくつかの分野でUWPを上回っています。したがって、マイクロソフトがマネージコードの生産性が向上すると主張したとき、マイクロソフトは明らかに正しかったのです。 この問題はできるだけ早く解決する必要があります。 WinUIは、両方のプロジェクトが同じ所有者（Microsoft）を持っているため、WPFよりもはるかに簡単/高速に作成できるはずです。したがって、WinUIはWPFからコードを自由にコピーできます。 したがって、WinUIはWPFの開発時間の約半分を必要としていたはずです。 実際には、WinUIは開始されるべきではなく、Microsoftは新しいバージョンのWPFでWinUIの機能を開発する必要がありました。WinUIはWPF5.0である必要があります。 したがって、状況は大きな混乱であり、マイクロソフトがこの混乱の残りのクリーンアップを優先し、数十億ドルの間違いを以前よりもさらに悪化させるようなことをやめることは非常に有益です（そしてあなたが見ているときはまだです今日のスマートフォンの市場シェアの状況で）。

これは、さらに多くの損失を防ぐために、マイクロソフトが過去にすでに言ったこと/知っていたことを覚えておくことで利益を得るということを意味します。

• Microsoft自身の主張によれば、マネージコードは生産性を向上させます。 WPFの4年間と比較したUWPの8年間を見ると、Microsoftはマネージコードの利点に関して正しかったという結論に違いありません。
• スクリプト言語はスクリプト用であり、プログラミング言語はプログラミング用です。 JavaScriptとPowerShellは、本来の目的（スクリプト）には適していますが、アプリのプログラミングには明らかに不適切な選択です。
• 成功するには、Microsoftはアルファ版からベータ版、リリースに進む必要があります。これは、「リリース」というラベルの付いた不完全なアルファ版ではなく、真のリリースバージョンである場合にのみ成功します。 したがって、Microsoft Storeは、非常に長い間ほとんど空でした。
• ソフトウェアエンジニアや他の従業員は、妥当な報酬と妥当な労働時間、そして健全な労働環境と引き換えに働くときに最もよく働きます。 明らかに、マイクロソフトの数十億ドルの損失は、無給の狂信者/熱狂者と彼らのいわゆる「昼間の仕事」と「夜の仕事」と彼らの持続不可能な/不健康な労働条件の使用によって決して元に戻されません。
• Androidの大きな市場シェアの獲得は、無給の狂信者のおかげではありませんでした。 未払いの狂信者が勝利の理由だったとしたら、Linuxは失敗しなかっただろう。 説明ははるかに簡単です。Androidタブレットとスマートフォンの価格は、Windowsタブレットとスマートフォンよりもはるかに安いです。 明らかに、エンドユーザーは「オープンソース」の宗教/イデオロギーを気にせず（ユーザーはそれが何であるかさえ知らない）、Androidデバイスの安い価格を単に愛しているだけです。
• Win16は非常に時代遅れです。 それは、プログラミングの初期の「ワイルドウェスト」時代からの20〜30年前の技術です。 したがって、Win16に基づく新しいコードの記述は停止してください。 それを「Win32」と呼んでも、それがまだ基本的にWin16であるという事実は実際には変わりません。 Win32はWin16と同じですが、ポインタのサイズが16ビットから32ビットに拡張されている点が異なります。 Microsoftのあまりにも多くのグループが、Win16 / 32に基づいた新しいコードを書き続けています。 これは非常に非効率的で、リソースの大きな浪費です。

@anawishnoff

ネイティブのWinUIコントロールに移行することに関心があります

ウィキペディアの記事「埋没費用」も参照してください。

埋没費用効果（またはコンコルド効果）は、行動が埋没費用の誤謬に従うことが多いという事実です。 人々は、「お金、努力、または時間への投資が行われると、努力を続ける傾向が強くなる」ことを示しています。 この振る舞いは「悪い後に良いお金を投げる」と表現されるかもしれません、そしてそれに屈することを拒否することは「人の損失を減らす」と表現されるかもしれません。

同様に「計画継続バイアス」 ：

計画の継続バイアス、get-there-itis、またはpress-on-itisは、失敗している計画を継続するのは賢明ではない傾向です。 これは、致命的な災害につながる場合でも計画されたコースに固執する可能性があり、代わりに中止する必要がある船の船長または航空機パイロットにとって危険な危険です。 .....プロジェクトは、計画の誤謬や、過度の楽観主義、失敗を認めたくない、集団思考、埋没費用の損失への嫌悪感などの関連要因により、コスト超過や遅延に苦しむことがよくあります。

WinRT / UWPにより、Microsoftは1年目または2年目に9億ドルの損失を被り、空のアプリストアが長すぎました。 WinRT / UWPは壊滅的な障害であったため、2年目に中止する必要がありましたが、「計画継続バイアス」と埋没費用の損失への嫌悪感から継続されました。 このようなものは、管理コースで教えられています。 計画の継続により、WinRT / UWPの壊滅的な障害が最終的に消去または逆転されましたか？ いいえ、スマートフォンの市場シェアの観点から見ると、今日でも壊滅的な失敗です。 ウィキペディアのこれらの説明は、UWPの状況を正確に説明しています。

今日、WinRT / UWPのリリースから7〜8年後の現時点では、UWPをキャンセルするには遅すぎることに同意する必要がありますが、これは、「計画継続バイアス」の犠牲になっていることを意味します。 "そして埋没費用の損失への嫌悪感。

では、状況を救うために合理的に何ができるでしょうか？ 何年も前にキャンセルされるべきだったのに、UWPをキャンセルして状況を救うことはできません。 私たちにできることは次のとおりです。WinRTによって行われた巨大な損傷を受け入れますが、それ以上の損傷を引き起こさず、プロジェクトの手順/ポリシーを変更します。 これは、WinRTの同じ壊滅的なミスの繰り返し/継続を停止することを意味します。 たとえば、このような大量のマネージコードを非生産的な古いアンマネージ「ネイティブ」コードにダウングレードするのはやめましょう。 真のベータステータスに到達するまでの遅延はすでに非常に大きくなっています。なぜ遅延をさらに悪化させるのでしょうか。

DataGridが管理されていない「ネイティブ」コードにダウングレードされた場合、「計画継続バイアス」/埋没費用の間違いが続きます。 WinRT / UWPなどの壊滅的なミスが発生した場合、この同じミスが何度も繰り返されると、さらに悪化します。 ダメージを抑えるためには、同じ過ちを繰り返さないようにする必要があります。 WinRTの壊滅的な失敗から学び、進行中の失血を止めるために包帯を適用し始める時が来ました。

DataGridをアンマネージドコードに変換することは、図書館に行き、最も知識/経験のある最高の著者から最高のプロジェクト管理本をすべて借りて、これらの優れた管理本をすべて焚き火に投げ込み、燃えるのを見るのと同じです。

@verelpode DataGridに関する2つの非常に大きな投稿について、ここでのポイントが何であるか

@ dotMorten-これらのメッセージに詳細を書いた理由は、問題を適切に説明しないと、人々がそれを理解できないためです。 しかし悲しいことに、今では余分な詳細が失敗し、とにかくそれがまだ理解されていなかったことがわかります。 それは非常に苛立たしいことです。 このような問題を人々に説明しようとするのは無意味だと信じているので、多くの人がフィードバックをまったく書かないのはこのためです。メッセージがうまく理解されたとしても、それを撮影するのは人間の本性です。悪い知らせを伝える人、何も言わない方がいい、または反対を考えながら「丁寧に」微笑む。

それはv3でそれから完全に解き放たれているので。

このv3のバインド解除は、同じ間違いの繰り返しを防ぐことはできません。 「計画継続バイアス」はまだ存在しています。

Microsoftのホームページに移動します。
https://www.microsoft.com/en-us/
次に、WindowsPhoneが表示されるまでホームページを下にスクロールします。 おお！ それを見て！ ホームページの最後に到達しました。Microsoftのホームページでは、WindowsPhoneについてはどこにも言及されていません。 これは何を意味するのでしょうか？ つまり、目を覚ます。 私が言ったように、それはUWPが壊滅的な失敗であったことを意味します。 つまり、UWPの失敗につながったのと同じ間違いを繰り返すのをやめることが重要です。 つまり、災害から救助し、回復するために計画を変更することです。
WinUIとDataGridがUWPの失敗と同じ間違いを繰り返し続けると、管理上の間違いになります。

「2016年5月、マイクロソフトはモバイルビジネスを根絶しました。....2017年、マイクロソフトのエグゼクティブであるジョーベルフィオーレは、市場シェアの低下とアプリ開発。」
-https：//en.wikipedia.org/wiki/Microsoft_Mobile

Anaは、wrtDataGridに関するフィードバックを提供するための5つのポイントをリストしています。 それらの点のどれについてコメントしていますか？ それはあなたが書いているものから私が得られないビットだと思います。 UWPはすべての人のニーズを満たしているわけではありませんが、WinUI3はUWPアプリモデルの使用を指示していません。あなたは主にUWPに反対しているようですか？ だからあなたはそこで元気になるはずです。

あなたは、DataGridがそれが犯したのと同じ過ちを犯し続けるべきではないと述べました。 では、特に既存のDataGridの間違いはどれですか。また、それらを修正する必要があることをどのように提案しますか。 （何らかの理由でC ++に実装されたくない場合は別として）

@dotMorten

Anaは、wrtDataGridに関するフィードバックを提供するための5つのポイントをリストしています。 それらの点のどれについてコメントしていますか？

メッセージの冒頭でアナを引用した部分。 メッセージの冒頭で引用したアナのメッセージの一部についてコメントしています。

WinUI3は、UWPアプリモデルの使用を指示しません

それは私のメッセージとは無関係です。 WinUI 3がバインドされておらず、nugetパッケージを介して利用できることは、WinUI3がUWPとWindowsPhoneの失敗、およびMicrosoftの数十億ドルの損失につながったのと同じ管理ミスを続けるかどうかという問題とは無関係です。

それらを修正する必要があることをどのように提案しますか？

以前のメッセージの最後にある6つの箇条書き。 2番目の箇条書き（スクリプト）は、一般にWinUIとUWPに関連していますが、DataGridには関連していません。 DataGridについて具体的に質問する場合は、最初の箇条書きが最も重要です。
私も書いた：そのような大量のマネージコードを非生産的な古いアンマネージ「ネイティブ」コードにダウングレードするのをやめなさい。 真のベータステータスに到達するまでの遅延はすでに非常に大きくなっています。なぜ遅延をさらに悪化させるのでしょうか。

@anawishnoffは書いた：

ネイティブのWinUIコントロールに移行することに関心があります

「ネイティブのWinUIコントロールに移行する」とは、ウィキペディアで言及されている「市場シェアの喪失とアプリ開発の欠如」につながった同じ間違いのいくつかの継続/繰り返しを実質的に構成します。

「2016年5月、マイクロソフトはモバイルビジネスを根絶しました。....2017年、マイクロソフトのエグゼクティブであるジョーベルフィオーレは、市場シェアの低下とアプリ開発。」
-https：//en.wikipedia.org/wiki/Microsoft_Mobile

DataGridがMicrosoftのモバイルビジネスを破壊したのと同じ道を歩み続ける必要があるのはなぜですか？

@verelpode

WinUI 3は、UWPとWindows Phoneの失敗、およびMicrosoftの数十億ドルの損失につながったのと同じ管理ミスを続けています。

私はマイクロソフトで働いていませんが、WinUIが管理ミスを犯しているとあなたが言う理由に興味があります。
WinUIがオープンソースであり、誰もが会話や意思決定に貢献できるという事実から、WinUIとは何かを定義するのに実際に役立っており、間違いの発生を防ぐ必要があります。
あなたは、DataGridがモバイルと同じ道を進んでいると言っていますが、ピッチのどこにもモバイルについて言及していませんでした。 おそらく、この問題が話していることに直接フィードバックを残すことができます。
WinUIに誤った管理手順があると感じた場合は、懸念事項について別の問題を作成できる可能性がありますが、コメントがDataGridコントロールとは関係がないと思います。

@verelpodeは、このトピックに関するフィードバックをここに保管してください。 WinUIまたはUWP全般について懸念がある場合は、新しいディスカッショントピックを開始するか、直接私に連絡してください（Twitterで私またはDMに電子メールを送信してください）。 または、＃717や＃1531などの既存のトピックについて話し合うことを検討してください。

DataGridがC ++で書き直されることについての懸念を共有しましたが、実際には、元の提案ではそれについて何も言及されていませんでした。 @anawishnoffは、DataGrid機能セットに関するフィードバックを収集しようとしています。 実装に関しては、C＃で保持するのが最も理にかなっている場合は、それを実行します（WinRTコンポーネントとして実行した場合でも、C ++から呼び出すことができます）。

@ jevansaks-私のフィードバックは話題になりましたが、悪いニュースを伝えるメッセンジャーを撃つのは人間の本性です。 あなたの反応は私を悲しくて失望させます。 OK、私は助けようとするのをやめます。なぜなら、それは正直で直接的であり、認識して解決するにはあまりにも苦痛である痛みを伴う問題に触れているためです（WinRTの壊滅的な失敗はあまりにも多くの感情を引き起こし、消去するのが簡単です）それをメモリから取得し、災害が発生しなかったかのように、同じ古い元のWinRTプランを続行します）。 本当の問題について正直に直接話し続けることは人々を苛立たせるだけなので、私はこの議論を終了し、DataGridの開発にこれ以上参加しません。

@verelpodeここで「悪いニュースを伝えるメッセンジャーを撃った」人は@jevansaksは、このリポジトリでUWP / WinUI / WinRTに関する幅広い懸念を共有するために、新しい問題を開くように招待しました。 この問題は実際にはDataGridに関するものであり、実際に懸念事項の1つはDataGridに関するものでしたが、大部分はUWP / WinUI / WinRT全般に関するものでした。 この議論をもう一度見てみると、WinUIチームは、この問題をDataGridの提案のみに焦点を当てたままにし、新しい/既存の問題を使用して、プラットホーム。

あなたが言及した懸念は、WinUIチームとコミュニティの両方が関与する興味深い議論の基礎となる可能性がありますが、この特定の問題はそのような議論には適していません。

@anawishnoff
Microsoft Pivot ViewerControlはhtmlではなかったと確信しています。 振り返ってください。 そのようなものを使用して大量のデータセットを視覚化する機能は、私たちが時々やりたかったことでした。 Silverlightで利用できたと思います。 https://www.microsoft.com/silverlight/pivotviewer/default#機能にDeepZoomを使用しました。 WinUI 3.0にディープズーム機能を追加するのは素晴らしいことです！ 実際にはデータグリッドではなく、データ表示コントロールです。 Deep ZoomのようなWPFの初期の頃からの「放棄された」アイデアはたくさんありますが、WinUI 3.0で時間をかけて生き返らせるのに素晴らしい、本番のWPFコントロールにはなりませんでした。 WPF博士を地下室から出して、もう一度投稿してもらいましょう。 彼が必要です。 動きを始める必要があります。 Dr.WPFを復活させてください!!!!! あなたはどこにいってしまったのですか？ WinUI博士!!!

@PaulMontgomerySPは、ピボットコントロールについて話し合うために新しい問題を開く必要があるようです。 ここで、Windows Community Toolkitからの以前の議論を参照してください： //github.com/windows-toolkit/WindowsCommunityToolkit/issues/770

キーボードで移動した行ごとに、選択変更イベントが発生します。
選択が変更されたイベントだけでなく、マウスクリックまたはセルタップのみのイベントがあると便利です。

選択変更イベントは、クリックとキーボードの両方で発生します。 クリックするだけのイベントがあると非常に便利です。

@ Going-Goneそのユースケースが何であるか知りたいですか？ なぜ違いを知る必要があるのですか？ また、タップされたイベントを使用することはできませんか？

UWP ToolkitのDataGridでヒットした制限の1つは、 DataGridTemplateColumnにCellTemplateがありますが、 CellTemplateSelectorがないことです（ CellEditingTemplateも同じことがありません）。 セレクターアプローチを使用して、各セルのUIをデータに適合させるのが簡単になります。これを処理するために、その下にある追加レベルのUIコントロールを使用してこれを行う必要はありません。

また、ここで詳しく説明したように、連続した順序だけでなく、行を選択できるようにしてください。
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

グリッドがサポートする必要があるクライアントから頻繁に要求されるものの特定の順序ではありません

1.フィルターを保存、ロード、構築する機能。 たとえば、linq式へのフィルター、SQLクエリへのフィルター、式ツリーへのフィルター、およびその逆。 例-https：//querybuilder.js.org/demo.html

1. 高速リアルタイムデータ機能、パフォーマンスが重要です。 トレーディングアプリケーションの1ミリ秒未満のリフレッシュレートと100万行を超える行では、パフォーマンスに関する考慮事項が異なります。
2. ソート順を指定する機能。例：i。 高/低の並べ替え、ii。 低/高を並べ替え、iii。 並べ替えなしまたはi。 低/高を並べ替える、ii。 高/低を並べ替え、iii。 並べ替えなし
3. Excelのようなフィルタリング
4. cssフォーマットをセルに適用する機能、条件付きフォーマット
5. フィルタ、列幅、並べ替えなどのグリッド設定を簡単に保存/ロードする機能
6. 動作するスクロール、たとえばデータ更新後にリセットされない、スムーズ。
7. データ収集イベントには、個々のオブジェクトではなく、範囲を読み込んだ後にイベントを発生させるオプションが必要です。 たとえば、ObservableCollectionには、追加された個々のオブジェクトごとにINotifyPropertyChangeが発生しないようにするためのサブクラスが必要だと思います。
8. データのロード/ロード、データのロードの開始、データのロード、特に非同期ロードを使用している場合のデータのロード時のイベントが改善されました。
9. グリッドは、データフィルター、範囲選択、クロスフィルター（https://github.com/dc-js/dc.jsなど）、グラフ、ピボットテーブルなどの他のコントロールにリンクされていることがよくあります。
10. 英数字データを処理するスマートソート。たとえば、ABC11、ABC111、ABC12の代わりにABC11、ABC12、ABC111のソート順
11. 無制限のレベルの階層グリッド（例： https ：

有用なリソース：-より良いデータテーブルを設計する
https://news.ycombinator.com/item?id=21460966
https://uxdesign.cc/design-better-data-tables-4ecc99d23356

ヘッダーから直接Columwidthにバインドすることはできません。 WPFでは、その場合はBindingProxyオブジェクトを使用する必要があります。

編集を容易にするためのアクティブな行の便利な動的サイズ変更。
編集モードでのコンテキストメニューのフルコントロール。

TelerikのようにCellDecorationStyleSelectorをサポートすることを願っています。

アクセシビリティ！
文書化されるように言及しますが、このコントロールは完全にアクセス可能である必要があります。
現在のツールキットバージョンには、この領域でいくつかの制限があります： https ： //github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079
また、Telerik RadDataGridにはいくつかの優れた機能がありますが、アクセシビリティをサポートしていないようです。

MicrosoftのD＆Iに対する大きな推進力により、すべてのコントロールに完全にアクセスできる必要性がどこでも要件として指定されていないことに驚いています。

おそらくこれはすでに可能であり、私はまだそれを達成する方法を知りません...しかし、カスタム行またはセルのスタイル設定はどうですか？

特定の行をターゲットにし、背景とテキストの色を変更する機能は素晴らしいでしょう。

WCT UWP DataGridと比較して：
1）パフォーマンス
2）より多くの組み込みの列タイプ（これらはテンプレート列よりもパフォーマンスが優れていると思います）
3）セルごとにマウスイベントをフックする機能、つまり、タップ、右タップ、ホバー（または下向きのポインターなど）
4）セルごとのキーボードイベント
5）（3）が機能しない場合、テスト機能にヒットしたかどうかをエミュレートできます
6）パフォーマンス

WinUI DataGridが、エンドユーザーがDataGrid内でセル値をインライン/直接編集できる機能を放棄した場合、何人の人が異議を唱えるでしょうか。

誰かがVB6を覚えていますか？ VB6 DataGridは、すぐに使用できるEdit、Delete、およびAddNewをサポートしていました。 追加は、リストの最後に自動的に追加される空白行として使用可能でした。 行を完成させると、別の空白の行が表示されます。

ほとんどの開発者がこの機能をデフォルトでオフにすることを好む場合でも、DataGridにはデータ入力をサポートするオプションが必要です。

VB6アプリをUWPに移植する際には、追加/編集/削除をサポートする独自のデータグリッドを作成する必要がありました。

ここで貢献している人のほとんどはWPF / Xamlの人々のようです。これは、xamlの人ではない人から2セントの価値があります。

私は自分のソフトウェアでDataGridコントロールをよく使用しています。 編集は場所が重要です！ 私の願い/問題点のいくつかは次のとおりです。

1. 編集モードでコンテキストメニューをカスタマイズする機能。
2. 列の自動サイズ設定時のパフォーマンスと制御が向上します。 必要に応じてユーザーがサイズを制御できるようにしたいのですが、ほとんどの場合、そうする必要はありません。 列のサイズが絶えず変化することは望ましくありませんが、100万行分のデータを測定することなく、何らかの形でデータに基づいて列のサイズを変更する必要があります。
3. 編集するとき、編集を終了せずに、編集中のデータに対して（またはそれを使用して）何かを行う別のコントロール/ボタンをクリックできるようにしたいと思います。 （＃1が実装されている場合、これはそれほど必要ではありませんが、それでも有用です。）
4. DataErrorイベントを使用して例外が処理される現在の方法は大まかなものです。 （申し訳ありませんが、これについて具体的に説明するのに苦労していますが、過去に何度か痛みを引き起こしたことはわかっています。）
5. 組み込みの自動スクロール機能があれば便利です： http ：
6. データが「ダーティ」であることを示す「透かし」を表示する機能（DataGridViewのその他の便利な拡張機能については、 BetterGridを参照してください。
7. 必要な「キー」セルが空白のままの場合に（検証エラーなしで）行を破棄する機能。
8. ユーザーが追加した行の画像を（赤いXの代わりに）表示しない組み込み機能。 参照： https ：
9. チェックボックス列が変更されたときにすぐにコミットできるようにします： //stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

アルファ版はいつリリースされる予定ですか？ 寄付は受け付けますか？ 古いデータグリッドを捨てようとしていて、これ、特に仮想化機能を本当に楽しみにしています。

このスレッドに非常に遅い入力を入れて申し訳ありませんが、私にとっては「新しい」です;）
_コントロールがどのように動作するかについてもう少し調べた後に編集_

クラウドドライブ用のインターフェイスのようなエクスプローラーを作成するためにDataGridを使用して作業したところ、タップされる行とセルの決定は、「あるべき」よりも少し複雑になる可能性があることがわかりました（IMHO）

私のアプリのデザインでは、行はファイルまたはフォルダー（DriveItems）を表します。 詳細ビューには、アイテムの詳細が表示されます。

フォルダアイテムをクリックする機能を作成し、インターフェイスをジャンプしてそれらのアイテムのリストを作成し、ドライブ全体をナビゲートできるようにしたかったのです。

たとえば、アイテムの「親」列のエントリ（ここでは/drive/root:/Documents/Vital%20Documentsをタップすると、インターフェイスはそのフォルダにリセットされ、そこにファイルが一覧表示されます。

セルのクリックされたイベントを取得することはできますが、そのイベントには、タップされたセルを判別するためのハンドラーのコンテキストがないようです（行、はい、ただし列ではありません）。現在、コントロールを使用すると、セルタップ動作と自動的に開く詳細動作の両方を実行できます（これを可能にする「ハック」と呼ばれるものを調査していますが、設計者がコントロールの通常の機能をオーバーライドし始めると、特に注意する必要があります。文書化されている動作ではなく、コントロールの動作の変更によって設計が破損するリスクがあります。

とはいえ、DataGridは、現在DriveItemをCurrentItemとして返すイベントに、クリックされたDataGridColumnオブジェクト全体となるCurrentColumnも含める必要があるため、私のシナリオをサポートしているようです。列名を抽出することが可能です。 イベントから調査できるCurrentColumnオブジェクトがあることに気付いたので、イベント引数としてはもっと良いと思いますが、これは機能するはずです。

また、詳細の動作をより厳密に制御するには、行のどこかをクリックするたびに拡張するのではなく、特定の1つの列をクリックするだけで詳細が自動拡張される場合があります。

DataGridColumnオブジェクトの基本クラスにExpandDetailsプロパティを含めることができます。このプロパティは、各列に対してデフォルトでtrueに設定できます。つまり、特定の列をクリックすると、行が展開されます。 プロパティがfalseである他の人はそうではありません。

たとえば、私のデザインでは、最初の列はファイルやフォルダ、画像や写真、音声などのアイテムタイプです。自動拡張動作を引き起こす唯一の列になるように、その列を設定することを想像するかもしれません。次に、[パス]列をクリックすると、上記で説明した「そのパスのリストを取得する」動作が発生する可能性があります。

並べ替えに関しては、設計者がマルチレベルの並べ替えを取得できるように十分な制御を実装することが論理的に重要であるように思われます。 現在のコントロールがイベントとコールバックをフック/オーバーライドすることでこれをどのようにサポートするかを判断するための調査は行っていませんが、簡単には見えません。

最後に、あなたがこれをよく知っていることは知っていますが、（私がより多くの機能を求めているとしても）、ユーザーがDataGridの上に自分で実装できる複雑な動作の束を追加しようとしないでください。 これらの中には、DataGridに実装しないものがあり、フィルターや並べ替えなどを外部に保存する必要があります。また、このコントロールをExcelのクローンにすることも避けます。

-ありがとう、素晴らしい仕事です！
-e

スティッキーグループ：大きなグループでデータセットを参照する場合、どのグループ（またはグループ、つまりブレッドクラム）が表示されているかについてのコンテキストが必要です。 これは、グループ化されたリストビュー、データグリッド、ツリービューなど、すべての階層的なリストベースのビューに不可欠なユーザビリティ機能のようです。

新しいWinUIItemsRepeaterコントロールの上に新しいDataGridコントロールを構築します。 そして、そのコントロールはそのItemsSourceをオブジェクトとして公開します。
Object ItemsSource { get; set; };

@RBrid約1年後に戻ってきます。 ItemsRepeaterには、オブジェクトItemsSourceがありますが、仮想化されたデータソースの操作に必要な次のインターフェイスのサポートが実際には組み込まれていないことに気付きました。

• ISupportIncrementalLoading
• IItemsRangeInfo
• ISelectionInfo

-C ++からDatagridを使用できるように、MVPを取得するのはどうでしょうか。