Lebih banyak mode tampilan. Lihatlah File Explorer dan tampilan Ikonnya. DataGrid harus dapat menampilkan ikon/item dalam kisi dengan pengelompokan, serta baris dan kolom tajuk.

Saya tahu ini mungkin tidak mungkin, atau di luar jangkauan - tetapi ini adalah aspek dari WinUI vs Win32 yang tidak semudah 1:1 - dan versi modern dari File Explorer, atau Dialog File Umum - mungkin perlu dari kontrol seperti itu. Ini bisa berupa kontrol itu, bukan kontrol kustom internal.

Daftar keinginan saya: bagi saya, datagrid yang baik mencakup semua fitur berikut secara default. Saya meminjam beberapa tangkapan layar dari dunia html.

Filter seluruh halaman dengan mudah dengan jumlah baris pilihan.

Pilih / Batal Pilih Kolom Terlihat , Penyortiran Kolom , Salin , Cetak

Ekspor data ke format tertentu.

Pengurutan Ulang Kolom dengan menyeret kolom.

Pemfilteran Kolom

Memperbaiki Header - tempat header tetap di atas bahkan saat menggulir

Detail baris dengan template XAML untuk detailnya.

Pengelompokan Baris

Tarik & Lepas Urutan Baris

Fitur-fitur di atas menurut saya harus standar di semua datagrid.

Jika Anda ingin membuat datagrid menonjol di dunia html maka saya juga akan menyertakan yang berikut ini. Saya menemukan diri saya berkali-kali melihat datagrid dan kemudian memilih tampilan daftar karena datagrid tidak memiliki fitur ini.

Geser ke samping baris untuk menyertakan fitur seperti edit, hapus, tandai, dll.

Fitur-fitur di atas terutama menangani "presentasi data", apa yang masih kurang dari WinUI adalah apa yang saya yakini harus menjadi fitur (kontrol) WinUI asli seperti Microsoft Pivot Control. untuk melengkapi datagrid.

MS sudah memiliki kode sumber untuk ini dan itu adalah kontrol yang sangat mengagumkan di masa lalu.

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

Sekarang Anda membahas presentasi dan visualisasi data yang harus minimum untuk membedakan WinUI dari semua fitur dasar di luar sana.

Yang terpenting itu benar-benar menampilkan kekuatan "aplikasi asli" yang harus menyertakan animasi yang luar biasa dan kontrol yang menarik secara visual yang kuat dan terlihat sangat keren.

Saya dapat mengambil satu langkah lebih jauh dan mengatakan setelah fitur di atas (visualisasi) kita dapat memasukkan animasi 2D/3D yang menciptakan konsep kedalaman dalam data dan akan membawa kita ke stratosfer yang berbeda, tapi saya rasa itu untuk hari lain; ))

Titik awal yang baik adalah melihat mitra Anda Telerik dengan RadDataGrid (UWP Open Source) mereka. Dengan salah satu klien saya, saya menggunakannya dan itu benar-benar berfungsi dengan baik. Ini sangat cepat dan serbaguna. Satu-satunya hal yang sulit adalah kode mereka, tidak ada cara untuk memodifikasi apa pun dari mesin mereka tanpa pemahaman arsitektur yang baik.

Saya berharap DataGrid baru memiliki performa yang sama seperti Telerik.

Saya sangat senang melihat tim WinUI sedang mempertimbangkan kontrol DataGrid.

Peningkatan paling substansial yang ingin saya lihat dari kontrol baru untuk menggantikan Toolkit DataGrid:

• Kemampuan untuk mengambil DataGridRow dengan indeks
• Acara khusus untuk DataGridRows itu sendiri. Misalnya, DoubleTapped dan RightTapped.
• Pengguliran halus
• Validasi input untuk penggantian nama sel
• DataGridColumn yang dirancang khusus untuk ikon baris
• Kustomisasi warna yang mudah, dll.

Opsi untuk memiliki tombol edit yang menempatkan ikon yang dapat diseret di sebelah setiap baris untuk memindahkan urutan akan menjadi fitur yang berguna. Akan sangat bagus juga untuk melihat beberapa bayangan di belakang baris diangkat dan dipindahkan (karena salah satu atribut utama Lancar adalah kedalaman). Panah atas dan bawah kecil mungkin bagus di sebelah ikon seret untuk memindahkan baris lebih mudah dengan input mouse. Jika sebuah baris dipindahkan menggunakan panah, animasi geser yang halus akan menjadi sentuhan yang bagus. Dengan input sentuh, opsi untuk menahan satu baris dan hanya memindahkannya tanpa perlu menekan tombol edit mungkin juga berfungsi dengan baik. Saya tidak yakin apakah ini sudah didukung, tetapi saya bisa melihat kotak centang pilihan seperti di File Explorer memperjelas pemilihan baris dukungan DataGrids dan hanya meningkatkan UX keseluruhan. Aplikasi pengingat iOS berisi beberapa ide ini (contoh gambar di bawah). Aplikasi iOS Stocks juga memiliki kesepakatan serupa dengan baris yang dapat dipindahkan. Sebagian besar ide ini juga cocok untuk kolom.

@NoahFeller Jenis tindakan itu lebih masuk akal untuk Tampilan Daftar. Dengan tampilan Grid Anda tidak mengatur ulang urutan, harus ada opsi pengurutan tetapi pengguna tidak menyeret semuanya.

*Sunting
Setelah memikirkannya sedikit lagi, saya melihat bagaimana opsi seperti itu dapat berguna. Namun, saya pasti tidak berpikir ini harus menjadi perilaku default.

@NoahFeller Jenis tindakan itu lebih masuk akal untuk Tampilan Daftar. Dengan tampilan Grid Anda tidak mengatur ulang urutan, harus ada opsi pengurutan tetapi pengguna tidak menyeret semuanya.

*Sunting
Setelah memikirkannya sedikit lagi, saya melihat bagaimana opsi seperti itu dapat berguna. Namun, saya pasti tidak berpikir ini harus menjadi perilaku default.

Ya, Anda mungkin benar @yaichenbaum. Saya membayangkan saran-saran itu sebagai kemampuan untuk melakukan pengurutan khusus dan saya pikir menyeret mungkin berguna untuk itu. Jadi saya setuju, jelas bukan default tetapi mungkin cukup berguna sebagai opsi. Terima kasih untuk umpan baliknya!

Kesederhanaan WPF yang dapat didata ke fungsi datagrid. Saya sebenarnya telah berjuang selama seminggu terakhir ini mencoba membuat datagrid UWP berfungsi seperti yang saya miliki di WPF di mana saya bisa mengikat Datagrid ke Dataview, lalu mengisi Dataview dari SQL dengan datatable.defaultview. Grid kemudian hanya menampilkan tabel data. Itu sangat sederhana untuk dilakukan, dan UWP sejauh ini telah membuatnya menjadi sangat rumit.

buat lintas platform

Saya ingin meminta mode pemilihan sel tunggal, gaya excel.
Tujuan akhir menjadi mode dengan perilaku yang tepat sebagai WinForms DataGridView.

Memiliki bermacam-macam opsi virtualisasi yang dapat mendukung berbagai kasus penggunaan (Dari opsi virtualisasi pengguliran biasa seperti daur ulang hingga konsep lain seperti paging data)
Seringkali (Dalam kontrol desktop serupa yang mendukung ini) beberapa opsi ini mulai gagal saat digunakan dengan templat khusus untuk kolom dengan data unik. Semakin banyak yang dapat mereka dukung dalam kasus tersebut, semakin baik.

Jika memungkinkan, proposal Paging Control #268, harus disinkronkan, dan semua kait yang diperlukan ditambahkan ke kontrol DataGrid.

Ini adalah kabar baik! Saya telah menunggu sesuatu yang resmi di bagian depan DataGrid untuk sementara waktu sejak itu muncul di toolkit komunitas. Ini benar-benar kontrol terakhir yang hilang dari WinUI 3.0 yang tidak memiliki alternatif yang baik untuk toolkit komunitas.

Pertama, tolong, jangan menemukan kembali roda. Sebagai permulaan, implementasi WPF dari DataGrid (saya tahu Anda tidak dapat menggunakan kode tersebut tetapi harap gunakan 100% API) -- BUKAN yang Silverlight. WPF DataGrid jauh lebih lengkap fitur dan memiliki lebih sedikit bug dalam pengujian saya.

Dalam menggunakan toolkit komunitas DataGrid, saya juga meminta tambahan API berikut yang muncul untuk berbagai kasus penggunaan. Diskusi di sini :

• RowPressed : Seperti dibahas di atas. Menunjukkan baris telah ditekan sehingga pemrosesan lebih lanjut atau menu konteks dapat terjadi.
• RowDoublePressed : Sama seperti RowPressed, hanya versi klik dua kali.
• ColumnHeaderPressed : Terjadi setiap kali header kolom ditekan. Harus diprioritaskan daripada pembaruan internal arah apa pun. Ini akan memungkinkan menu pemfilteran khusus atau opsi klik kanan untuk mengaktifkan/menonaktifkan kolom.
• ColumnHeaderDoublePressed : Sama seperti ColumnHeaderPressed, hanya versi double klik.
• ColumnHeaderWidthChanged : Terjadi setiap kali pengguna mengubah ukuran lebar header kolom. Ini akan memungkinkan untuk menyimpan informasi ini dengan cara yang bersih. Ini biasanya diperlukan saat memulihkan status UI.

Saya juga terus memiliki banyak masalah dengan komunitas yang mengambil DataGrid mengatur ulang posisi gulir ke atas setelah ItemsSource diubah. Ini perlu diperbaiki sehingga offset dipertahankan seperti di WPF; namun, kita juga harus dapat mengontrol ini, itulah sebabnya saya juga menyarankan API berikut:

• FirstRowInView() : Mengembalikan baris pertama yang terlihat di DataGrid yang digunakan untuk memulihkan status.
• VerticalOffset : Dapatkan/Setel lagi untuk mengembalikan status bilah gulir
• HorizontalOffset : Dapatkan/Atur untuk memulihkan status bilah gulir

@RBrid Juga membantu dengan beberapa analisis di sini :

Acara baru yang disarankan, dan beberapa peningkatan pada acara yang sudah ada sebelumnya:

| Acara | Komentar |
| :--- | :--- |
| ContextRequestedForColumnHeader | Untuk mendukung menampilkan menu konteks (atau flyout lainnya) saat header kolom diklik kanan. Sama seperti Windows.UI.Xaml.UIElement.ContextRequested tetapi untuk header kolom, bukan seluruh DataGrid. |
| ContextCanceledForColumnHeader | Sama seperti Windows.UI.Xaml.UIElement.ContextCanceled tetapi untuk tajuk kolom alih-alih seluruh DataGrid. |
| ContextRequestedForRow | Untuk mendukung menampilkan menu konteks (atau flyout lainnya) ketika sebuah baris diklik kanan. Sama seperti Windows.UI.Xaml.UIElement.ContextRequested tetapi untuk baris, bukan seluruh DataGrid. |
| ContextCanceledForRow | Sama seperti Windows.UI.Xaml.UIElement.ContextCanceled tetapi untuk baris, bukan seluruh DataGrid. |
| RowTapped | Perhatikan juga kasus penyadapan baris yang sudah dipilih. |
| RowDoubleTapped | Sama seperti Windows.UI.Xaml.UIElement.DoubleTapped tetapi untuk baris, bukan seluruh DataGrid. |
| RowRightTapped | Sama seperti Windows.UI.Xaml.UIElement.RightTapped tetapi untuk baris, bukan seluruh DataGrid. Lihat juga ContextRequestedForRow . |
| PointerPressedInRow | Sama seperti Windows.UI.Xaml.UIElement.PointerPressed tetapi untuk baris, bukan seluruh DataGrid. |
| PointerReleasedInRow | Sama seperti Windows.UI.Xaml.UIElement.PointerReleased tetapi untuk baris, bukan seluruh DataGrid. |
| PointerMovedInRow | Sama seperti Windows.UI.Xaml.UIElement.PointerMoved tetapi untuk baris, bukan seluruh DataGrid. Mungkin PointerMovedInRow hanya akan terpicu saat pointer ditangkap. |
| ColumnHeaderTapped | Perhatikan juga kasus penyadapan header kolom yang sudah dipilih. |
| ColumnHeaderDoubleTapped | Sama seperti Windows.UI.Xaml.UIElement.DoubleTapped tetapi untuk header kolom, bukan seluruh DataGrid. |
| ColumnHeaderRightTapped | Sama seperti Windows.UI.Xaml.UIElement.RightTapped tetapi untuk header kolom, bukan seluruh DataGrid. Lihat juga ContextRequestedForColumnHeader . |
| ColumnHeaderWidthChanged | Atau bisa disebut ColumnHeaderResized . Dalam argumen acara, sertakan properti boolean yang menentukan apakah itu diubah oleh pengguna atau diubah secara terprogram. Jelas argumen acara juga harus menentukan tajuk kolom mana yang diubah ukurannya/diubah. |
| SortOrderChanged | Harus dipicu ketika daftar tajuk kolom yang dipilih berubah. Juga dipicu ketika salah satu kolom yang dipilih dialihkan antara urutan menaik versus menurun. Dalam argumen acara, sertakan properti boolean yang menentukan apakah urutan pengurutan diubah oleh pengguna atau diubah secara terprogram. Lihat juga acara yang sudah ada sebelumnya Sorting . Saya pikir acara baru SortOrderChanged akan dipicu setelah acara Sorting dipicu, jika penyortiran tidak dibatalkan. |
| Sorting | Sudah ada tetapi pertimbangkan untuk menambahkan properti boolean yang dapat diatur dalam argumen peristiwa yang memungkinkan permintaan penyortiran dibatalkan. Misalnya, penyortiran mungkin tidak valid atau tidak dapat dilakukan dan perlu dibatalkan. Juga tambahkan properti boolean untuk menentukan apakah penyortiran diminta oleh pengguna atau secara terprogram. |
| ColumnSortDirectionChanged | Acara ini dapat dibuat tetapi bisa jadi tidak diperlukan jika acara SortOrderChanged disebutkan di atas dibuat, jika SortOrderChanged juga dipicu saat arah pengurutan berubah. |
| ColumnDisplayIndexChanged | Sudah ada tetapi harap pertimbangkan untuk menambahkan properti boolean (dalam argumen acara) yang menentukan apakah itu diubah oleh pengguna atau diubah secara terprogram. Juga, harap dokumentasikan mengapa perlu mengadakan kedua acara ColumnDisplayIndexChanged dan ColumnReordered . Atau, hilangkan salah satu dari peristiwa ini. |
| ColumnReordered | Sudah ada tetapi harap pertimbangkan untuk menambahkan properti boolean yang menentukan apakah itu diubah oleh pengguna atau diubah secara terprogram. |
| SelectionChanged | Sudah ada tetapi harap pertimbangkan untuk menambahkan properti boolean (dalam argumen acara) yang menentukan apakah itu diubah oleh pengguna atau diubah secara terprogram. |
| CopyingRowClipboardContent | Sudah ada, tetapi harap pertimbangkan untuk menambahkan properti boolean ke argumen peristiwa yang menentukan apakah operasi dipotong alih-alih menyalin. Atau buat acara terpisah untuk dipotong. |
| CuttingRowClipboardContent | Tidak ada. Pertimbangkan untuk membuat peristiwa yang dipicu saat pengguna mencoba memotong baris (melalui hotkey control-X, menu konteks, atau lainnya). Atau buat properti boolean yang disebutkan di atas yang memungkinkan CopyingRowClipboardContent dipicu untuk operasi salin dan potong |
| PastingRowClipboardContent | Tidak ada. Pertimbangkan untuk membuat peristiwa yang dipicu saat pengguna mencoba menempel (melalui hotkey control-V, menu konteks, atau lainnya). |

Saya pikir fitur yang paling penting bagi saya adalah kemampuan untuk menangani satu juta baris atau lebih dengan mudah, tanpa harus memuat jutaan baris ke dalam memori. Antarmuka ISupportIncrementalLoading tidak cukup baik untuk ini, karena bilah gulir hanya mencerminkan berapa banyak baris yang telah Anda muat sejauh ini (bukan jumlah total), dan untuk mencapai 1 juta baris, Anda harus terus menggulir sampai akhir dan lagi dan memuat lebih banyak dan lebih banyak data, dan berharap saya tidak akan kehabisan memori. Tetapi jika saya tahu saya memiliki 1 juta catatan data, izinkan saya memberi tahu datagrid itu, dan jika saya menggulir cepat atau melompat ke akhir, saya dapat diminta untuk memberikan beberapa baris terakhir saja.
Pikirkan menggulir daftar baris dalam database yang akan saya tarik secara dinamis.

Saya pikir fitur yang paling penting bagi saya adalah kemampuan untuk menangani satu juta baris atau lebih dengan mudah, tanpa harus memuat jutaan baris ke dalam memori. Antarmuka ISupportIncrementalLoading tidak cukup baik untuk ini, karena bilah gulir hanya mencerminkan berapa banyak baris yang telah Anda muat sejauh ini (bukan jumlah total), dan untuk mencapai 1 juta baris, Anda harus terus menggulir sampai akhir dan lagi dan memuat lebih banyak dan lebih banyak data, dan berharap saya tidak akan kehabisan memori. Tetapi jika saya tahu saya memiliki 1 juta catatan data, izinkan saya memberi tahu datagrid itu, dan jika saya menggulir cepat atau melompat ke akhir, saya dapat diminta untuk memberikan beberapa baris terakhir saja.
Pikirkan menggulir daftar baris dalam database yang akan saya tarik secara dinamis.

Ini.

'Modern' berarti ringan dan cepat, dan aplikasi perusahaan biasanya tentang memilah-milah banyak data internal untuk menemukan dan menjelajahi catatan yang sesuai. Paging, pengurutan, pemuatan inkremental asinkron, pengguliran tanpa akhir - semua ini adalah pokok aplikasi desktop yang memanfaatkan kisi data.

MS harus menghasilkan aplikasi sampel yang menyoroti fitur-fitur ini di kisi baru dan mengumpulkan umpan balik dari pengembang perusahaan dari waktu ke waktu untuk menjadikan pengalaman ini lebih baik. Apakah itu lari dari kumpulan data besar seperti Importir Seluruh Dunia untuk menunjukkan keefektifannya.

@dotMorten

Saya pikir fitur yang paling penting bagi saya adalah kemampuan untuk menangani satu juta baris atau lebih dengan mudah, tanpa harus memuat jutaan baris ke dalam memori.

Saya berharap untuk itu juga. Untuk membantu mendukung sejuta baris (dan maksud saya bantuan, belum tentu solusi lengkap), saya menyarankan agar DataGrid membuat teknik pengikatan data saat ini opsional. Saya percaya saat ini pengikatan data adalah wajib (kecuali pengetahuan saya tidak lagi mutakhir dengan versi DataGrid terbaru). DataGrid seharusnya tidak memerlukan penggunaan Windows.UI.Xaml.Data.Binding sebagai satu-satunya cara yang didukung untuk mengambil nilai untuk setiap sel/kolom di setiap baris yang terlihat.

Saya menyarankan agar DataGrid mengizinkan aplikasi memberi DataGrid delegasi atau instance antarmuka yang akan dipanggil DataGrid kapan pun DataGrid perlu mengambil nilai sel/kolom dalam satu baris (sebagai alternatif, delegasi atau antarmuka ini dapat mengambil seluruh baris -- semua nilai kolom untuk baris tertentu).

Idealnya (jika memungkinkan), DataGrid akan mengizinkan delegasi atau antarmuka ini untuk beroperasi secara asinkron . Misalnya, delegasi atau antarmuka mungkin mengembalikan Task atau IAsyncOperation<TResult> alih-alih segera mengembalikan nilai yang diminta.

Atau, dukungan asinkron juga dimungkinkan tanpa Task dan IAsyncOperation<TResult> , jika DataGrid beroperasi mirip dengan prosedur berikut:

1. DataGrid memutuskan bahwa ia perlu mengambil nilai sel/kolom 5 di baris ID 50001. Atau DataGrid memutuskan untuk mengambil semua nilai kolom untuk ID baris 50001.
2. DataGrid memanggil delegasi atau instance antarmuka atau pengendali peristiwa yang memberi tahu aplikasi bahwa DataGrid telah meminta pemuatan nilai data dari kolom/baris atau seluruh baris yang ditentukan.
3. Aplikasi mengambil data baris yang diminta secara asinkron. Misalnya, itu bisa secara tidak sinkron melakukan kueri database SQL.
4. Aplikasi selesai mengambil data baris yang diminta. Aplikasi memanggil metode di DataGrid yang memberikan data baris ke DataGrid.
5. DataGrid menampilkan data baris, atau melakukan apa pun yang perlu dilakukan dengan data tersebut.

Pertama, woy!! Terima kasih banyak untuk semua orang yang menyumbangkan ide-ide mereka. Saya memiliki beberapa tanggapan spesifik di bawah ini, tetapi secara keseluruhan saya ingin mengatakan bahwa saya menyimpan banyak komentar ini dan sangat senang mendengar bagaimana kita dapat membangun DataGrid modern yang mengagumkan. Tetap datang!

@Pinox terima kasih banyak atas tanggapan terperinci dan tangkapan

@verelpode , @robloo , @duke7553 YA untuk acara khusus DataGrid! Terima kasih semua atas detail yang Anda masukkan ke dalam ini. Saat kami mendesain untuk sentuhan pertama dan untuk berbagai masukan, acara seperti ini pasti harus diterapkan!

@dotMorten , @jkewley , @verelpode Performa jelas merupakan salah satu motivasi utama untuk proyek ini dan salah satu peningkatan utama yang ingin kami terapkan, melalui kisah virtualisasi data baru dan penggunaan kontrol modern seperti ItemsRepeater. Akan membuat Anda semua diperbarui setelah kami memiliki lebih spesifik - tetapi sekali lagi terima kasih atas detail yang Anda sarankan.

@Laz3rPanth3r , @robloo , @keeganatorr Kami mendengar Anda keras dan jelas tentang menyukai DataGrids milik WPF dan kerangka kerja UI lainnya - kami pasti mempertimbangkan ini dalam penyegaran ini!

Terima kasih atas kerja bagus di DataGrid dan permintaan umpan balik! Berikut adalah beberapa peningkatan yang disarankan.

Perlu lebih banyak subkelas DataGridColumn

Subkelas/implementasi DataGridColumn ini tidak mencukupi. Saya sarankan membuat subclass baru berikut dari DataGridColumn :

| Subkelas yang Diusulkan | Deskripsi |
| :--- | :--- |
| DataGridIconColumn | Persyaratan umum adalah menampilkan ikon di setiap baris daftar, oleh karena itu saya sarankan membuat subkelas DataGridColumn bernama DataGridIconColumn yang mengetik nilai sel yang diambil ke Windows.UI.Xaml.Controls.IconSource dan merender IconSource instans (contoh IconSource yang berbeda dirender di setiap sel). |
| DataGridImageColumn | DataGridImageColumn harus beroperasi sama seperti yang diusulkan DataGridIconColumn kecuali bahwa itu harus membuat Windows.UI.Xaml.Media.ImageSource bukan Windows.UI.Xaml.Controls.IconSource . |
| DataGridDateTimeColumn | Menampilkan tanggal dan/atau waktu, tergantung pada pengaturan. Mengetik nilai sel menjadi System.DateTimeOffset atau System.DateTime (keduanya didukung) dan mengonversinya menjadi teks untuk ditampilkan di sel. Konversi ke teks harus dikontrol dengan memformat pengaturan/properti di kelas DataGridDateTimeColumn . Jelas penyortiran berdasarkan tanggal/waktu juga harus didukung. |
| DataGridTimeSpanColumn | Mengetik nilai sel menjadi System.TimeSpan dan mengonversinya menjadi teks untuk ditampilkan di sel. Konversi ke teks harus dikontrol dengan memformat pengaturan/properti di kelas DataGridTimeSpanColumn . Jelas penyortiran juga harus didukung, dan itu harus mengurutkan instance TimeSpan bukan teks yang ditampilkan. |
| DataGridDataSizeColumn | Mengetik nilai sel menjadi System.Int64 , UInt64 , Int32 , atau UInt32 (semua didukung) dan mengonversinya menjadi ukuran dalam byte (sebagai teks ) yang akan ditampilkan. Misalnya, 1572864 akan ditampilkan sebagai "1,5 MB" karena 1572864/1024/1024 = 1,5. Konversi ke teks harus dikontrol oleh pengaturan/properti di kelas DataGridDataSizeColumn . Penyortiran harus dilakukan menggunakan nilai integer asli, bukan teks yang ditampilkan. |
| DataGridCustomColumn | Ini harus beroperasi mirip dengan DataGridTemplateColumn sudah ada sebelumnya kecuali tanpa Windows.UI.Xaml.DataTemplate . Itu harus memanggil delegasi/panggilan balik atau acara untuk menghasilkan dan/atau memperbarui subpohon elemen GUI yang ditampilkan. |
| DataGridTextColumn | Sudah ada, tetapi harap pertimbangkan untuk menambahkan properti atau peristiwa yang memungkinkan aplikasi mengganti konversi objek-ke-teks dan fungsi perbandingan untuk pengurutan. Saya menjelaskan ini secara lebih rinci nanti dalam pesan saya. |

DataGridCustomColumn akan menjadi seperti ini:

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
}

Ketika event DataGridCustomColumn.DisplayingCell dipicu, event handler harus membuat atau memperbarui subtree UIElement untuk menampilkan DataGridDisplayingCellEventArgs.CellValue , dan mengatur properti DataGridDisplayingCellEventArgs.CellUIElement ke itu UIElement subtree, dan kemudian DataGrid akan menampilkannya.

Saat berikutnya DataGrid memicu peristiwa ini, DataGrid harus menyetel properti DataGridDisplayingCellEventArgs.CellUIElement ke instance UIElement yang sebelumnya dibuat oleh pengendali peristiwa, untuk memungkinkan pengendali peristiwa menggunakan kembali/mendaur ulang dan memperbarui subpohon UIElement (berpotensi dengan nilai berbeda di DataGridDisplayingCellEventArgs.CellValue ). Pengendali event diperbolehkan untuk baik recycle sama UIElement subtree ATAU mengatur properti DataGridDisplayingCellEventArgs.CellUIElement ke yang baru dibuat UIElement subtree.

Pertimbangkan juga kemungkinan membuat acara DisplayingCell secara langsung di kelas dasar DataGridColumn , alih-alih membuat subkelas DataGridCustomColumn . Jadi acara DataGridColumn.DisplayingCell dapat memungkinkan penyesuaian atau penggantian UIElement dihasilkan untuk setiap subkelas DataGridColumn .

Dalam DataGridTextColumn sudah ada sebelumnya, saat ini nilai sel/objek dikonversi menjadi teks untuk ditampilkan dengan menjalankan System.Object.ToString . Harap pertimbangkan untuk membuat delegasi/panggilan balik atau acara yang memungkinkan aplikasi mengganti konversi nilai-ke-teks ini. Harap pertimbangkan juga properti yang memungkinkan aplikasi menentukan instance System.Collections.IComparer untuk mengganti perilaku penyortiran.

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

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

Atau, alih-alih membuat properti Comparer di DataGridTextColumn , pertimbangkan kemungkinan membuat properti Comparer langsung di kelas dasar DataGridColumn , untuk mengizinkan apps untuk mengontrol perilaku penyortiran untuk semua subkelas DataGridColumn .

Demikian juga properti CellValueToToStringConverter juga dapat dibuat di kelas dasar DataGridColumn karena akan berguna jika memiliki kemampuan untuk mengonversi nilai sel apa pun menjadi teks terlepas dari subkelas mana dari DataGridColumn digunakan. Misalnya, saat menyalin baris ke clipboard, setiap nilai sel dapat dikonversi menjadi teks. (Baik format teks dan non-teks dapat ditempatkan secara bersamaan di papan klip -- aplikasi biasanya melakukan ini untuk meningkatkan kompatibilitas dengan aplikasi lain.)

Mengurutkan ulang ketika DataGridIconColumn atau DataGridImageColumn dipilih: Jelas DataGrid tidak dapat mengurutkan ikon atau gambar, oleh karena itu ia dapat menggunakan salah satu dari solusi ini:

• Cukup larang pengguna akhir untuk memilih (mengurutkan berdasarkan) tajuk kolom dengan tipe DataGridIconColumn atau DataGridImageColumn .
• Buat properti AlternativeText di kelas IconSource . Saat DataGridIconColumn mengurutkan baris, atau saat mengubah sel menjadi teks untuk clipboard/salin, itu akan menggunakan properti AlternativeText .
• Buat properti Comparer diatur (dengan tipe System.Collections.IComparer ) baik dalam DataGridColumn atau DataGridIconColumn .

Akses ke baris/item yang dipilih

Harap pertimbangkan untuk meningkatkan fungsionalitas untuk mendapatkan dan mengatur baris/item yang dipilih, karena fungsionalitas saat ini tidak mencukupi. Saat ini properti ini ada:

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

Saya menemukan bahwa terkadang saya memerlukan akses ke instance DataGridRow dari baris yang dipilih, jadi saya berharap properti berikut dapat ditambahkan ke DataGrid:

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

Atau, jika hal di atas terlalu sulit untuk diterapkan, variasi read-only berikut ini kurang kuat tetapi tetap membantu:

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

Jika instance DataGridRow dapat didaur ulang , maka dokumentasi untuk properti di atas harus memperingatkan bahwa info yang dikembalikan hanya valid untuk sementara, sehingga harus segera dibaca/digunakan dan tidak disimpan untuk waktu yang lebih lama.

Juga, properti SelectedIndex sudah ada sebelumnya memberikan akses ke satu indeks yang dipilih, tetapi bagaimana dengan mendapatkan akses ke semua item yang dipilih? Oleh karena itu saya sarankan membuat properti SelectedIndexes :

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

Secara pribadi saya menemukan nama "SelectedIndex" membingungkan karena DataGrid sering digunakan bersama dengan database dan istilah "indeks" memiliki arti yang sama sekali berbeda dalam database, oleh karena itu saya sarankan mengganti nama properti sebagai berikut, tetapi saya berharap saran penamaan saya akan ditolak:

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

Saya juga menginginkan kemampuan untuk menggulir DataGridRow dan/atau DataGridColumn yang ditentukan ke tampilan. Saat ini metode ini ada:

public void ScrollIntoView(object item, DataGridColumn column);

Saya sarankan mengganti metode ScrollIntoView sudah ada sebelumnya dengan 2 metode ini:

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

Dapatkan dan atur urutan-urutan dalam satu pukulan

Saat aplikasi dibuka dan ditutup, mereka membutuhkan kemampuan untuk menyimpan dan memulihkan konfigurasi DataGrid pengguna akhir, termasuk urutan pengurutan dan pengaturan lainnya. Urutkan urutan yang berarti daftar kolom yang dipilih oleh pengguna. Perhatikan ini adalah daftar, bukan satu kolom. Lebih dari satu kolom dapat dipilih secara bersamaan, artinya kolom utama untuk pengurutan, dan kolom sekunder untuk pengurutan, dan kolom tersier untuk pengurutan, dll.

Oleh karena itu properti berikut dapat dibuat di DataGrid, tetapi sebenarnya ini hanya ide pertama dan tidak ideal:

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

Di atas tidak ideal karena tidak mendukung penyimpanan dan pemulihan DataGridColumn.SortDirection dari setiap kolom dalam satu klik . Saya menyadari bahwa aplikasi dapat melakukannya dalam beberapa langkah:

1. Setel properti SortOrder diusulkan ke daftar kolom yang dipilih.
2. Tetapkan properti SortDirection dari setiap kolom yang dipilih (ulangi langkah ini untuk setiap kolom).

Itu masih bermasalah karena banyak hit, yang berarti menyebabkan beberapa resor DataGrid yang memakan waktu. Pengguna akhir dapat melihat dan mengalami penundaan yang signifikan dalam DataGrid yang berisi banyak baris, ketika DataGrid digunakan beberapa kali secara tidak perlu. Untuk menghilangkan masalah ini, saya menyarankan solusi berikut yang memungkinkan aplikasi memulihkan urutan pengurutan lengkap dalam satu pukulan dan menyebabkan tidak lebih dari satu resor.

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

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

Catatan Saya sengaja menulis IReadOnlyList<DataGridColumnAndDirection> bukan IList<DataGridColumnAndDirection> atas karena aplikasi seharusnya tidak dapat mengubah daftar yang dikembalikan oleh properti SortOrder . Alih-alih mengubah daftar, aplikasi harus menyetel properti SortOrder ke daftar yang akan disalin dan digunakan DataGrid untuk sepenuhnya mengganti seluruh daftar urutan pengurutan. Jadi itu akan beroperasi dalam satu pukulan dan menghindari beberapa resor mahal.

Ketika DataGrid.SortOrder disetel ke daftar baru, DataGrid juga akan menyetel properti DataGridColumn.SortDirection di setiap kolom dalam daftar SortOrder , tetapi tanpa menyebabkan banyak resor. Jadi DataGrid.SortOrder[i].SortDirection setara dengan DataGridColumn.SortDirection .

Dapatkan dan atur urutan kolom yang ditampilkan dalam satu pukulan

Saat aplikasi dibuka dan ditutup, mereka membutuhkan kemampuan untuk menyimpan dan memulihkan urutan kolom pengguna akhir, sebaiknya dalam satu klik. Saya tahu bahwa properti yang sudah ada sebelumnya DataGridColumn.DisplayIndex dapat disetel, oleh karena itu secara teoritis aplikasi dapat memulihkan konfigurasi pengguna akhir dengan mengulangi semua kolom di DataGrid.Columns dan mengatur DisplayIndex masing-masing, tetapi ini dapat menyebabkan bug. Misalnya, DisplayIndex mungkin gagal atau berperilaku tidak terduga saat aplikasi perlu menyetel sementara DisplayIndex dari satu kolom ke DisplayIndex sama dari kolom lain. Juga, jika tidak dilakukan dalam satu pukulan, maka itu dapat memicu beberapa penarikan ulang dan/atau penghitungan ulang yang mahal.

Oleh karena itu saya sarankan membuat properti ColumnDisplayOrder di DataGrid:

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

Sama seperti yang saya sebutkan sebelumnya untuk SortOrder , ColumnDisplayOrder sengaja IReadOnlyList<DataGridColumn> bukan IList<DataGridColumn> karena harus beroperasi dalam satu pukulan.
Ketika DataGrid.ColumnDisplayOrder diatur ke daftar baru, DataGrid akan memperbarui DataGridColumn.DisplayIndex dari setiap kolom agar sesuai.

Izinkan pengguna akhir untuk menyembunyikan/menampilkan kolom

Konsisten dengan properti yang sudah ada sebelumnya DataGridColumn.CanUserReorder dll, saya sarankan membuat properti CanUserChangeVisibility di DataGridColumn . Ketika DataGridColumn.CanUserChangeVisibility benar, pengguna akhir akan dapat menyebabkan perubahan pada properti DataGridColumn.Visibility .

Mendukung elemen GUI yang dihasilkan secara dinamis saat runtime

Izinkan GUI detail baris dibuat tanpa memerlukan penggunaan DataGrid.RowDetailsTemplate ( Windows.UI.Xaml.DataTemplate ). Untuk mencapai ini, beberapa pemikiran perlu dimasukkan ke dalam API, tetapi inilah ide pertama saya tentang cara melakukannya: Mungkin melakukannya melalui acara yang sudah ada sebelumnya DataGrid.LoadingRow dengan mengubah properti DataGridRowDetailsEventArgs.DetailsElement agar dapat diatur sehingga event handler dapat menghasilkan (atau memperbarui) UIElement dengan sendirinya dan memberikannya ke DataGrid dengan menyetel properti DetailsElement .

Alasan mengapa penggunaan wajib Windows.UI.Xaml.DataTemplate menjadi masalah: Meskipun template adalah fitur yang bagus, konsep template mengharapkan cuplikan/dokumen XAML yang tidak berubah yang telah dibuat sebelumnya yang ditulis oleh pengembang sebelumnya. Jadi, template menjadi masalah ketika aplikasi perlu menghasilkan GUI secara dinamis saat runtime. Jadi saya berharap alternatif yang disebutkan di atas untuk DataTemplate .

Seret dan lepas baris, ke dalam dan ke luar

Saya sarankan membuat kemampuan untuk secara opsional mengaktifkan drag-and-drop baris. DataGrid akan menerapkan drag tapi tidak drop. Saat penurunan terjadi, DataGrid akan memicu suatu peristiwa dan aplikasi merespons peristiwa tersebut untuk melakukan tindakan yang diinginkan saat baris dijatuhkan di luar DataGrid.

Juga kemampuan untuk secara opsional mengaktifkan drag-and-drop baris atau item/objek yang masuk. DataGrid akan menerima drag-and-drop yang masuk tetapi tidak mengimplementasikan drop. DataGrid akan memicu peristiwa saat baris/item/objek dijatuhkan, dan aplikasi merespons peristiwa tersebut untuk melakukan tindakan yang diinginkan saat baris dijatuhkan di dalam DataGrid.

Latar belakang sel individu

Kami memiliki permintaan fitur dari pelanggan yang ingin sel individual dirusak (dengan mengubah warna/kuas latar belakang sel) pada waktu tertentu (seperti saat aplikasi kami mendeteksi perubahan atau nilai penting atau nilai berbahaya yang melebihi batas aman, dll.).

Jadi saya dapat mengusulkan properti DataGridCell.Background (dari tipe Brush ), tetapi saya pikir cara melakukannya mungkin rusak karena DataGrid mendaur ulang instance DataGridCell , bukan? Jadi saya kira bahwa membunuh sel individu dengan menetapkan properti DataGridCell.Background akan menjadi solusi yang tidak dapat diandalkan.

Cara yang lebih baik mungkin melalui acara DataGridColumn.DisplayingCell yang saya usulkan dalam pesan saya sebelumnya. Penangan acara dapat menetapkan properti CellBackgroundBrush di DataGridDisplayingCellEventArgs .

Pengambilan data DataGrid yang bodoh (nilai sel)

Saya tahu "bodoh" terdengar sangat buruk, tetapi pada kenyataannya saya akan senang jika DataGrid dibuat bodoh di bidang pengambilan data (pengambilan nilai sel yang akan ditampilkan oleh DataGrid).

Saat ini DataGrid mencoba melakukan pengambilan data dengan cara otomatis yang nyaman melalui propertinya DataGrid.ItemsSource plus teknik pengikatan data (properti DataGridBoundColumn.Binding ), dan antarmuka seperti System.ComponentModel.INotifyPropertyChanged .

Ya pengikatan data adalah fitur yang nyaman, tetapi sebenarnya saya lebih suka DataGrid melakukan _less_ di departemen itu! Beberapa komponen Microsoft sebenarnya menyebabkan kesulitan besar bagi saya melalui perilaku mereka yang mencoba menjadi pintar tetapi akhirnya menjadi terlalu pintar . Secara keseluruhan saya benar-benar akan mengalami lebih sedikit kesulitan dan lebih sedikit pekerjaan jika komponen ini berhenti berusaha menjadi sangat pintar/otomatis/nyaman. Saat merancang perilaku otomatis, saya merasa perlu diingat bahwa otomatis terdengar hebat tetapi berpotensi menjadi bumerang.

_"Biarkan aku melakukannya sendiri."_
Terkadang solusi terbaik adalah dengan mengizinkan aplikasi melakukan tugas sendiri, alih-alih mencoba-dan-gagal melakukannya "secara otomatis" di dalam komponen seperti DataGrid. Saya berharap DataGrid mengizinkan saya untuk sepenuhnya melakukan pengambilan data sendiri, alih-alih mencoba mengambil data secara otomatis melalui properti DataGridBoundColumn.Binding dan DataGrid.ItemsSource .

Idealnya saya ingin menghilangkan persyaratan untuk menggunakan properti DataGrid.ItemsSource untuk memasok barang. @dotMorten menyebutkan satu juta baris. Saat ini DataGrid mewajibkan aplikasi untuk menyetel DataGrid.ItemsSource , tetapi tidak praktis untuk membuat objek daftar yang berisi satu juta item. Jadi saya berharap DataGrid akan berhenti menjadi pintar di departemen pengambilan data dan sebagai gantinya membiarkan saya sepenuhnya melakukan pengambilan data sendiri, tanpa menggunakan DataGridBoundColumn.Binding dan DataGrid.ItemsSource .

@anawishnoff menulis:

Performa jelas merupakan salah satu motivasi utama untuk proyek ini dan salah satu peningkatan utama yang ingin kami terapkan, melalui kisah virtualisasi data baru dan penggunaan kontrol modern seperti ItemsRepeater.

Saya melihat Anda mengatakan bahwa kisah virtualisasi data baru akan meningkatkan kinerja, dan itu kabar baik, tetapi apakah itu juga akan menghilangkan persyaratan untuk menggunakan properti DataGridBoundColumn.Binding untuk memasok nilai sel yang ditampilkan DataGrid?

Jika seluruh pekerjaan pengambilan data dialihdayakan ke aplikasi yang menggunakan DataGrid, maka aplikasi memiliki fleksibilitas penuh untuk melakukan pengambilan data dengan cara apa pun yang diperlukan. Ini akan memungkinkan banyak skenario pengambilan data yang berbeda, termasuk jutaan baris yang disebutkan @dotMorten . Tolong dong ya :smile:

Beberapa fitur yang tidak perlu di WPF DataGrid?

DataGrid versi WPF memiliki beberapa fitur yang tampaknya tidak perlu atau tidak praktis, dan fitur ini dapat dilewati di WinUI DataGrid, tetapi saya berharap beberapa orang mungkin memiliki pendapat yang berbeda tentang fitur ini.

Berapa banyak orang yang akan mengajukan keberatan jika WinUI DataGrid mengabaikan fitur di mana pengguna akhir dapat mengedit nilai sel sebaris/langsung di dalam DataGrid? Dalam kasus kami, di setiap tempat di mana kami menggunakan DataGrid, kami selalu menyetel DataGrid.IsReadOnly ke true untuk menonaktifkan fitur pengeditan inline/langsung. Kami mengizinkan pengguna untuk mengedit baris yang dipilih di panel atau panel terpisah, atau di RowDetails ( DataGrid.RowDetailsTemplate ), tetapi tidak langsung di dalam DataGrid itu sendiri.

Sepertinya WinUI DataGrid telah pindah ke arah menjatuhkan dukungan untuk inline/editing langsung karena WPF DataGrid memiliki CanUserAddRows dan CanUserDeleteRows tetapi properti ini tidak ada lagi di WinUI DataGrid. Mengapa tidak sepenuhnya menghapus fitur pengeditan sebaris/langsung? Berapa banyak orang yang keberatan dengan ide ini?

Pilihan sel individual: WPF DataGrid memiliki properti SelectionUnit yang dapat Anda atur ke Cell , FullRow , atau CellOrRowHeader . Dalam kasus kami, kami selalu menyetelnya ke FullRow dan tidak pernah menemukan kebutuhan untuk menyetelnya ke Cell . Namun saya melihat satu orang di sini telah meminta mode pemilihan sel tunggal. Pertanyaan saya adalah apakah mode pemilihan sel adalah permintaan umum atau langka.

Di sisi lain, pemilihan sel individual mungkin berguna saat pengguna menyalin baris/sel ke clipboard. Ini akan memungkinkan pengguna untuk menyalin sel individual (atau beberapa sel yang berdekatan) ke clipboard alih-alih menyalin seluruh baris. Namun saya tidak yakin apakah fitur ini benar-benar berharga atau tidak.

| Fitur Meragukan di WPF | Komentar |
| :--- | :--- |
| DataGrid.IsReadOnly | Mungkin tidak ada kebutuhan nyata untuk menyetel IsReadOnly ke false? |
| DataGrid.CanUserAddRows | Tidak ada di WinUI DataGrid. Sudah terbengkalai, atau mungkin belum dilaksanakan (saya tidak tahu rencananya). |
| DataGrid.CanUserDeleteRows | Tidak ada di WinUI DataGrid. Sudah terbengkalai, atau mungkin belum dilaksanakan (saya tidak tahu rencananya). |
| DataGrid.SelectionUnit | Tidak ada di WinUI DataGrid. |

Wow, diskusi yang luar biasa di sini. ❤️

Saya juga setuju dengan WPF DataGrid API. WPF DataGrid benar-benar DataGrid yang saya inginkan untuk WinUI 3.0.

Tetapi bahkan WPF DataGrid tidak memiliki beberapa fitur. Di masa lalu, sebagian besar pelanggan saya menggunakan DataGrid pihak ketiga yang lebih kuat untuk mendapatkan fitur ini:

• Filter di Header Kolom
• Baris filter lengkap di bagian atas DataGrid
• Tampilan data hierarkis yang kuat. Beberapa DataGrids pihak ke-3 benar-benar berfungsi seperti TreeView yang kuat dengan DataGrids bersarang. Sementara WPF DataGrid memungkinkan untuk membangun sesuatu seperti itu, itu tidak mendukungnya di luar kotak
• Dukungan untuk tipe data yang berbeda. Seperti misalnya kolom DateTime. Di DataGrid WPF Anda harus menggunakan DataGridTemplateColumn

Tapi bagaimanapun, apa pun yang Anda lakukan, saya pikir membangun DataGrid adalah pernyataan dan komitmen yang kuat untuk WinUI 3.0. Untuk aplikasi LOB, Anda tidak dapat menganggap serius kerangka kerja UI yang tidak berisi DataGrid bawaan. Dan sangat menyenangkan melihat investasi ini dibuat untuk WinUI!

@thomasclaudiushuber

Untuk aplikasi LOB, Anda tidak dapat menganggap serius kerangka kerja UI yang tidak berisi DataGrid bawaan. Dan sangat menyenangkan melihat investasi ini dibuat untuk WinUI!

Sepakat! Dalam kasus kami, DataGrid adalah komponen yang sangat penting yang kami gunakan di banyak tempat dan tidak dapat hidup tanpanya.

Tampilan data hierarkis yang kuat. Beberapa DataGrids pihak ke-3 benar-benar berfungsi seperti TreeView yang kuat dengan DataGrids bersarang.

Saya bingung dengan topik itu karena -- seperti Anda -- saya akan menemukan DataGrid hierarkis berguna dalam beberapa situasi, tetapi kekhawatiran saya adalah jika DataGrid mengimplementasikan fungsionalitas hierarkis, maka itu bisa menjadi terlalu rumit dan sulit, dan pelepasan DataGrid kemungkinan besar akan tertunda secara substansial. Fitur baru akan sulit untuk ditambahkan karena kerumitan membuat fitur baru kompatibel dengan fungsionalitas hierarkis dan non-hierarki.

Untuk menghilangkan masalah kompleksitas/penundaan yang disebutkan di atas, saya menyarankan solusi ini: Buat kelas terpisah bernama HierarchicalDataGrid yang secara internal menggunakan/membungkus instance DataGrid . Atau HierarchicalDataGrid dapat secara publik mewarisi DataGrid tetapi saya menduga pewarisan ini tidak praktis, oleh karena itu saya lebih suka menyarankan bahwa HierarchicalDataGrid mewarisi Control dan secara internal memiliki bidang pribadi ketik DataGrid . Dengan demikian fungsionalitas hierarkis akan diimplementasikan dalam lapisan HierarchicalDataGrid yang mengarahkan instance DataGrid non-hierarki internal.

Keuntungan utama dari solusi di atas adalah akan memberikan fitur hierarki yang diinginkan _tanpa_ menghambat DataGrid , tanpa membuat DataGrid begitu rumit sehingga menjadi tidak dapat dikelola dan lambat untuk dikembangkan.

Dukungan untuk tipe data yang berbeda. Seperti misalnya kolom DateTime.

Saya setuju. Lihat DataGridDateTimeColumn dan DataGridTimeSpanColumn yang saya usulkan di pesan sebelumnya.

@pinox

Filter seluruh halaman dengan mudah

@thomasclaudiushuber

Filter di Header Kolom; Baris filter lengkap di bagian atas DataGrid;

Filter akan sangat bagus untuk membantu pengguna akhir dengan cepat menemukan baris atau baris, alih-alih situasi saat ini yang dipaksa untuk melihat secara manual sejumlah besar baris untuk menemukan apa yang mereka cari.

Tapi bagaimana dengan masalah pencocokan teks filter pengguna dengan kolom non-teks? Arti kolom selain DataGridTextColumn , seperti memfilter dengan DataGridTemplateColumn dll? Saya menyarankan untuk menyelesaikan ini dengan sesuatu yang kira-kira seperti solusi berikut yang memberikan DataGridColumn (dan subkelas) kemampuan untuk mengonversi nilai sel menjadi kata kunci untuk digunakan dengan pencarian/pemfilteran/pencocokan.

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

Berikut adalah contoh cara menggunakan metode 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);
    }
}

Atau, nilai sel dapat dikonversi ke string tunggal alih-alih kumpulan kata kunci, tetapi alasan mengapa saya menyarankan kumpulan kata kunci adalah karena kata kunci memungkinkan untuk menggunakan algoritme pencarian yang berjalan dengan kecepatan tinggi bahkan ketika jumlah barisnya banyak. sangat besar.

Mudah menyalin masa lalu dari excel
Sekarang tidak ada cara untuk menggunakan ctrl+v untuk menyalin konten sel Excel ke datagrid. Sekarang salin semua konten sel ke satu sel di kisi data.

Harap berikan dukungan beberapa item yang dipilih dengan benar, dengan menjadikan SelectedItems sebagai properti ketergantungan untuk memungkinkan penggunaan pengikatan data saat mengelola baris yang dipilih.

@verelpode Saya dapat melihat pemilihan sel individual berguna untuk aplikasi jenis spreadsheet apa pun, bukan? Saya pikir itu lebih penting dalam skenario edit vs skenario tampilan. Saat melihat data dalam datagrid tanpa edit, saya setuju saya tidak akan melihat penggunaan untuk pemilihan sel individual dan selalu memiliki pemilihan baris penuh.

@anawishnoff Saya pikir @Laz3rPanth3r akan setuju dan beberapa masalah di sini dan di sini dari toolkit yang dapat menyerap data dengan mudah dan sederhana ke dalam DataGrid adalah fitur penting. Anda harus dapat mem-boot-strap grid dengan mengikat ke koleksi objek atau memperluas objek dalam daftar. Jika itu dapat dengan cerdas memilih kolom untuk angka dan string dan tipe data dasar, itu bagus. Pengembang selalu dapat melakukan lebih banyak pekerjaan setelah menyesuaikan kolom individual di luar itu.

Saya dapat melihat pemilihan sel individual berguna untuk aplikasi jenis spreadsheet apa pun, bukan?

Dalam spreadsheet, header kolom diberi nama dengan huruf abjad menaik, A, B, C, D, … dan jenis setiap kolom adalah sama, seolah-olah setiap kolom menggunakan DataGridTextColumn dan tidak ada kolom lain type diperlukan, dan nama kolom juga tidak terlalu dibutuhkan karena dibuat secara otomatis dari alfabet.
Perbedaan lain antara DataGrid dan spreadsheet adalah bahwa spreadsheet tidak mengurutkan baris saat Anda mengklik header kolom mana pun.

Maksud saya adalah, hanya kesamaan yang dangkal (kebanyakan kesamaan visual) yang ada antara DataGrid dan spreadsheet. DataGrid tidak benar-benar beroperasi seperti spreadsheet. Teknik pengambilan data sel DataGrid juga kurang cocok untuk spreadsheet.

Saya suka DataGrid tetapi akan berfungsi buruk jika saya mencoba menggunakannya untuk mengimplementasikan spreadsheet. Saya tidak berpikir DataGrid adalah pilihan yang tepat bagi siapa saja yang ingin mengimplementasikan spreadsheet.

Desain DataGrid yang ada selaras jauh lebih baik dengan database SQL daripada spreadsheet, dan pengembang database SQL akan berteriak keras jika seseorang mencoba mengklaim bahwa database adalah "hanya spreadsheet".

@verelpode Kontribusi Anda sangat rinci dan

Saat ini DataGrid mewajibkan aplikasi untuk menyetel DataGrid.ItemsSource, tetapi tidak praktis untuk membuat objek daftar yang berisi satu juta item. Jadi saya berharap DataGrid akan berhenti menjadi pintar di departemen pengambilan data dan sebagai gantinya membiarkan saya sepenuhnya melakukan pengambilan data sendiri, tanpa menggunakan DataGridBoundColumn.Binding dan DataGrid.ItemsSource.

Ini menarik, dan saya ingin melihat lebih dalam karena kami sangat tertarik dengan kinerja. Situasi/skenario data seperti apa yang Anda cari, khususnya? Apakah Anda ingin menghubungkan DataGrid langsung ke hasil kueri SQL, atau database, atau sesuatu seperti itu?

@khoshroomahdi Dengan menyalin dan menempel, maksud Anda Anda ingin menyalin sel excel ke DataGrid di aplikasi yang sedang berjalan, dan mengisi dengan cara itu? Itu kasus penggunaan yang menarik, saya ingin mendengar lebih banyak.

@alexyak , bisakah Anda memperluas sedikit lebih jauh? Properti SelectedItems saat ini memungkinkan Anda untuk mendapatkan semua item yang dipilih dalam DataGrid (melalui mode pilihan yang diperluas, bukan mode pilihan ganda). Saya melihat dari beberapa komentar lain di sini bahwa pemilihan dalam DataGrid pasti membutuhkan pekerjaan, tetapi saya ingin memahami permintaan Anda dengan lebih baik.

@anawishnoff ya persis.
Saya memiliki beberapa data di sel excel dan ingin menyalinnya di aplikasi yang sedang berjalan.

Untuk skenario yang tidak terikat data, kita harus melihat bagaimana kontrol WinForms DataGridView, yang saya tulis bertahun-tahun yang lalu, mendukung mode virtual: https://docs.microsoft.com/en-us/dotnet/api/system. windows.forms.datagridview.virtualmode

Saat ini DataGrid mewajibkan aplikasi untuk menyetel DataGrid.ItemsSource, tetapi tidak praktis untuk membuat objek daftar yang berisi satu juta item. Jadi saya berharap DataGrid akan berhenti menjadi pintar di departemen pengambilan data dan sebagai gantinya membiarkan saya sepenuhnya melakukan pengambilan data sendiri, tanpa menggunakan DataGridBoundColumn.Binding dan DataGrid.ItemsSource.

Saya setuju itu akan menyenangkan juga. Saya sedang memikirkan sesuatu seperti ListBox di mana Anda dapat menambahkan Item secara manual atau mengatur ItemsSource. Yang mengatakan, di masa lalu saya hanya membuat DataTable baru yang mewakili sebagian tampilan dari database lengkap untuk mengimplementasikan paging (yang merupakan kasus penggunaan yang baik untuk ini). Tampilan DataTable tersebut kemudian dapat diatur ke ItemsSource. Jadi sementara saya benar-benar berpikir ini bagus untuk dimiliki, sepertinya tidak wajib untuk kinerja tinggi.

Mengenai semua komentar yang mengubah kontrol menjadi kurang lebih subset Excel(r), saya pikir di luar kotak, DataGrid harus mendukung pemilihan sel dan pengeditan per sel. Namun, hal-hal seperti salin/tempel antar aplikasi eksternal harus ditangani oleh pengembang.

@alexyak Mengenai permintaan Anda untuk menjadikan SelectedItems sebagai DependencyProperty yang nyata dan dapat diikat, ini akan bagus untuk memulihkan status juga (sebagian besar permintaan fitur saya sejauh ini adalah mengembalikan status tampilan). Saya pikir ini adalah masalah seluruh kerangka kerja karena tidak didukung dalam kontrol WinUI/UWP apa pun yang saya ketahui. Ini mungkin harus menjadi permintaan fitur umum. Lihat diskusi di sini

@anawishnoff menulis:

Kontribusi Anda sangat rinci dan bijaksana, terima kasih banyak untuk semua itu!

Terima kasih, saya senang mendengar bahwa kontribusi saya berguna dalam membuat DataGrid menjadi lebih baik :)

Situasi/skenario data seperti apa yang Anda cari, khususnya? Apakah Anda ingin menghubungkan DataGrid langsung ke hasil kueri SQL, atau database, atau sesuatu seperti itu?

Itu masih terlalu pintar. Perilaku cerdas ini mencegah aplikasi yang berbeda melakukan pengambilan data dengan cara yang berbeda. Aplikasi yang berbeda memiliki keadaan yang sangat berbeda, sehingga sistem pengambilan data "terbaik" berbeda untuk aplikasi yang berbeda -- tidak ada satu pun "terbaik". Misalnya, beberapa aplikasi tidak pernah menampilkan lebih dari beberapa ratus baris, sedangkan beberapa aplikasi lain dapat bekerja dengan satu juta baris seperti yang disebutkan @dotMorten , oleh karena itu satu ukuran sepatu tidak cocok untuk semua.

Saya sarankan untuk benar-benar menurunkannya ke level ini:

1. DataGrid memutuskan bahwa ia perlu menampilkan (atau menggunakan) nilai yang ada di kolom 5 baris 9001 dalam sistem penyimpanan data eksternal.
2. DataGrid memberi tahu aplikasi bahwa itu membutuhkan nilai untuk kolom 5 dari baris 9001.
3. Aplikasi mengambil nilai untuk kolom 5 dari baris 9001. Ini mungkin melibatkan kueri SQL asinkron, atau Tugas C# asinkron, atau sistem data lainnya. Idealnya DataGrid harus mengizinkan langkah ini menjadi asinkron.
4. Aplikasi memberi tahu DataGrid bahwa itu selesai mengambil nilai untuk kolom 5 dari baris 9001. Aplikasi memberikan nilai ini ke DataGrid.
5. DataGrid menggunakan nilai dengan cara apa pun yang diperlukan, seperti menampilkan nilai seperti yang disebutkan pada langkah 1.

@RBrid menulis:

Untuk skenario yang tidak terikat data, kita harus melihat bagaimana kontrol WinForms DataGridView, yang saya tulis bertahun-tahun yang lalu, mendukung mode virtual:

Ya ya ya! Saya belum pernah menggunakan WinForms DataGridView, tetapi saya baru saja membaca dokumentasinya sekarang dan saya yakin Anda telah berhasil. Halaman web yang Anda tautkan mengatakan:
_"Mode virtual dirancang untuk digunakan dengan penyimpanan data yang sangat besar."_

Saya melihat bahwa WinForms DataGridViewCellValueEventArgs berisi properti ini:

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

Itu luar biasa, kecuali bahwa idealnya itu harus diperbarui untuk mendukung kata kunci C# async dan await , atau yang setara dengan UWP ( IAsyncOperation<TResult> ), atau lebih tepatnya segala jenis penundaan waktu antara DataGrid yang meminta nilai sel dan aplikasi yang mengirimkan nilai sel ke DataGrid. Jadi untuk memperbaruinya untuk mendukung async, lakukan ini:

1. Simpan acara CellValueNeeded .
2. Hapus properti DataGridViewCellValueEventArgs.Value .
3. Buat metode di DataGrid bernama sesuatu seperti SupplyCellValue yang akan dipanggil aplikasi, alih-alih diminta untuk segera/sinkron menyetel properti DataGridViewCellValueEventArgs.Value .

Metode SupplyCellValue dapat didefinisikan seperti ini:

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

Jadi pada saat runtime prosedurnya adalah:

1. DataGrid memutuskan bahwa ia perlu menampilkan (atau menggunakan) nilai yang ada di kolom 5 baris 9001 dalam sistem penyimpanan data eksternal.
2. DataGrid memicu acara CellValueNeeded dan menetapkan DataGridViewCellValueEventArgs.RowIndex ke 9001 dan DataGridViewCellValueEventArgs.ColumnIndex ke 5.
3. Penangan peristiwa (aplikasi) mulai menjalankan tugas asinkron yang akan mengambil nilai untuk kolom 5 dari baris 9001.
4. Ketika tugas async selesai berjalan, artinya ketika aplikasi telah mengambil nilainya, aplikasi memanggil metode DataGrid.SupplyCellValue .

Teknik dumbed-down ini lebih kuat dan fleksibel daripada teknik otomatis cerdas DataGridBoundColumn.Binding dan DataGrid.ItemsSource .

@alexyak , bisakah Anda memperluas sedikit lebih jauh? Properti SelectedItems saat ini memungkinkan Anda untuk mendapatkan semua item yang dipilih dalam DataGrid (melalui mode pilihan yang diperluas, bukan mode pilihan ganda). Saya melihat dari beberapa komentar lain di sini bahwa pemilihan dalam DataGrid pasti membutuhkan pekerjaan, tetapi saya ingin memahami permintaan Anda dengan lebih baik.

Kami membutuhkan penyatuan data dua arah yang tepat untuk model tampilan untuk mengelola banyak pilihan

@verelpode , kami telah memodelkan model WinForms DataGridView setelah kontrol Win32 ComCtl32 yang lebih lama. Secara khusus, saya sedang memikirkan bagaimana kontrol tampilan daftar menggunakan pesan LVN_GETDISPINFO dalam mode virtual (lihat https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview #handling-virtual-list-view-control-notification-codes dan https://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo). Barang lama dari tahun 90-an.

Bagaimanapun, saya percaya cara aspek pengambilan data asinkron harus ditangani adalah melalui 'acara yang ditangguhkan'.
Kontrol WinUI sudah menggunakan acara yang ditangguhkan dua kali:

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

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

Ini adalah pola yang ingin diadopsi oleh acara CellValueNeeded DataGrid baru. Ini memungkinkan event handler untuk memasok data secara asinkron dan memberi tahu kontrol saat selesai melakukannya. Lihat https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferral.

@RBrid
Poin bagus tentang GetDeferral() menjadi pola standar baru. Dalam kasus khusus CellValueNeeded , tampaknya jauh lebih sulit untuk menggunakan Deferral daripada dalam kasus/peristiwa lain. Perbaiki saya jika saya salah, tetapi saya pikir masalah dengan menggunakan GetDeferral() dalam kasus khusus ini adalah GetDeferral() membuat objek baru setiap kali dipanggil, dan ini akan menyebabkan sejumlah besar pembuatan objek dan pembersihan diulang untuk setiap sel dari setiap baris dari sejumlah besar baris yang berpotensi. Saya belum melihat kode sumber dari berbagai implementasi GetDeferral() oleh karena itu saya bisa salah tentang ini.

Dengan kata lain, kecuali Deferral mendukung daur ulang atau memiliki cara untuk membuat GetDeferral() jauh lebih efisien, maka itu masih terlalu pintar. Proposal bodoh saya dengan metode SupplyCellValue menghindari biaya overhead untuk membuat, menyelesaikan, dan membuang instance Deferral untuk setiap sel dari setiap baris yang berlaku.

1. GetDeferral()
2. Penangguhan.Lengkap
3. Tunda. Buang
4. Ulangi langkah di atas beberapa kali.

Tugas mengambil nilai sel bukan satu-satunya tugas manajemen data yang dapat dialihdayakan ke aplikasi. Penyortiran mungkin juga dialihdayakan. Oleh karena itu, mungkin ada baiknya mempertimbangkan untuk memikirkan antarmuka daripada satu acara CellValueNeeded . Sebuah aplikasi akan memberikan DataGrid modul manajemen data dalam bentuk objek yang mengimplementasikan antarmuka tertentu. DataGrid akan memanggil antarmuka ini untuk mengambil nilai sel, tetapi juga berpotensi tugas lain seperti penyortiran.

Untuk mendukung jutaan baris yang disebutkan @dotMorten , CellValueNeeded saja tidak akan menyelesaikan masalah lain yang terjadi saat pengguna mengklik header kolom dan DataGrid mencoba mengurutkan jutaan baris. Dengan demikian pengambilan sel DAN penyortiran dapat dialihdayakan ke aplikasi melalui modul/antarmuka yang disebutkan di atas.

Jika aplikasi tidak menyediakan modul/objek manajemen data apa pun ke DataGrid, maka idealnya DataGrid akan menggunakan modul manajemen data default. Jadi semua kode pengikatan data yang ada di DataGrid akan dipindahkan dari DataGrid dan ke kelas baru yang terpisah -- kelas yang mengimplementasikan modul manajemen data default dengan bekerja dengan DataGridBoundColumn.Binding dll.

yaitu ketika penyortiran juga dialihdayakan ke aplikasi atau modul manajemen datanya, maka ini membuka pintu ke berbagai solusi yang mendukung sejuta baris, seperti menulis modul manajemen data yang menginstruksikan server SQL untuk melakukan penyortiran, alih-alih mencoba- dan-gagal melakukan penyortiran satu juta baris di dalam DataGrid dalam waktu kurang dari 10 atau 20 jam setelah pengguna mengklik tajuk kolom untuk memulai penyortiran.

@verelpode , ya itu kekhawatiran yang valid. Saya berharap DataGrid memiliki kumpulan objek Windows.Foundation.Deferral yang dapat didaur ulang. Kami perlu mengkonfirmasi kelayakan dan kinerja dengan pasti.

Setelah mengambil ketergantungan pada Windows Community Toolkit DataGrid yang memiliki Detail Baris sebagai fitur (walaupun dengan bug kinerja yang serius tetapi dengan solusi), kami sangat ingin datagrid baru ini memilikinya sebagai fitur juga - dengan opsi yang sama untuk memiliki beberapa detail baris secara bersamaan. Menggunakannya untuk skenario data streaming server ke klien.

Sejuta baris versus GUI paging , @robloo menulis:

Saya setuju bahwa [mendukung satu juta baris] akan menyenangkan juga. .... Yang mengatakan, di masa lalu saya hanya membuat DataTable baru yang mewakili sebagian tampilan dari database lengkap untuk mengimplementasikan paging (yang merupakan kasus penggunaan yang baik untuk ini). Tampilan DataTable tersebut kemudian dapat diatur ke ItemsSource. Jadi sementara saya benar-benar berpikir ini bagus untuk dimiliki, sepertinya tidak wajib untuk kinerja tinggi.

Paging adalah teknik yang berguna dan layak disebut, tetapi memiliki kelemahan substansial: Itu membuat fitur penyortiran DataGrid praktis tidak berguna. Begitu juga untuk fitur filtering di DataGrid versi selanjutnya. Paging membuat penyortiran dan pemfilteran tidak berguna atau setidaknya kurang bermanfaat.

Misalnya, bayangkan 2 atau 3 kolom adalah kolom tanggal, dan pengguna ingin melihat baris yang memiliki tanggal terbaru (atau terlama) di kolom tanggal kedua. Jadi pengguna mengklik header kolom tanggal kedua untuk mengurutkan DataGrid menurut kolom itu, dan juga mengklik untuk mengubah arah pengurutan dari turun ke menaik atau sebaliknya. Ini berfungsi dengan baik jika tidak ada paging yang digunakan, atau jika jumlah total baris cukup kecil untuk tidak melebihi satu halaman, tetapi akan rusak jika ada beberapa halaman.

Pengguna perlu menemukan tanggal terbaru (atau terlama) di semua baris tetapi halaman GUI DataGrid hanya menunjukkan tanggal terbaru (atau terlama) di halaman saat ini, tidak di semua baris, sehingga paging membuat penyortiran (dan pemfilteran) secara praktis tidak berguna.

Ini menimbulkan pertanyaan tentang baris mana yang mendarat di halaman mana. Jawabannya adalah bahwa setiap halaman biasanya berisi subset baris yang praktis-acak, ketika halaman/baris diperoleh melalui kueri SQL SELECT yang tidak menggunakan ORDER BY . (Maksud saya acak dari sudut pandang pengguna, tidak benar-benar acak.)

Pseudo-random tidak membantu bagi pengguna akhir. Untuk menghilangkan keacakan yang bermasalah ini, kita dapat berpikir untuk menggunakan SQL ORDER BY (bersama dengan kata kunci ASC atau DESC untuk mengontrol arah pengurutan), dan kemudian ya halamannya tidak lagi acak, tetapi masih rusak karena penggunaan ORDER BY selalu mengurutkan berdasarkan kolom yang sama dan arah pengurutan yang sama, artinya urutan pengurutan sering berbeda dari urutan yang dipilih oleh pengguna akhir mengklik kolom tajuk di DataGrid.

Untuk memperbaikinya, Anda perlu menggunakan kueri SQL yang berbeda setiap kali pengguna mengklik header kolom yang berbeda. SQL ORDER BY ... ASC/DESC harus tetap sama dengan urutan pengurutan apa pun yang dipilih oleh pengguna akhir DataGrid. DataGrid tidak mendukung ini saat ini.

Solusi yang disarankan ada di pesan saya sebelumnya : Saya menyarankan agar DataGrid mengizinkan penyortiran untuk dialihdayakan ke aplikasi (atau ke "modul manajemen data"). Ide ini akan memungkinkan aplikasi (atau "modul manajemen data") untuk mengubah SQL ORDER BY ... ASC/DESC setiap kali pengguna akhir mengubah urutan pengurutan DataGrid dengan mengklik tajuk kolom, dll.

Mungkin juga bermanfaat untuk memberikan acara yang sudah ada sebelumnya DataGrid.Sorting properti yang dapat diatur dalam argumen acara yang memungkinkan aplikasi (penangan acara) untuk membatalkan penyortiran dan mengambil alih. Idealnya argumen acara juga akan menentukan apakah perubahan urutan pengurutan diminta secara terprogram versus diminta oleh pengguna akhir yang mengklik tajuk kolom, dll. Dalam hal ini, mungkin juga membantu untuk mengganti nama acara DataGrid.Sorting menjadi sesuatu yang kurang ambigu karena saat ini maksud dan tujuan dari acara Sorting belum jelas. Lihat juga acara yang diusulkan

Setelah mengambil ketergantungan pada Windows Community Toolkit DataGrid yang memiliki Baris
Detail sebagai fitur (meskipun dengan bug kinerja yang serius tetapi dengan solusi), kami akan
sangat menyukai datagrid baru ini untuk memilikinya sebagai fitur juga - dengan opsi yang sama untuk dimiliki
beberapa detail baris secara bersamaan. Menggunakannya untuk skenario data streaming server ke klien.

Tautan ke masalah kinerja Detail Baris: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2842
Repro: https://github.com/observito/DataGridRowDetailsPerfTest

Titik awal yang baik adalah melihat mitra Anda Telerik dengan RadDataGrid (UWP Open Source) mereka. Dengan salah satu klien saya, saya menggunakannya dan itu benar-benar berfungsi dengan baik. Ini sangat cepat dan serbaguna. Satu-satunya hal yang sulit adalah kode mereka, tidak ada cara untuk memodifikasi apa pun dari mesin mereka tanpa pemahaman arsitektur yang baik.

Saya berharap DataGrid baru memiliki performa yang sama seperti Telerik.

Fitur grid syncfusion sangat bagus tetapi tidak ramah mvvm. Jadi Anda bisa melakukan lebih baik.

Hai lagi semua! Mari kita lanjutkan percakapan ini. Apa pendapat Anda tentang dokumentasi DataGrid yang ada saat ini?

Berikut tautan ke halaman dokumentasi utama yang menautkan ke semua halaman lain yang relevan.

Jika kami membuat DataGrid baru, kami ingin memastikan dokumentasi yang menyertainya akan menjadi yang terbaik, mudah dipahami, dan mengatasi semua masalah dan skenario yang penting bagi pengembang kami.

_Apa topik yang Anda harap kami miliki? Apa saja topik yang bisa diklarifikasi?_

Hai lagi semua! Mari kita lanjutkan percakapan ini. Apa pendapat Anda tentang dokumentasi DataGrid yang ada saat ini?

Berikut tautan ke halaman dokumentasi utama yang menautkan ke semua halaman lain yang relevan.

Jika kami membuat DataGrid baru, kami ingin memastikan dokumentasi yang menyertainya akan menjadi yang terbaik, mudah dipahami, dan mengatasi semua masalah dan skenario yang penting bagi pengembang kami.

_Apa topik yang Anda harap kami miliki? Apa saja topik yang bisa diklarifikasi?_

Gambar yang menunjukkan pengaturan DataGrid yang khas, bersama dengan xaml dan kode untuk membuatnya, akan berguna.

Gambar yang menunjukkan pengaturan DataGrid yang khas, bersama dengan xaml dan kode untuk membuatnya, akan berguna.

@mdtauk Apakah ada pengaturan DataGrid tertentu yang menurut Anda "khas", atau kasus penggunaan di mana Anda secara konsisten menemukan DataGrid sebagai pilihan terbaik untuk digunakan?

Gambar yang menunjukkan pengaturan DataGrid yang khas, bersama dengan xaml dan kode untuk membuatnya, akan berguna.

@mdtauk Apakah ada pengaturan DataGrid tertentu yang menurut Anda "khas", atau kasus penggunaan di mana Anda secara konsisten menemukan DataGrid sebagai pilihan terbaik untuk digunakan?

Saya pikir untuk jangka waktu WinUI 3.0, menunjukkan WPF umum, skenario tampilan grid/ikon data Win32. Serta apa yang dianggap Microsoft sebagai desain UI DataGrid Lancar/Modern.

Itu jika ide di balik kontrol, adalah untuk mendorong perpindahan dari UI lama ke WinUI 3

@anawishnoff Saya pikir beberapa pertanyaan yang kami miliki dari toolkit dalam hal hal-hal yang orang cari dokumentasi di mana lebih banyak skenario ini juga:

• Tema/Re-templating/Penyelarasan
• Pengikatan Data (secara umum dan dalam XAML)
• Penanganan Acara/Seleksi/Casing
• Mengedit perilaku (terutama mengedit saat diklik)
• Multi-paging (yang harus dipasangkan dengan baik dengan #60 dan #268)
  
  
  
  • Memuat koordinasi animasi saat memuat data
  
  
• Salin/Tempel/Memformat
• Jenis Data Kolom yang Berbeda (dan yang khusus) (misalnya enum)
• Menu Konteks
• Aksesibilitas

Saya perhatikan bahwa Toolkit DataGrid yang ada memerlukan IEnumerable untuk properti ItemsSource-nya. Meskipun ini tampak seperti keputusan logis, ini membuat pengaturan objek yang dikembalikan oleh Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector() sebagai properti ini tidak mungkin. (Kecuali ada cara untuk mengembalikan objek) Selanjutnya, kontrol lain seperti ListView dan GridView mendukung pengaturan properti ItemsSource mereka ke nilai tipe objek. Saya tidak yakin, tetapi mendukung ini kemungkinan akan memungkinkan antarmuka pengguna yang lebih responsif selama operasi penyimpanan.

@mdtauk Apakah ada pengaturan DataGrid tertentu yang menurut Anda "khas", atau kasus penggunaan di mana Anda secara konsisten menemukan DataGrid sebagai pilihan terbaik untuk digunakan?

Saya pikir untuk jangka waktu WinUI 3.0, menunjukkan WPF umum, skenario tampilan grid/ikon data Win32. Serta apa yang dianggap Microsoft sebagai desain UI DataGrid Lancar/Modern.

Itu jika ide di balik kontrol, adalah untuk mendorong perpindahan dari UI lama ke WinUI 3

Contoh Win32 (File Explorer)

Contoh WPF

Contoh Web Kain

contoh UWP

@mdtauk Terima kasih atas tangkapan

@michael-hawker Luar biasa. Saya sudah melihat beberapa topik di sana yang telah diangkat beberapa kali di utas ini, jadi itu jelas merupakan tempat yang baik untuk memulai.

@ duke7553 Saya tidak 100% yakin tentang solusi untuk itu, atau jika mendukung tipe objek akan bijaksana. Mungkin @RBrid bisa

@anawishnoff & @duke7553 , saya akan membangun kontrol DataGrid baru di atas kontrol WinUI ItemsRepeater baru. Dan kontrol itu mengekspos ItemsSource-nya sebagai Objek:
Object ItemsSource { get; set; };

Semoga mendukung CellDecorationStyleSelector seperti di Telerik.

@anawishnoff

kami tertarik untuk memindahkannya ke kontrol WinUI asli

hmmmm ketika Anda mengatakan "lulus", apakah itu termasuk menurunkannya ke C++? Saat ini DataGrid WinUI ditulis dalam C#. Saya harap "lulus" tidak berarti "turun peringkat". Yang penting, WinUI perlu mencapai titik di mana tim WinUI dapat mengatakan bahwa WinUI lebih baik daripada WPF dalam segala hal yang penting, tetapi tujuan ini sangat terlambat. Sasaran ini akan menjadi lebih terlambat jika waktu/sumber daya terbuang sia-sia dalam penurunan versi kode yang tidak perlu seperti DataGrid dari C# ke C++.

Meskipun awalnya ada alasan untuk menulis WinRT/UWP/WinUI di C++, sayangnya alasan itu tidak membuahkan hasil, dan Google/Android mengambil sebagian besar pangsa pasar smartphone, oleh karena itu alasan awal untuk menggunakan C++ tidak berlaku lagi (dengan mudah dikatakan di belakang, tetapi tidak begitu mudah untuk dikatakan sebelumnya). Jika WinUI ditulis dalam C# dari awal, maka tujuan yang lebih baik dari WPF akan tercapai 3 tahun yang lalu, tetapi sekarang sudah 8 tahun dan masih belum tercapai, dan tidak ada yang dapat secara akurat mengatakan kapan tujuan akan tercapai. Semoga tujuan yang lebih baik dari WPF dan tujuan "kelulusan" WinUI DataGrid tidak akan tertunda oleh konversi yang tidak perlu ke bahasa pemrograman yang lebih lama dan kurang produktif.

Saya bias mendukung C++ karena saya memulai pemrograman dalam C++ bahkan sebelum C# ada, dan orang-orang lebih memilih untuk tetap dengan apa yang awalnya mereka pelajari, dan dengan senang hati mengingat _"masa lalu yang indah"_. Meskipun bias saya mendukung C++, saya berhenti menulis C++, dan saya pikir DataGrid tidak boleh diturunkan ke C++ dan ditunda. Biarkan sebagai C# dan fokus pada hal-hal yang lebih penting seperti membuat berbagai perbaikan yang disarankan oleh orang-orang dalam masalah ini, dan mencapai tujuan yang lebih baik dari WPF sebelum 1 dekade tercapai.

Saya menyukai banyak aspek WinUI, dan saya menghargai banyak perbaikan cerdas di dalamnya, dan saya menulis kode aplikasi untuk WinUI, tetapi apakah Anda ingin mengetahui kebenaran yang sebenarnya? Sebenarnya, sayangnya saya belum pernah merilis aplikasi WinUI apa pun kepada pengguna. Perangkat lunak yang dirilis ke pengguna ditulis dengan WPF, dan pengguna tidak peduli karena perangkat lunak bekerja dengan baik dan termasuk modernisasi GUI. Meskipun saya telah menulis banyak kode aplikasi untuk WinUI, itu semua persiapan, perencanaan, pengujian, menunggu, tidak benar-benar digunakan oleh pengguna. Mudah-mudahan tahun depan komponen WinUI pertama akan dirilis ke pengguna, tetapi saya akan lebih menghargai peralihan ini daripada mereka. Pengguna hampir tidak akan menyadari peralihan, jika semuanya berjalan sesuai rencana.

Dari sudut pandang Microsoft, WinRT/UWP adalah perangkat lunak berkualitas rilis, diterbitkan untuk pengguna sejak tahun 2012, tetapi dari sudut pandang saya, UWP masih merupakan eksperimen besar. Bagi saya, UWP (termasuk WinUI) adalah versi beta-test besar yang telah saya mainkan selama bertahun-tahun.

Selama beberapa tahun pertama UWP, setiap tahun saya berpikir: _"errr… Saya akan menunggu sampai tahun depan. Masih terlalu banyak hal di WPF yang hilang di UWP. Pasti tahun depan akan lebih baik."_
Kemudian tahun berikutnya datang dan saya mengulangi pemikiran yang sama. Kemudian tahun berikutnya datang dan saya mengulangi pemikiran yang sama. Semoga tahun ini adalah tahun terakhir untuk mengatakan itu, atau setidaknya itu niat saya.

WinUI tidak mampu menunda lebih banyak. Biarkan DataGrid WinUI sebagai kode C#. Mulailah menulis lebih banyak kode WinUI dalam C# untuk meningkatkan produktivitas. Sekarang 8 tahun dan Android telah mengambil pangsa pasar yang besar. Itu situasi yang parah.

Omong-omong, saya sebenarnya sedang baik/murah hati ketika saya mengatakan bahwa UWP masih versi beta, karena secara teknis UWP cocok dengan definisi versi alpha, bukan beta. Untuk menjadi versi beta yang sebenarnya, perlu fitur-lengkap, tetapi UWP belum mencapai status fitur-lengkap, oleh karena itu UWP masih alpha. Misalnya, artikel "Siklus hidup rilis perangkat lunak" Wikipedia mengatakan:

"Fase beta umumnya dimulai ketika perangkat lunak memiliki fitur lengkap tetapi kemungkinan mengandung sejumlah bug yang diketahui atau tidak dikenal."
"Perangkat lunak Alpha mungkin tidak berisi semua fitur yang direncanakan untuk versi final."

Wikipedia mendefinisikan "fitur lengkap" sebagai berikut:

"Versi lengkap fitur dari sebuah perangkat lunak memiliki semua fitur yang direncanakan atau fitur utamanya diimplementasikan tetapi belum final karena bug, masalah kinerja atau stabilitas. Ini terjadi pada akhir pengujian alfa pengembangan."

Tidak masuk akal untuk menggambarkan UWP sebagai fitur-lengkap karena jika itu benar-benar fitur-lengkap, maka UWP harus memiliki semua kemampuan Windows '95 plus lebih, tetapi tidak -- UWP belum melebihi Windows 95 di semua bidang . Windows 95 dirilis 25 tahun yang lalu. Ketika UWP/WinRT dirilis 7-8 tahun yang lalu, Microsoft menderita kerugian $900 juta dan kekurangan aplikasi di Windows Store. Itu adalah versi alfa yang diberi label sebagai versi rilis, sehingga pengembang aplikasi menunggu dan menonton. Hari ini, hampir 8 tahun kemudian, itu masih versi alpha dan sangat terlambat, dan saya masih menunggu dan menonton dan menunggu.

Akan sangat bermanfaat bagi Microsoft dan pengembang jika Microsoft akan membuat keputusan/komitmen serius untuk memprioritaskan produksi UWP versi beta yang sebenarnya, untuk segera diikuti oleh versi Kandidat Rilis yang sebenarnya. Ini akan sangat direkomendasikan dan tindakan yang sangat masuk akal. Ini akan sangat baik untuk semua orang.

UWP masih alpha/tidak lengkap karena beberapa alasan, misalnya: 25 tahun yang lalu, mudah menggunakan fungsi "MoveFile" di Windows 95 untuk memindahkan file atau folder (walaupun fungsinya bernama "MoveFile", itu mendukung kedua file dan folder). Bisakah UWP memindahkan folder? Tidak, belum. Jelas bahwa kemampuan untuk memindahkan folder adalah salah satu fitur dasar dasar yang mendasar, tetapi UWP masih kehilangan fitur penting ini dan lainnya, oleh karena itu tidak masuk akal untuk menggambarkan UWP sebagai fitur yang lengkap, oleh karena itu UWP belum mencapai status beta, meskipun dirilis 7-8 tahun yang lalu. Microsoft perlu memprioritaskan UWP versi beta yang sebenarnya.

Repo GitHub publik untuk melacak masalah UWP (selain masalah UI) belum ada, sejauh yang saya tahu (atau jika repo UWP memang ada, saya tidak dapat menemukannya). Sekali lagi ini cocok dengan definisi versi alfa karena repo pelacakan masalah publik sering kali tidak diinginkan selama tahap alfa. Jika itu adalah versi beta atau rilis yang sebenarnya, maka repo pelacakan masalah publik akan telah dibuka, dan UWP akan menyertakan semua fitur Windows 95, dan Windows 7, dan banyak lagi.

Bagaimana situasi ini mempengaruhi DataGrid ? Mempertimbangkan bahwa versi beta lengkap fitur dari UWP sangat terlambat, dan mengingat parahnya situasi ini dan kerugian multi-miliar dolar yang diderita Microsoft sebagai akibatnya, tidak dapat dibenarkan dan masuk akal untuk membuang lebih banyak waktu. dengan mengonversi WinUI DataGrid ke kode yang tidak dikelola dan bahasa pemrograman yang lebih lama. Microsoft berulang kali mengatakan bahwa keuntungan besar dari C# dan "kode terkelola" adalah peningkatan produktivitas, dan saya dapat mengatakan bahwa klaim Microsoft tentang "kode terkelola" benar-benar benar dalam pengalaman saya dengan C++ dan C#. UWP akan mencapai status beta yang sebenarnya beberapa tahun yang lalu jika terutama ditulis menggunakan kode terkelola yang dimulai dengan versi 1.0. Jadi saya berharap situasinya tidak akan menjadi lebih buruk dengan melakukan lebih banyak lagi penurunan versi yang tidak perlu ini dari kode terkelola ke kode tidak terkelola.

Sebagai perbandingan, sebagian besar WPF berhasil diselesaikan dalam 4 tahun dari 2006 hingga 2010. WPF terutama merupakan kode yang dikelola, tidak seperti UWP. UWP adalah kode yang tidak dikelola dan setelah 8 tahun pengembangan, Windows 95 masih mengalahkan UWP di beberapa area, jadi Microsoft jelas benar ketika Microsoft mengklaim bahwa kode yang dikelola meningkatkan produktivitas. Masalah ini perlu diselesaikan secepatnya. WinUI seharusnya jauh lebih mudah/lebih cepat untuk dibuat daripada WPF karena kedua proyek memiliki pemilik yang sama (Microsoft) sehingga WinUI bebas untuk menyalin kode dari WPF. Jadi WinUI seharusnya membutuhkan kira-kira setengah dari waktu pengembangan WPF. Sebenarnya WinUI seharusnya tidak pernah dimulai, melainkan Microsoft seharusnya mengembangkan fitur WinUI di versi baru WPF -- WinUI seharusnya adalah WPF 5.0. Jadi, situasinya kacau balau dan akan sangat bermanfaat bagi Microsoft untuk memprioritaskan pembersihan sisa kekacauan ini, dan berhenti melakukan hal-hal yang membuat kesalahan multi-miliar dolar menjadi lebih buruk daripada sebelumnya (dan masih terjadi saat Anda melihat pada situasi pangsa pasar smartphone saat ini).

Ini berarti, untuk mencegah lebih banyak kerugian, Microsoft akan mendapat manfaat dengan mengingat apa yang telah dikatakan/diketahui Microsoft di masa lalu:

• Kode yang dikelola meningkatkan produktivitas, menurut klaim Microsoft sendiri. Ketika Anda melihat 8 tahun UWP dibandingkan dengan 4 tahun WPF, kesimpulannya pasti bahwa Microsoft benar tentang manfaat dari kode yang dikelola.
• Bahasa skrip untuk skrip, dan bahasa pemrograman untuk pemrograman. JavaScript dan PowerShell bagus untuk tujuan yang dimaksudkan (skrip), tetapi jelas merupakan pilihan yang tidak cocok untuk pemrograman aplikasi.
• Agar berhasil, Microsoft harus maju dari alfa ke beta untuk merilis, dan ini hanya berhasil jika itu adalah versi rilis yang sebenarnya, bukan alfa yang tidak lengkap yang diberi label sebagai "rilis". Jadi Microsoft Store sebagian besar kosong untuk waktu yang sangat lama.
• Insinyur perangkat lunak dan karyawan lainnya bekerja paling baik ketika mereka bekerja dengan imbalan remunerasi yang wajar dan jumlah jam kerja yang wajar, serta lingkungan kerja yang sehat. Jelas, kerugian multi-miliar dolar Microsoft tidak akan pernah dapat dibalikkan oleh penggunaan orang-orang fanatik/fanatik yang tidak dibayar dan apa yang disebut "pekerjaan siang" dan "pekerjaan malam" dan kondisi kerja mereka yang tidak berkelanjutan/tidak sehat.
• Kemenangan pangsa pasar Android yang besar bukan berkat fanatik yang tidak dibayar. Jika fanatik yang tidak dibayar adalah alasan untuk menang, maka Linux tidak akan gagal. Penjelasannya jauh lebih sederhana: Harga tablet dan smartphone Android JAUH lebih rendah daripada tablet dan smartphone Windows. Jelas pengguna akhir tidak peduli dengan agama/ideologi "sumber terbuka" (pengguna bahkan tidak tahu apa itu), melainkan mereka hanya menyukai harga perangkat Android yang murah.
• Win16 sangat usang. Ini adalah teknologi dari 20-30 tahun yang lalu, dari hari-hari awal pemrograman "Wild West". Oleh karena itu, berhenti menulis kode baru berdasarkan Win16. Menyebutnya "Win32" tidak benar-benar mengubah fakta bahwa pada dasarnya masih Win16. Win32 adalah hal yang sama dengan Win16 kecuali dengan ukuran pointer yang diperluas dari 16 bit menjadi 32 bit. Terlalu banyak grup di Microsoft yang terus menulis kode baru berdasarkan Win16/32. Ini sangat tidak efisien dan membuang-buang sumber daya.

@anawishnoff

kami tertarik untuk memindahkannya ke kontrol WinUI asli

Lihat juga artikel Wikipedia "Biaya hangus" :

Efek biaya hangus (atau efek Concorde) adalah fakta bahwa perilaku sering mengikuti kekeliruan biaya hangus; orang menunjukkan "kecenderungan yang lebih besar untuk melanjutkan upaya setelah investasi uang, tenaga, atau waktu telah dilakukan." Perilaku ini dapat digambarkan sebagai "membuang uang yang baik setelah yang buruk," dan menolak untuk menyerah dapat digambarkan sebagai "memotong kerugian."

Dan juga "Bias kelanjutan rencana" :

Bias kelanjutan rencana, get-there-itis atau press-on-itis adalah kecenderungan yang tidak bijaksana untuk bertahan dengan rencana yang gagal. Ini adalah bahaya yang berbahaya bagi nakhoda kapal atau pilot pesawat yang mungkin tetap pada jalur yang direncanakan bahkan ketika itu mengarah pada bencana yang fatal dan mereka harus membatalkannya. ..... Proyek sering mengalami pembengkakan biaya dan penundaan karena kesalahan perencanaan dan faktor terkait termasuk optimisme yang berlebihan, keengganan untuk mengakui kegagalan, pemikiran kelompok dan keengganan untuk kehilangan biaya hangus.

WinRT/UWP menyebabkan Microsoft menderita kerugian $900 juta pada tahun pertama atau kedua, dan toko aplikasi kosong terlalu lama. WinRT/UWP adalah kegagalan besar, sehingga seharusnya dibatalkan pada tahun kedua, tetapi dilanjutkan karena "Bias kelanjutan rencana" dan keengganan untuk kehilangan biaya hangus. Hal ini diajarkan dalam kursus manajemen. Apakah kelanjutan rencana akhirnya menghapus atau membalikkan bencana kegagalan WinRT/UWP? Tidak, ini masih merupakan kegagalan besar saat ini jika Anda melihat dari segi pangsa pasar smartphone. Uraian-uraian tersebut di Wikipedia secara akurat menggambarkan situasi UWP.

Sekarang hari ini kita semua harus setuju bahwa pada saat ini, 7-8 tahun setelah rilis WinRT/UWP, sekarang sudah terlambat untuk membatalkan UWP, tetapi ini berarti kita kembali menjadi korban dari "Bias kelanjutan rencana " dan keengganan untuk kehilangan biaya hangus.

Jadi apa yang bisa dilakukan untuk menyelamatkan situasi? Kami tidak dapat menyelamatkan situasi dengan membatalkan UWP, meskipun seharusnya sudah dibatalkan bertahun-tahun yang lalu. Yang bisa kita lakukan adalah: Terima kerusakan besar yang dilakukan oleh WinRT, tetapi jangan menyebabkan kerusakan lebih lanjut, dan lakukan perubahan pada prosedur/kebijakan proyek. Ini berarti, berhenti mengulangi/melanjutkan kesalahan fatal yang sama dari WinRT. Misalnya, hentikan penurunan versi kode terkelola dalam jumlah besar ke kode "asli" lama yang tidak terkelola yang tidak produktif. Penundaan dalam mencapai status beta yang sebenarnya sudah sangat besar -- mengapa penundaan ini semakin parah?

Kesalahan "Bias kelanjutan rencana" / biaya hangus berlanjut jika DataGrid diturunkan ke kode "asli" yang tidak dikelola. Ketika kesalahan besar seperti WinRT/UWP dibuat, itu menjadi jauh lebih buruk ketika kesalahan yang sama diulang lagi dan lagi dan lagi. Untuk membatasi kerusakan, Anda harus berhenti mengulangi kesalahan yang sama. Sudah waktunya untuk belajar dari bencana kegagalan WinRT dan mulai menerapkan perban untuk menghentikan kehilangan darah yang sedang berlangsung.

Mengonversi DataGrid ke kode yang tidak dikelola sama dengan pergi ke perpustakaan dan meminjam semua buku manajemen proyek terbaik dari penulis terbaik dengan pengetahuan/pengalaman paling banyak, dan kemudian membuang semua buku manajemen luar biasa ini ke dalam api unggun dan menyaksikannya terbakar.

@verelpode Saya ingin tahu apa maksud Anda di sini dengan dua posting Anda yang sangat besar dengan DataGrid. Saya pribadi tidak begitu mengerti apa umpan balik di atas secara khusus untuk meningkatkan kontrol OOB DataGrid. Satu-satunya hal yang saya dapatkan adalah Anda khawatir membuang-buang waktu untuk mengubahnya menjadi kode asli, tetapi itu tidak membahas mereka yang menggunakan WinUI dari C++. Anda masih bebas menggunakan implementasi terkelola saat ini jika Anda setuju dengan overhead pemuatan runtime terkelola. Segala sesuatu yang lain tampaknya tentang WinRT dan model aplikasi UWP, yang keduanya tidak benar-benar berlaku untuk WinUI, karena sepenuhnya tidak terikat dengan v3.

@dotMorten -- alasan mengapa saya menulis detail ekstra dalam pesan-pesan itu adalah karena jika saya tidak menjelaskan masalahnya secara memadai, maka orang-orang tidak akan memahaminya. Tapi sayangnya sekarang saya melihat bahwa detail ekstra gagal dan tetap tidak dipahami. Itu sangat membuat frustrasi. Inilah alasan mengapa banyak orang bahkan tidak repot-repot menulis umpan balik sama sekali, karena mereka percaya tidak ada gunanya mencoba menjelaskan masalah semacam ini kepada orang-orang, dan bahkan jika pesannya berhasil dipahami, maka sudah menjadi sifat manusia untuk menembak orang yang menyampaikan berita buruk, jadi lebih baik tidak mengatakan apa-apa, atau hanya tersenyum "sopan" sambil berpikir sebaliknya.

karena semakin tidak terikat dengan v3.

Pelepasan v3 ini tidak mencegah pengulangan kesalahan yang sama. "Bias kelanjutan rencana" masih ada.

Pergi ke halaman rumah Microsoft:
https://www.microsoft.com/en-us/
Sekarang gulir ke bawah halaman beranda sampai Anda melihat Windows Phone. Oh! Lihat itu! Kami telah mencapai akhir halaman beranda dan Windows Phone tidak disebutkan DI MANA SAJA di halaman beranda Microsoft! Apa artinya ini? Artinya, bangun. Itu berarti UWP adalah kegagalan besar seperti yang saya katakan. Artinya, penting untuk berhenti mengulangi kesalahan yang sama yang menyebabkan kegagalan UWP. Artinya, mengubah rencana untuk menyelamatkan dan memulihkan diri dari bencana.
Akan menjadi kesalahan manajemen jika WinUI dan DataGrid terus mengulangi kesalahan yang sama seperti pada kegagalan UWP.

"Pada Mei 2016, Microsoft memusnahkan bisnis selulernya, .... Pada 2017, eksekutif Microsoft Joe Belfiore mengungkapkan bahwa Microsoft telah menghentikan pengembangan ponsel Windows baru dan fitur baru untuk Windows 10 Mobile, dengan alasan kerugian dalam pangsa pasar dan kurangnya pengembangan aplikasi."
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

Ana mencantumkan 5 poin untuk memberikan umpan balik tentang wrt DataGrid. Manakah dari poin-poin itu yang Anda komentari? Saya kira itu yang tidak saya dapatkan dari apa yang Anda tulis. UWP tidak memenuhi kebutuhan semua orang, tetapi WinUI3 tidak mendikte menggunakan model aplikasi UWP, dan Anda tampaknya sebagian besar menentang UWP? Jadi kamu harus baik-baik saja di sana.

Anda menyebutkan DataGrid tidak boleh terus membuat kesalahan yang sama. Jadi kesalahan mana yang secara khusus dilakukan pada DataGrid yang ada, dan bagaimana menurut Anda kesalahan itu harus diperbaiki? (selain dari Anda tidak ingin itu diimplementasikan dalam C++ karena alasan tertentu)

@dotMorten

Ana mencantumkan 5 poin untuk memberikan umpan balik tentang wrt DataGrid. Manakah dari poin-poin itu yang Anda komentari?

Bagian di mana saya mengutip Ana di awal pesan saya. Saya mengomentari bagian pesan Ana yang saya kutip di awal pesan saya.

WinUI3 tidak mendikte menggunakan model aplikasi UWP

Itu tidak ada hubungannya dengan pesan saya. WinUI 3 yang tidak terikat dan tersedia melalui paket nuget tidak relevan dengan pertanyaan apakah WinUI 3 melanjutkan kesalahan manajemen yang sama yang menyebabkan kegagalan UWP dan Windows Phone dan kerugian multi-miliar dolar Microsoft.

bagaimana Anda menyarankan mereka harus diperbaiki?

6 poin-poin di akhir pesan saya sebelumnya . Poin peluru kedua (scripting) berhubungan dengan WinUI dan UWP secara umum, tetapi tidak berhubungan dengan DataGrid. Poin peluru pertama adalah yang paling penting jika Anda bertanya secara khusus tentang DataGrid.
Saya juga menulis: berhenti menurunkan versi kode terkelola dalam jumlah besar ke kode "asli" lama yang tidak terkelola yang tidak produktif. Penundaan dalam mencapai status beta yang sebenarnya sudah sangat besar -- mengapa penundaan ini semakin parah?

@anawishnoff menulis:

kami tertarik untuk memindahkannya ke kontrol WinUI asli

"lulus ke kontrol WinUI asli" secara praktis merupakan kelanjutan/pengulangan dari beberapa kesalahan yang sama yang menyebabkan "kerugian dalam pangsa pasar dan kurangnya pengembangan aplikasi" yang disebutkan di Wikipedia:

"Pada Mei 2016, Microsoft memusnahkan bisnis selulernya, .... Pada 2017, eksekutif Microsoft Joe Belfiore mengungkapkan bahwa Microsoft telah menghentikan pengembangan ponsel Windows baru dan fitur baru untuk Windows 10 Mobile, dengan alasan kerugian dalam pangsa pasar dan kurangnya pengembangan aplikasi."
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

Mengapa DataGrid harus melanjutkan jalan yang sama yang menghancurkan bisnis seluler Microsoft?

@verelpode

WinUI 3 melanjutkan kesalahan manajemen yang sama yang menyebabkan kegagalan UWP dan Windows Phone dan kerugian multi-miliar dolar Microsoft.

Saya tidak bekerja untuk Microsoft tetapi saya ingin tahu mengapa Anda mengatakan WinUI membuat kesalahan manajemen.
Dari apa yang saya lihat, fakta bahwa WinUI adalah open source dan semua orang dapat berkontribusi pada percakapan dan keputusan sebenarnya membantu menentukan apa itu WinUI dan harus mencegah kesalahan terjadi.
Anda menyebutkan bahwa DataGrid berlanjut di jalur yang sama dengan seluler, namun tidak ada tempat di lapangan yang saya lihat menyebutkan seluler. Mungkin Anda dapat menyimpan umpan balik secara langsung tentang apa yang sedang dibahas dalam masalah ini.
Jika Anda merasa ada langkah salah urus dengan WinUI maka mungkin Anda dapat membuat masalah terpisah dengan kekhawatiran Anda, tetapi saya benar-benar tidak berpikir bahwa komentar Anda ada hubungannya dengan kontrol DataGrid.

@verelpode harap simpan umpan balik Anda di sini sesuai topik. Jika Anda memiliki kekhawatiran tentang WinUI atau UWP pada umumnya, silakan mulai topik diskusi baru atau hubungi saya secara langsung (email saya atau DM di twitter). Atau Anda mungkin mempertimbangkan untuk mendiskusikan topik yang sudah ada seperti #717 atau #1531.

Anda berbagi kekhawatiran tentang DataGrid yang ditulis ulang dalam C++, tetapi sebenarnya proposal asli tidak menyebutkan apa pun tentang itu. @anawishnoff mencoba mengumpulkan umpan balik tentang kumpulan fitur DataGrid. Dari segi implementasi, jika paling masuk akal untuk menyimpannya di C#, kami akan melakukannya (dan itu masih bisa dipanggil dari C++ jika kami melakukannya sebagai komponen WinRT).

@jevansaks -- Umpan balik saya sesuai topik, tapi sudah menjadi sifat manusia untuk menembak utusan yang menyampaikan berita buruk. Tanggapan Anda membuat saya sedih dan kecewa. Oke, saya akan berhenti mencoba membantu, karena bantuan saya tidak diinginkan karena terlalu jujur ​​dan langsung dan menyentuh masalah menyakitkan yang terlalu menyakitkan untuk diakui dan dipecahkan (kegagalan besar WinRT menimbulkan terlalu banyak emosi sehingga lebih mudah untuk dihapus). itu dari memori dan melanjutkan rencana WinRT asli yang sama seolah-olah bencana itu tidak pernah terjadi). Saya akan keluar dari diskusi ini dan tidak berpartisipasi lebih jauh dalam pengembangan DataGrid karena terus berbicara jujur ​​dan langsung tentang masalah sebenarnya hanya akan mengganggu orang.

@verelpode Tidak ada yang "menembak utusan yang menyampaikan kabar buruk" di sini. @jevansaks mengundang Anda untuk membuka edisi baru untuk berbagi keprihatinan luas Anda tentang UWP/WinUI/WinRT di repositori ini. Masalah ini sebenarnya hanya tentang DataGrid dan sementara memang salah satu kekhawatiran Anda adalah tentang DataGrid, sebagian besar adalah tentang UWP/WinUI/WinRT secara umum. Saya yakin jika Anda akan melihat diskusi ini lagi, Anda akan melihat bahwa tim WinUI hanya meminta Anda untuk menjaga masalah ini hanya terfokus pada proposal DataGrid dan untuk membuka baru/menggunakan masalah yang sudah ada untuk kekhawatiran Anda yang lebih luas tentang platform.

Kekhawatiran yang Anda sebutkan dapat menjadi dasar untuk diskusi menarik yang melibatkan tim WinUI dan komunitas, tetapi masalah khusus ini tidak cocok untuk diskusi semacam itu.

@anawishnoff
Saya cukup yakin bahwa Microsoft Pivot Viewer Control bukan html. Silakan lihat kembali. Kemampuan untuk memvisualisasikan kumpulan data yang besar menggunakan sesuatu seperti itu adalah sesuatu yang ingin kami lakukan pada waktu-waktu tertentu. Itu tersedia di Silverlight saya pikir. https://www.microsoft.com/silverlight/pivotviewer/default# Ini menggunakan Deep Zoom untuk fungsionalitasnya. Menambahkan kemampuan Deep Zoom ke WinUI 3.0 akan luar biasa! Tidak benar-benar Datagrid, tetapi kontrol Tampilan Data. Ada banyak ide "ditinggalkan" dari hari-hari awal WPF seperti Deep Zoom yang tidak pernah berhasil menjadi kontrol WPF produksi yang akan sangat bagus untuk dihidupkan kembali di WinUI 3.0 seiring waktu. Heck, keluarkan Dr. WPF dari ruang bawah tanah dan buat dia memposting lagi!!! Kami membutuhkan dia kembali. Kita perlu memulai sebuah gerakan. KEMBALI Dr. WPF!!!!! Kemana saja kamu? Dr WinUI!!!

@PaulMontgomerySP sepertinya Anda harus membuka masalah baru untuk membahas kontrol Pivot. Silakan merujuk ke diskusi sebelumnya tentang hal itu dari Windows Community Toolkit di sini: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/770

Pemilihan mengubah peristiwa kebakaran untuk setiap baris yang saya pindahkan dengan keyboard.
Akan lebih baik untuk memiliki acara hanya untuk klik mouse atau ketukan sel, alih-alih hanya acara yang diubah pemilihannya.

Pemilihan mengubah acara yang diaktifkan untuk klik, dan keyboard. Akan sangat bermanfaat untuk mengadakan acara hanya untuk mengklik.

@Going-Gone Saya ingin tahu apa use case untuk itu? Mengapa Anda perlu mengetahui perbedaannya? Juga tidak bisakah Anda menggunakan acara yang disadap?

Satu batasan yang baru saja saya tekan dengan DataGrid UWP Toolkit adalah DataGridTemplateColumn memiliki CellTemplate, tetapi tidak memiliki CellTemplateSelector (dan yang sama tidak ada untuk CellEditingTemplate ). Ini akan menyederhanakan mengadaptasi UI di setiap sel ke data menggunakan pendekatan pemilih, daripada harus melakukan ini dengan tingkat kontrol UI ekstra di bawahnya untuk menanganinya.

Harap juga memungkinkan untuk memilih baris tidak hanya dalam urutan berurutan seperti yang telah saya jelaskan secara rinci di sini:
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

Tanpa urutan tertentu dari hal-hal yang sering diminta oleh klien yang harus didukung oleh grid

1.Kemampuan untuk menyimpan, memuat, dan membuat filter. Misalnya filter ke ekspresi linq, filter ke query SQL, filter ke pohon ekspresi dan sebaliknya. Contoh - https://querybuilder.js.org/demo.html

1. Kemampuan data waktu nyata berkecepatan tinggi, kinerja penting. Kecepatan refresh di bawah 1 md untuk aplikasi perdagangan vs > 1 juta baris memiliki pertimbangan kinerja yang berbeda.
2. Kemampuan untuk menentukan urutan pengurutan, mis. mengurutkan tinggi/rendah, ii. mengurutkan rendah/tinggi dan iii. tidak ada semacam atau saya. urutkan rendah/tinggi, ii. mengurutkan tinggi/rendah dan iii. tidak ada jenis
3. Pemfilteran seperti Excel
4. Kemampuan untuk menerapkan pemformatan css ke sel, pemformatan bersyarat
5. Kemampuan untuk dengan mudah menyimpan/memuat pengaturan kisi, misalnya filter, lebar kolom, penyortiran, dll
6. Menggulir yang berfungsi, misalnya tidak mengatur ulang setelah pembaruan data, lancar.
7. Peristiwa Pengumpulan Data harus memiliki opsi untuk mengaktifkan peristiwa setelah memuat rentang daripada objek individual. Misalnya, saya percaya ObservableCollection memerlukan subkelas untuk mencegah penembakan INotifyPropertyChange untuk setiap objek individu yang ditambahkan.
8. Acara yang lebih baik ketika data dimuat/dimuat, pemuatan data dimulai, pemuatan data, data dimuat terutama jika menggunakan pemuatan asinkron.
9. Kisi sering dikaitkan dengan kontrol lain seperti filter data, pemilihan rentang, filter silang (mis. https://github.com/dc-js/dc.js), bagan, tabel pivot, dll.
10. Penyortiran cerdas yang menangani data alfanumerik, misalnya urutan pengurutan ABC11, ABC12, ABC111, bukan ABC11, ABC111, ABC12
11. Tingkat kisi hierarkis yang tidak terbatas, misalnya https://docs.telerik.com/devtools/wpf/controls/radgridview/hierarchical-gridview/hierachy-overview

Sumber daya yang berguna: - Desain Tabel Data yang Lebih Baik
https://news.ycombinator.com/item?id=21460966
https://uxdesign.cc/design-better-data-tables-4ecc99d23356

Saya tidak akan dapat Mengikat ke Columwidth dari Header secara langsung. Dalam WPF saya harus menggunakan Objek BindingProxy dalam kasus itu.

Pengubahan ukuran dinamis yang nyaman dari baris aktif untuk pengeditan yang lebih mudah.
Kontrol penuh menu konteks dalam mode edit.

Semoga mendukung CellDecorationStyleSelector seperti di Telerik.

Aksesibilitas!
Menyebutkannya sehingga didokumentasikan, tetapi kontrol ini harus dapat diakses sepenuhnya.
Versi toolkit saat ini memiliki beberapa batasan di area ini: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3400 & https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079
Selain itu, meskipun Telerik RadDataGrid memiliki beberapa fitur hebat, tampaknya tidak mendukung aksesibilitas .

Dengan dorongan besar Microsoft untuk D&I, saya terkejut bahwa kebutuhan untuk semua kontrol agar dapat diakses sepenuhnya tidak ditentukan sebagai persyaratan di mana-mana.

Mungkin ini sudah mungkin, dan saya hanya belum tahu bagaimana mencapainya... tapi bagaimana dengan: baris khusus atau gaya sel?

Kemampuan untuk menargetkan baris tertentu, mengubah latar belakang dan warna teks akan sangat bagus.

Dibandingkan dengan DataGrid UWP WCT:
1) Kinerja
2) Lebih banyak tipe Kolom bawaan (saya berasumsi bahwa ini memiliki kinerja yang lebih baik daripada kolom templat)
3) Kemampuan untuk mengaitkan peristiwa mouse per sel, yaitu ketuk, ketuk kanan, dan arahkan, (atau penunjuk ke bawah atau apa pun)
4) Acara keyboard per Sel
5) Jika (3) tidak dapat diterapkan, kami dapat meniru jika kami telah mencapai fungsionalitas pengujian
6) Kinerja

Berapa banyak orang yang akan mengajukan keberatan jika WinUI DataGrid mengabaikan fitur di mana pengguna akhir dapat mengedit nilai sel sebaris/langsung di dalam DataGrid?

Ada yang ingat VB6? VB6 DataGrid mendukung Edit, Hapus, dan AddNew di luar kotak. Tambahkan tersedia sebagai baris kosong yang ditambahkan secara otomatis ke akhir daftar. Lengkapi baris dan baris kosong lainnya muncul.

DataGrid harus memiliki opsi untuk mendukung entri data, meskipun sebagian besar pengembang lebih memilih fitur ini untuk dinonaktifkan secara default.

Dalam porting aplikasi VB6 ke UWP kami harus menulis grid data kami sendiri untuk mendukung add/edit/delete.

Tampaknya sebagian besar yang berkontribusi di sini adalah orang-orang WPF/Xaml, ini bernilai dua sen dari seseorang yang bukan orang xaml.

Saya banyak menggunakan kontrol DataGrid di perangkat lunak saya. Mengedit adalah tempat itu penting! Beberapa poin keinginan/sakit saya adalah:

1. Kemampuan untuk menyesuaikan menu konteks saat dalam mode edit.
2. Performa yang lebih baik dan kontrol yang lebih besar saat mengubah ukuran kolom secara otomatis. Saya ingin pengguna dapat mengontrol ukuran jika perlu tetapi sebagian besar tidak perlu. Saya tidak ingin ukuran kolom terus berubah, tetapi saya ingin mereka entah bagaimana didasarkan pada data tanpa harus mengukur data senilai satu juta baris.
3. Saat mengedit, saya ingin dapat mengklik kontrol/tombol berbeda yang melakukan sesuatu pada (atau dengan) data yang sedang diedit tanpa mengakhiri pengeditan. (Ini akan kurang diperlukan jika #1 diterapkan - meskipun masih berguna.)
4. cara pengecualian saat ini ditangani menggunakan acara DataError masih kasar. (Maaf, saya mengalami kesulitan untuk menjelaskan hal ini secara spesifik, tetapi saya tahu itu membuat saya sakit beberapa kali di masa lalu.)
5. Kemampuan pengguliran otomatis bawaan akan menyenangkan: http://stackoverflow.com/questions/2567809/how-to-autoscroll-a-datagridview-during-drag-and-drop
6. Kemampuan untuk menampilkan "tanda air" yang menunjukkan saat data "kotor" (lihat BetterGrid untuk beberapa peningkatan tambahan yang berguna untuk DataGridView.
7. Kemampuan untuk mengabaikan baris (tanpa kesalahan validasi) saat sel "kunci" yang diperlukan dibiarkan kosong.
8. Kemampuan bawaan untuk tidak menampilkan gambar (bukan X merah) untuk baris yang ditambahkan pengguna. Lihat: https://stackoverflow.com/questions/937919/datagridviewimagecolumn-red-x
9. Izinkan kolom kotak centang untuk segera dikomit saat diubah: https://stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

Kapan alpha diharapkan akan dirilis? Apakah akan terbuka untuk kontribusi? Mencoba membuang kisi data yang sudah ketinggalan zaman dan sangat menantikan ini, terutama fitur virtualisasi.

Maaf untuk memasukkan masukan yang sangat terlambat ke utas ini, tetapi bagi saya itu "baru";)
_diedit setelah mengetahui lebih banyak tentang bagaimana perilaku kontrol_

Dalam bekerja dengan DataGrid untuk membuat antarmuka seperti penjelajah untuk drive cloud, saya menemukan bahwa menentukan baris dan sel yang disadap mungkin sedikit lebih rumit daripada yang "seharusnya" (IMHO)

Dalam desain aplikasi saya, baris mewakili file atau folder (DriveItems). Tampilan detail menunjukkan detail lebih lanjut tentang item tersebut.

Saya ingin membuat kemampuan untuk mengklik item folder, dan membuat antarmuka melompati dan membuat daftar item tersebut, memungkinkan navigasi di seluruh drive.

Misalnya, jika saya mengetuk entri kolom "Induk" item, /drive/root:/Documents/Vital%20Documents sini, antarmuka akan mengatur ulang ke folder itu dan mencantumkan file di sana.

Meskipun seseorang bisa mendapatkan acara yang diklik untuk sel, acara itu tampaknya tidak memiliki konteks untuk penangan untuk menentukan sel yang disadap (baris, ya, tetapi bukan kolom), dan saya tidak yakin bahwa saat ini kontrol akan memungkinkan saya untuk memiliki perilaku yang disadap sel DAN perilaku detail yang terbuka secara otomatis (masih menyelidiki apa yang saya sebut "peretasan" yang memungkinkan itu, tetapi kita harus mengingatkan diri kita sendiri bahwa ketika desainer mulai mengesampingkan fungsi normal kontrol, terutama bukan perilaku yang didokumentasikan, mereka berisiko merusak desain karena perubahan perilaku kontrol.

Semua ini dikatakan, DataGrid tampaknya mendukung skenario saya dengan memiliki acara yang saat ini mengembalikan DriveItem sebagai CurrentItem, juga harus menyertakan CurrentColumn yang akan menjadi seluruh objek DataGridColumn yang diklik di dalam, melalui yang memungkinkan untuk mengekstrak nama kolom. Saya menyadari sekarang bahwa kami memiliki objek CurrentColumn yang dapat kami selidiki dari acara tersebut, jadi, meskipun saya ingin lebih baik sebagai acara, ini harus bekerja.

Selain itu, kontrol yang lebih ketat dari perilaku detail mungkin bahwa detail hanya akan diperluas secara otomatis berdasarkan mengklik satu kolom tertentu, alih-alih meluaskan setiap kali mengklik di mana saja dalam baris.

Mungkin kelas dasar dari objek DataGridColumn dapat memiliki properti ExpandDetails yang dapat disetel ke true secara default untuk setiap kolom, yang berarti kolom tertentu yang diklik menyebabkan baris meluas. Lainnya di mana properti itu palsu tidak akan.

Dalam desain saya, misalnya, kolom pertama adalah jenis item, seperti dalam File atau Folder, atau Gambar atau Foto, Audio, dll. Saya mungkin membayangkan pengaturan kolom itu menjadi satu-satunya yang menyebabkan perilaku perluasan otomatis, dan kemudian klik pada kolom Path dapat menyebabkan perilaku "dapatkan daftar jalur itu" yang saya jelaskan di atas.

Untuk penyortiran, tampaknya secara logis penting untuk menerapkan kontrol yang cukup untuk memungkinkan desainer mendapatkan penyortiran multi-level. Saya belum melakukan penyelidikan untuk menentukan bagaimana kontrol saat ini dapat mendukung ini melalui mengaitkan/mengganti peristiwa dan panggilan balik, tetapi tidak terlihat langsung.

Akhirnya, saya tahu Anda sangat menyadari hal ini, tetapi (bahkan ketika saya meminta lebih banyak fungsionalitas), mari TOLONG hindari mencoba menambahkan sekelompok perilaku kompleks yang dapat diterapkan pengguna sendiri di atas DataGrid. Di antaranya yang tidak akan saya terapkan di DataGrid adalah yang berkaitan dengan penyimpanan eksternal filter atau pengurutan, dll. Saya juga akan menghindari membuat kontrol ini menjadi klon excel.

-terima kasih, kerja bagus!
-e

Grup tetap: saat menelusuri kumpulan data dengan grup besar harus ada konteks tentang grup mana (atau grup, yaitu remah roti) yang sedang dilihat. Ini sepertinya fitur kegunaan penting untuk semua tampilan berbasis daftar hierarkis: tampilan daftar yang dikelompokkan, kisi data, dan tampilan hierarki.

Saya akan membangun kontrol DataGrid baru di atas kontrol WinUI ItemsRepeater baru. Dan kontrol itu mengekspos ItemsSource-nya sebagai Objek:
Object ItemsSource { get; set; };

@RBrid Kembali ke ini ~ 1 tahun kemudian. Saya menyadari bahwa ItemsRepeater, meskipun memiliki objek ItemsSource, sebenarnya tidak memiliki dukungan bawaan untuk antarmuka berikut yang diperlukan untuk bekerja dengan sumber data tervirtualisasi:

• IsupportIncrementalLoading
• InfoRentang Barang
• InfoPemilihan

-Bagaimana dengan mendapatkan MVP di sana sekarang sehingga kita dapat menggunakan Datagrid dari c++.