المزيد من طرق العرض. ألق نظرة على File Explorer وطريقة عرض Icon. يجب أن تكون DataGrid قادرة على إظهار الرموز / العناصر في شبكة مع التجميع ، بالإضافة إلى الصفوف والأعمدة ذات الرؤوس.

أعلم أن هذا قد لا يكون ممكنًا ، أو خارج النطاق - ولكنه جانب من WinUI vs Win32 ليس سهلاً مثل 1: 1 - وقد تحتاج إلى إصدار حديث من File Explorer ، أو Common File Dialogs من هذا النوع من السيطرة. قد يكون هذا هو ذلك التحكم ، وليس عنصر تحكم مخصص داخلي.

قائمة أمنياتي: بالنسبة لي ، تشتمل شبكة بيانات جيدة على جميع الميزات التالية افتراضيًا. أقوم باستعارة بعض لقطات الشاشة من عالم html.

من السهل تصفية الصفحة بأكملها مع عدد الصفوف المفضل.

حدد / إلغاء تحديد الأعمدة المرئية وفرز العمود والنسخ والطباعة

تصدير البيانات إلى تنسيق معين.

إعادة ترتيب العمود عن طريق سحب العمود.

تصفية العمود

رأس ثابت - حيث يظل الرأس في المقدمة حتى عند التمرير

تفاصيل الصف مع نموذج XAML للحصول على التفاصيل.

تجميع الصف

سحب وإسقاط ترتيب الصف

يجب أن تكون الميزات المذكورة أعلاه في رأيي قياسية في جميع خوادم البيانات.

إذا كنت ترغب في إبراز شبكة البيانات في عالم html ، فسأقوم أيضًا بتضمين ما يلي. أجد نفسي عدة مرات أنظر إلى شبكة بيانات ثم استقر على طريقة عرض قائمة لأن شبكة البيانات تفتقر إلى هذه الميزات.

امسح الصف جنبًا إلى جنب لتضمين ميزات مثل التحرير والحذف والإشارة وما إلى ذلك.

تتعامل الميزات المذكورة أعلاه بشكل أساسي مع "عرض البيانات" ، وما لا يزال ينقصه WinUI هو ما أعتقد أنه يجب أن يكون ميزة WinUI أصلية (تحكم) مثل Microsoft Pivot Control. لتكمل البيانات.

لدى MS بالفعل الكود المصدري لهذا وكان عنصر تحكم رائع مطلق في الأيام الماضية.

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

أنت الآن تغطي العرض التقديمي وتصور البيانات التي يجب أن تكون الحد الأدنى لتمييز WinUI عن جميع الميزات الأساسية الموجودة هناك.

والأهم من ذلك أنها تعرض بالفعل قوة "التطبيقات الأصلية" التي يجب أن تتضمن رسومًا متحركة رائعة وعناصر تحكم جذابة بصريًا قوية وتبدو رائعة حقًا.

يمكنني أن أخطو خطوة أخرى إلى الأمام وأقول بعد الميزات المذكورة أعلاه (التصورات) يمكننا تضمين الرسوم المتحركة ثنائية الأبعاد / ثلاثية الأبعاد التي تخلق مفهومًا للعمق في البيانات وستأخذنا إلى طبقة الستراتوسفير المختلفة ، لكن أعتقد أن هذا سيحدث ليوم آخر ؛ ))

تتمثل نقطة البداية الجيدة في النظر إلى شريكك Telerik باستخدام RadDataGrid (UWP Open Source). مع أحد عملائي ، استخدمته وهو يعمل بشكل جيد بالفعل. إنه سريع للغاية ومتعدد الاستخدامات. الشيء الوحيد الصعب هو الكود الخاص بهم ، ولا توجد طريقة لتعديل أي شيء من محركهم دون فهم جيد للهندسة المعمارية.

أتوقع أن تكون DataGrid الجديدة بنفس أداء Telerik.

أنا سعيد جدًا برؤية فريق WinUI يفكر في عنصر تحكم DataGrid.

أهم التحسينات التي أود رؤيتها من عنصر تحكم جديد لاستبدال Toolkit DataGrid:

• القدرة على استرداد DataGridRow بالفهرس
• الأحداث الخاصة بـ DataGridRows أنفسهم. على سبيل المثال ، DoubleTapped و RightTapped.
• التمرير السلس
• التحقق من صحة الإدخال لإعادة تسمية الخلية
• DataGridColumn مصمم خصيصًا لرموز الصفوف
• التخصيص السهل للألوان ، إلخ.

سيكون خيار الحصول على زر تحرير والذي يضع رموزًا قابلة للسحب بجوار كل صف لتحريك الترتيب ميزة مفيدة. سيكون من الرائع أيضًا أن ترى بعض الظلال خلف الصف يتم رفعها وتحريكها (نظرًا لأن العمق هو أحد السمات الرئيسية لطلاقة). قد تكون الأسهم الصغيرة لأعلى ولأسفل جيدة بجوار أيقونة السحب لتحريك الصفوف بسهولة أكبر باستخدام إدخال الماوس. إذا تم نقل صف باستخدام الأسهم ، فستكون الرسوم المتحركة المنزلقة الدقيقة لمسة لطيفة. من خلال الإدخال باللمس ، قد يعمل خيار الاحتفاظ بصف ما وتحريكه دون الحاجة إلى الضغط على زر التحرير بشكل جيد أيضًا. لست متأكدًا مما إذا كان هذا مدعومًا بالفعل ، ولكن يمكنني رؤية مربعات اختيار التحديد كما هو الحال في File Explorer مما يوضح أي من DataGrids يدعم اختيار الصف ويحسن فقط UX بشكل عام. يحتوي تطبيق تذكيرات iOS على بعض هذه الأفكار (الأمثلة في الصورة أدناه). يحتوي تطبيق iOS Stocks أيضًا على نوع مماثل من التعامل مع الصفوف المتحركة. ستعمل معظم هذه الأفكار أيضًا بشكل رائع مع الأعمدة.

NoahFeller هذا النوع من الإجراء يكون أكثر منطقية لعرض القائمة. باستخدام طريقة عرض الشبكة ، لا تقوم بإعادة ترتيب الترتيب ، يجب أن تكون هناك خيارات فرز ولكن المستخدم لا يسحب الأشياء.

*يحرر
بعد التفكير في الأمر أكثر من ذلك بقليل ، أرى كيف يمكن أن يكون هذا الخيار مفيدًا. ومع ذلك ، أنا بالتأكيد لا أعتقد أن هذا يجب أن يكون السلوك الافتراضي.

NoahFeller هذا النوع من الإجراء يكون أكثر منطقية لعرض القائمة. باستخدام طريقة عرض الشبكة ، لا تقوم بإعادة ترتيب الترتيب ، يجب أن تكون هناك خيارات فرز ولكن المستخدم لا يسحب الأشياء.

*يحرر
بعد التفكير في الأمر أكثر من ذلك بقليل ، أرى كيف يمكن أن يكون هذا الخيار مفيدًا. ومع ذلك ، أنا بالتأكيد لا أعتقد أن هذا يجب أن يكون السلوك الافتراضي.

نعم ربما أنت على حق @ ayichenbaum. كنت أتخيل هذه الاقتراحات على أنها القدرة على القيام بفرز مخصص واعتقدت أن السحب قد يكون مفيدًا لذلك. لذلك أوافق ، بالتأكيد ليس افتراضيًا ولكنه قد يكون مفيدًا جدًا كخيار. شكرا على ملاحظاتك!

بساطة WPF datatable لوظيفة datagrid. لقد كنت أقاتل بالفعل خلال الأسبوع الماضي أو نحو ذلك في محاولة للحصول على شبكة بيانات UWP للعمل بالطريقة التي كنت أعمل بها في WPF حيث يمكنني فقط ربط Datagrid بـ Dataview ، ثم ملء Dataview من SQL بـ datatable.default view. ثم عرضت الشبكة جدول البيانات فقط. كان الأمر سهلاً بشكل مذهل ، وقد جعلت UWP هذا الأمر معقدًا بشكل يبعث على السخرية حتى الآن.

اجعلها عبر منصة

أود أن أطلب وضع اختيار خلية واحدة ، أسلوب التفوق.
الهدف النهائي هو وضع السلوك الدقيق مثل WinForms DataGridView.

امتلاك مجموعة متنوعة من خيارات المحاكاة الافتراضية التي يمكن أن تدعم حالات الاستخدام المختلفة (من خيارات المحاكاة الافتراضية للتمرير العادي مثل إعادة التدوير إلى مفاهيم أخرى مثل ترحيل البيانات)
غالبًا (في عناصر تحكم سطح المكتب المماثلة التي تدعم ذلك) تبدأ بعض هذه الخيارات بالفشل عند استخدامها مع قوالب مخصصة للأعمدة ذات البيانات الفريدة. وكلما زاد دعمهم في تلك الحالات ، كان ذلك أفضل.

إذا كان ذلك ممكنًا على الإطلاق ، فيجب مزامنة اقتراح Paging Control # 268 ، وإضافة أي خطافات مطلوبة إلى عنصر تحكم DataGrid.

هذه أخبار جيدة! لقد كنت أنتظر شيئًا رسميًا على واجهة DataGrid لبعض الوقت منذ ظهوره في مجموعة أدوات المجتمع. هذا هو بالفعل عنصر التحكم الأخير المفقود من WinUI 3.0 الذي لا تملك مجموعة أدوات المجتمع بديلًا جيدًا له.

أولاً ، من فضلك ، لا تعيد اختراع العجلة. كبداية أساسية لتطبيق WPF لـ DataGrid (أعلم أنه لا يمكنك استخدام الكود ولكن يرجى استخدام 100٪ من واجهة برمجة التطبيقات) - وليس برنامج Silverlight. كان WPF DataGrid أكثر اكتمالاً من حيث الميزات ولديه عدد أقل من الأخطاء في الاختبار.

عند استخدام مجموعة أدوات المجتمع DataGrid ، طلبت أيضًا إضافات واجهة برمجة التطبيقات التالية التي ظهرت في مناقشة حالات الاستخدام المختلفة

• RowPressed: كما تمت مناقشته أعلاه. يشير إلى أنه تم الضغط على أحد الصفوف حتى تحدث مزيد من المعالجة أو قائمة السياق.
• RowDoublePressed: مثل RowPressed ، فقط انقر نقرًا مزدوجًا فوق الإصدار.
• ColumnHeaderPressed: يحدث عند الضغط على رأس العمود. يجب أن تأخذ الأولوية على أي تحديثات داخلية لاتجاه الفرز. سيسمح هذا بقوائم التصفية المخصصة أو خيارات النقر بزر الماوس الأيمن لتشغيل / إيقاف تشغيل الأعمدة.
• ColumnHeaderDoublePressed: مثل ColumnHeaderPressed ، فقط انقر نقرا مزدوجا الإصدار.
• ColumnHeaderWidthChanged: يحدث عندما يقوم المستخدم بتغيير حجم عرض رأس العمود. سيسمح هذا بحفظ هذه المعلومات بطريقة نظيفة. هذا مطلوب بشكل شائع عند استعادة حالة واجهة المستخدم.

ما زلت أيضًا أعاني من الكثير من المشكلات مع المجتمع الذي قام DataGrid بإعادة تعيين موضع التمرير إلى الأعلى بعد تغيير ItemsSource. هذا يحتاج إلى إصلاح حتى يتم الحفاظ على الإزاحة كما في WPF ؛ ومع ذلك ، نحتاج أيضًا إلى أن نكون قادرين على التحكم في هذا ولهذا السبب أقترح أيضًا واجهة برمجة التطبيقات التالية:

• FirstRowInView (): إرجاع الصف الأول المرئي في DataGrid المستخدمة لاستعادة الحالة.
• VerticalOffset: إحضار / تعيين مرة أخرى لاستعادة حالة شريط التمرير
• HorizontalOffset: Get / Set لاستعادة حالة شريط التمرير

ساعد RBrid أيضًا في إجراء بعض التحليلات هنا :

أحداث جديدة مقترحة ، وبعض التحسينات على الأحداث الموجودة مسبقًا:

| حدث | التعليقات |
| : --- | : --- |
| ContextRequestedForColumnHeader | لدعم إظهار قائمة السياق (أو قائمة منبثقة أخرى) عند النقر بزر الماوس الأيمن فوق رأس العمود. مثل Windows.UI.Xaml.UIElement.ContextRequested لكن لرؤوس الأعمدة بدلاً من DataGrid بالكامل. |
| ContextCanceledForColumnHeader | مثل Windows.UI.Xaml.UIElement.ContextCanceled لكن لرؤوس الأعمدة بدلاً من DataGrid بالكامل. |
| ContextRequestedForRow | لدعم إظهار قائمة السياق (أو قائمة منبثقة أخرى) عند النقر بزر الماوس الأيمن فوق أحد الصفوف. مثل Windows.UI.Xaml.UIElement.ContextRequested لكن للصفوف بدلاً من DataGrid بالكامل. |
| ContextCanceledForRow | مثل Windows.UI.Xaml.UIElement.ContextCanceled لكن للصفوف بدلاً من DataGrid بالكامل. |
| RowTapped | لاحظ أيضًا حالة النقر على صف تم تحديده بالفعل. |
| RowDoubleTapped | مثل Windows.UI.Xaml.UIElement.DoubleTapped لكن للصفوف بدلاً من DataGrid بالكامل. |
| RowRightTapped | مثل Windows.UI.Xaml.UIElement.RightTapped لكن للصفوف بدلاً من DataGrid بالكامل. راجع أيضًا ContextRequestedForRow . |
| PointerPressedInRow | مثل Windows.UI.Xaml.UIElement.PointerPressed لكن للصفوف بدلاً من DataGrid بالكامل. |
| PointerReleasedInRow | مثل Windows.UI.Xaml.UIElement.PointerReleased لكن للصفوف بدلاً من DataGrid بالكامل. |
| PointerMovedInRow | مثل Windows.UI.Xaml.UIElement.PointerMoved لكن للصفوف بدلاً من DataGrid بالكامل. من المحتمل أن يتم تشغيل PointerMovedInRow فقط أثناء التقاط المؤشر. |
| ColumnHeaderTapped | لاحظ أيضًا حالة النقر فوق رأس العمود المحدد بالفعل. |
| ColumnHeaderDoubleTapped | مثل Windows.UI.Xaml.UIElement.DoubleTapped لكن لرؤوس الأعمدة بدلاً من DataGrid بالكامل. |
| ColumnHeaderRightTapped | مثل Windows.UI.Xaml.UIElement.RightTapped لكن لرؤوس الأعمدة بدلاً من DataGrid بالكامل. راجع أيضًا ContextRequestedForColumnHeader . |
| ColumnHeaderWidthChanged | بدلاً من ذلك ، يمكن تسميته ColumnHeaderResized . في الحدث args ، قم بتضمين خاصية منطقية تحدد ما إذا تم تغييرها بواسطة المستخدم مقابل تغييرها برمجيًا. من الواضح أن وسائط الحدث يجب أن تحدد أيضًا رأس العمود الذي تم تغيير حجمه / تغييره. |
| SortOrderChanged | يجب تشغيله عندما تتغير قائمة رؤوس الأعمدة المختارة. يتم تشغيله أيضًا عند تبديل أي من الأعمدة المحددة بين ترتيب تصاعدي مقابل تنازلي. في الحدث args ، قم بتضمين خاصية منطقية تحدد ما إذا تم تغيير ترتيب الفرز بواسطة المستخدم مقابل تغييره برمجيًا. راجع أيضًا الحدث الموجود مسبقًا Sorting . أعتقد أنه سيتم تشغيل حدث جديد SortOrderChanged بعد تشغيل الحدث Sorting ، إذا لم يتم إلغاء الفرز. |
| Sorting | موجودة بالفعل ولكن ضع في اعتبارك إضافة خاصية منطقية قابلة للتعيين في حالة args التي تسمح بإلغاء طلب الفرز. على سبيل المثال ، قد يكون الفرز غير صالح أو لا يمكن تنفيذه ويحتاج إلى إلغاؤه. أضف أيضًا خاصية منطقية لتحديد ما إذا كان الفرز مطلوبًا من قبل المستخدم أم برمجيًا. |
| ColumnSortDirectionChanged | يمكن إنشاء هذا الحدث ولكن قد يكون غير ضروري إذا تم إنشاء الحدث المذكور أعلاه SortOrderChanged ، إذا تم أيضًا تشغيل SortOrderChanged عندما يتغير اتجاه الفرز. |
| ColumnDisplayIndexChanged | موجودة بالفعل ولكن يُرجى التفكير في إضافة خاصية منطقية (في الحدث args) تحدد ما إذا كان المستخدم قد تم تغييرها مقابل تغييرها برمجيًا. يرجى أيضًا توثيق سبب ضرورة وجود كلا الحدثين ColumnDisplayIndexChanged و ColumnReordered . بدلاً من ذلك ، قم بإزالة أحد هذه الأحداث. |
| ColumnReordered | موجودة بالفعل ولكن يُرجى التفكير في إضافة خاصية منطقية تحدد ما إذا تم تغييرها بواسطة المستخدم مقابل تغييرها برمجيًا. |
| SelectionChanged | موجودة بالفعل ولكن يُرجى التفكير في إضافة خاصية منطقية (في الحدث args) تحدد ما إذا كان المستخدم قد تم تغييرها مقابل تغييرها برمجيًا. |
| CopyingRowClipboardContent | موجودة بالفعل ولكن يُرجى مراعاة إضافة خاصية منطقية إلى الحدث args التي تحدد ما إذا كانت العملية ستُقطع بدلاً من نسخها. بدلاً من ذلك ، قم بعمل حدث منفصل للقطع. |
| CuttingRowClipboardContent | غير موجود. ضع في اعتبارك إنشاء حدث يتم تشغيله عندما يحاول المستخدم قطع الصفوف (عبر مفتاح الاختصار control-X أو قائمة السياق أو غير ذلك). بدلاً من ذلك ، قم بعمل الخاصية المنطقية المذكورة أعلاه والتي من شأنها أن تسمح بتشغيل CopyingRowClipboardContent لكل من عمليات النسخ والقص |
| PastingRowClipboardContent | غير موجود. ضع في اعتبارك إنشاء حدث يتم تشغيله عندما يحاول المستخدم اللصق (عبر مفتاح الاختصار control-V أو قائمة السياق أو غير ذلك). |

أعتقد أن الميزة الأكثر أهمية بالنسبة لي هي القدرة على التعامل بسهولة مع مليون صف أو أكثر ، دون الحاجة إلى تحميل ملايين الصفوف في الذاكرة. واجهة ISupportIncrementalLoading ليست جيدة بما يكفي لهذا ، لأن شريط التمرير يعكس فقط عدد الصفوف التي قمت بتحميلها حتى الآن (ليس العدد الإجمالي) ، وللحصول على الصف 1 مليون ، يجب عليك الاستمرار في التمرير حتى النهاية وأكثر وأكثر وتحميل المزيد والمزيد من البيانات ، وآمل ألا تنفد الذاكرة. ولكن إذا علمت أن لدي مليون سجل بيانات ، دعني أخبر شبكة البيانات بذلك ، وإذا قمت بالتمرير سريعًا أو قفزت إلى النهاية ، فيمكن أن يُطلب مني تقديم الصفوف القليلة الأخيرة فقط.
فكر في التمرير عبر قائمة الصفوف في قاعدة البيانات التي سأقوم بسحبها ديناميكيًا.

أعتقد أن الميزة الأكثر أهمية بالنسبة لي هي القدرة على التعامل بسهولة مع مليون صف أو أكثر ، دون الحاجة إلى تحميل ملايين الصفوف في الذاكرة. واجهة ISupportIncrementalLoading ليست جيدة بما يكفي لهذا ، لأن شريط التمرير يعكس فقط عدد الصفوف التي قمت بتحميلها حتى الآن (ليس العدد الإجمالي) ، وللحصول على الصف 1 مليون ، يجب عليك الاستمرار في التمرير حتى النهاية وأكثر وأكثر وتحميل المزيد والمزيد من البيانات ، وآمل ألا تنفد الذاكرة. ولكن إذا علمت أن لدي مليون سجل بيانات ، دعني أخبر شبكة البيانات بذلك ، وإذا قمت بالتمرير سريعًا أو قفزت إلى النهاية ، فيمكن أن يُطلب مني تقديم الصفوف القليلة الأخيرة فقط.
فكر في التمرير عبر قائمة الصفوف في قاعدة البيانات التي سأقوم بسحبها ديناميكيًا.

هذه.

تعني كلمة "حديث" أنها خفيفة الوزن وسريعة ، وعادة ما تدور تطبيقات المؤسسات حول الفرز عبر الكثير من البيانات الداخلية للعثور على السجلات المناسبة واستكشافها. الترحيل ، والفرز ، والتحميل المتزايد غير المتزامن ، والتمرير اللانهائي - كل هذه عناصر أساسية لتطبيقات سطح المكتب التي تستفيد من شبكات البيانات.

يجب أن تنتج MS تطبيقًا نموذجيًا يسلط الضوء على هذه الميزات في الشبكة الجديدة ويجمع التعليقات من مطوري المؤسسات بمرور الوقت لتحسين هذه التجارب. اجعله ينفد من مجموعة بيانات كبيرة مثل المستوردين العالميين لإثبات فعاليته.

تضمين التغريدة

أعتقد أن الميزة الأكثر أهمية بالنسبة لي هي القدرة على التعامل بسهولة مع مليون صف أو أكثر ، دون الحاجة إلى تحميل ملايين الصفوف في الذاكرة.

اتمنى ذلك ايضا من أجل المساعدة في دعم مليون صف (وأعني المساعدة ، وليس بالضرورة الحل الكامل) ، أقترح أن تجعل DataGrid أسلوب ربط البيانات الحالي الخاص بها اختياريًا. أعتقد أن ربط البيانات حاليًا إلزامي (ما لم تكن معرفتي محدثة بأحدث إصدار من DataGrid). يجب ألا تتطلب DataGrid استخدام Windows.UI.Xaml.Data.Binding باعتبارها الطريقة الوحيدة المدعومة لاسترداد القيم لكل خلية / عمود في كل صف مرئي.

أقترح أن تسمح DataGrid للتطبيقات بإعطاء DataGrid مفوضًا أو مثيل واجهة تستدعيه DataGrid كلما احتاجت DataGrid إلى استرداد قيمة خلية / عمود في صف (بدلاً من ذلك ، يمكن لهذا المفوض أو الواجهة استرداد الصف بالكامل - جميع قيم العمود لصف محدد).

من الناحية المثالية (إن أمكن) ، ستسمح DataGrid لهذا المفوض أو الواجهة بالعمل بشكل غير متزامن . على سبيل المثال ، قد يقوم المفوض أو الواجهة بإرجاع Task أو IAsyncOperation<TResult> بدلاً من إرجاع القيمة المطلوبة فورًا.

بدلاً من ذلك ، يكون الدعم غير المتزامن ممكنًا أيضًا بدون Task و IAsyncOperation<TResult> ، إذا كانت DataGrid تعمل بشكل مشابه للإجراء التالي:

1. قررت DataGrid أنها بحاجة إلى استرداد قيمة الخلية / العمود 5 في معرف الصف 50001. وبدلاً من ذلك ، قررت DataGrid استرداد كافة قيم العمود لمعرف الصف 50001.
2. تستدعي DataGrid المفوض أو مثيل الواجهة أو معالج الأحداث الذي يخطر التطبيق بأن DataGrid قد طلبت تحميل قيم البيانات للعمود / الصف المحدد أو الصف بأكمله.
3. يسترد التطبيق بيانات الصف المطلوبة بشكل غير متزامن. على سبيل المثال ، يمكنه تنفيذ استعلام قاعدة بيانات SQL بشكل غير متزامن.
4. ينتهي التطبيق من استرداد بيانات الصف المطلوبة. يستدعي التطبيق طريقة في DataGrid تعطي بيانات الصف إلى DataGrid.
5. يعرض DataGrid بيانات الصف ، أو يفعل أي شيء آخر يلزم القيام به مع البيانات.

أولا ، واو !! شكرا جزيلا لكل من ساهم بأفكارهم. لدي بعض الردود المحددة أدناه ، ولكن بشكل عام أردت أن أقول إنني أحفظ الكثير من هذه التعليقات وأستمتع حقًا بسماع كيف يمكننا بناء DataGrid الحديثة الرائعة. استمر في القدوم!

Pinox شكرًا جزيلاً على الرد التفصيلي ولقطات الشاشة. قائمة أمنياتك رائعة (خاصة تلك الرسوم المتحركة الرائعة!) - أوافق على أن تلك الميزات الموجودة في html هي نقطة إلهام جيدة وبسيطة لكنها ستحسن نوعية الحياة بشكل كبير. بالتأكيد سيتم حفظ هذا التعليق للرجوع إليه في المستقبل!

verelpode ، robloo ، @ duke7553 نعم للأحداث الخاصة بـ DataGrid! شكرا لكم جميعا على التفاصيل التي وضعتها في هذه. نظرًا لأننا نصمم من أجل اللمس أولاً ولمجموعة متنوعة من المدخلات ، يجب بالتأكيد تنفيذ مثل هذه الأحداث!

dotMorten ، jkewley ، verelpode Performance يعد بالتأكيد أحد الدوافع الرئيسية لهذا المشروع وأحد التحسينات الرئيسية التي نريد تنفيذها ، من خلال قصة افتراضية للبيانات الجديدة واستخدام عناصر تحكم حديثة مثل ItemsRepeater. سنبقيكم جميعًا على اطلاع بمجرد توفر المزيد من التفاصيل - ولكن شكرًا مرة أخرى على هذه التفاصيل التي اقترحتها.

@ Laz3rPanth3r ، robloo ، keeganatorr نسمعك بصوت عالٍ وواضح بشأن الإعجاب بـ DataGrids التي تنتمي إلى WPF وأطر عمل واجهة المستخدم الأخرى - نحن بالتأكيد نأخذ ذلك في الاعتبار في هذا التحديث!

شكرًا للعمل الرائع على DataGrid وطلب التعليقات! فيما يلي بعض التحسينات الأخرى المقترحة.

بحاجة إلى المزيد من الفئات الفرعية من DataGridColumn

الفئات الفرعية الحالية / تطبيقات DataGridColumn غير كافية. أقترح إنشاء الفئات الفرعية الجديدة التالية DataGridColumn :

| الفئة الفرعية المقترحة | الوصف |
| : --- | : --- |
| DataGridIconColumn | من المتطلبات الشائعة عرض رمز في كل صف من القائمة ، لذلك أقترح إنشاء فئة فرعية DataGridColumn باسم DataGridIconColumn والتي تكتب قيمة الخلية المستردة إلى Windows.UI.Xaml.Controls.IconSource وتعرض IconSource مثيل (يتم عرض مثيل IconSource في كل خلية). |
| DataGridImageColumn | يجب أن يعمل DataGridImageColumn بنفس طريقة DataGridIconColumn المقترحة باستثناء أنه يجب أن يعرض Windows.UI.Xaml.Media.ImageSource بدلاً من Windows.UI.Xaml.Controls.IconSource . |
| DataGridDateTimeColumn | يعرض التاريخ و / أو الوقت ، حسب الإعدادات. يكتب قيمة الخلية إلى System.DateTimeOffset أو System.DateTime (كلاهما مدعوم) ويحولها إلى نص ليتم عرضه في الخلية. يجب التحكم في التحويل إلى نص من خلال تنسيق الإعدادات / الخصائص في فئة DataGridDateTimeColumn . من الواضح أنه يجب أيضًا دعم الفرز حسب التاريخ / الوقت. |
| داتاجريدتيميسبانكولومن | يكتب قيمة الخلية إلى System.TimeSpan ويحولها إلى نص ليتم عرضه في الخلية. يجب التحكم في التحويل إلى نص من خلال تنسيق الإعدادات / الخصائص في فئة DataGridTimeSpanColumn . من الواضح أن الفرز يجب أن يكون مدعومًا أيضًا ، ويجب أن يفرز مثيلات TimeSpan وليس النص المعروض. |
| DataGridDataSizeColumn | نسخ قيمة الخلية إلى System.Int64 أو UInt64 أو Int32 أو UInt32 (جميعها مدعومة) وتحويلها إلى حجم بالبايت (كنص ) ليتم عرضها. على سبيل المثال ، سيتم عرض 1572864 كـ "1.5 ميغا بايت" لأن 1572864/1024/1024 = 1.5. يجب التحكم في التحويل إلى نص من خلال الإعدادات / الخصائص في فئة DataGridDataSizeColumn . يجب إجراء الفرز باستخدام قيمة عدد صحيح أصلي وليس النص المعروض. |
| DataGridCustomColumn | يجب أن يعمل هذا على غرار DataGridTemplateColumn الموجود مسبقًا باستثناء Windows.UI.Xaml.DataTemplate . يجب أن يستدعي مفوض / رد اتصال أو حدث لإنشاء و / أو تحديث الشجرة الفرعية لعنصر واجهة المستخدم الرسومية المعروضة. |
| DataGridTextColumn | موجود بالفعل ولكن يرجى التفكير في إضافة خصائص أو أحداث تسمح للتطبيقات بتجاوز تحويل الكائن إلى نص ووظيفة المقارنة للفرز. سأشرح هذا بمزيد من التفصيل لاحقًا في رسالتي. |

DataGridCustomColumn هذا النحو:

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

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

عندما يتم تشغيل الحدث DataGridCustomColumn.DisplayingCell ، يجب على معالج الحدث إنشاء أو تحديث الشجرة الفرعية UIElement به لعرض DataGridDisplayingCellEventArgs.CellValue ، وتعيين الخاصية DataGridDisplayingCellEventArgs.CellUIElement لذلك شجرة فرعية UIElement ، ثم تعرضها DataGrid.

في المرة التالية التي يقوم فيها DataGrid بتشغيل هذا الحدث ، يجب على DataGrid تعيين الخاصية DataGridDisplayingCellEventArgs.CellUIElement إلى مثيل UIElement الذي تم إنشاؤه مسبقًا بواسطة معالج الحدث ، للسماح لمعالج الحدث بإعادة الاستخدام / إعادة التدوير والتحديث نفس الشجرة الفرعية UIElement (من المحتمل أن تكون ذات قيمة مختلفة في DataGridDisplayingCellEventArgs.CellValue ). يُسمح لمعالج الحدث إما بإعادة تدوير نفس الشجرة الفرعية UIElement أو تعيين الخاصية DataGridDisplayingCellEventArgs.CellUIElement إلى الشجرة الفرعية UIElement المنشأة حديثًا.

ضع في اعتبارك أيضًا إمكانية إنشاء حدث DisplayingCell مباشرةً في الفئة الأساسية DataGridColumn ، بدلاً من جعل الفئة الفرعية DataGridCustomColumn . وبالتالي فإن الحدث DataGridColumn.DisplayingCell قد يسمح بتخصيص أو تجاوز UIElement الذي تم إنشاؤه لكل فئة فرعية من DataGridColumn .

في DataGridTextColumn الموجود مسبقًا ، يتم حاليًا تحويل قيمة الخلية / الكائن إلى نص للعرض عن طريق استدعاء System.Object.ToString . يرجى التفكير في إجراء تفويض / رد اتصال أو حدث يسمح للتطبيقات بتجاوز تحويل القيمة إلى نص. يُرجى أيضًا مراعاة خاصية تسمح للتطبيقات بتحديد مثيل System.Collections.IComparer لتجاوز سلوك الفرز.

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

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

بدلاً من ذلك ، بدلاً من جعل الخاصية Comparer في DataGridTextColumn ، ضع في اعتبارك إمكانية جعل الخاصية Comparer مباشرة في الفئة الأساسية DataGridColumn ، من أجل السماح للتحكم في سلوك الفرز لجميع الفئات الفرعية من DataGridColumn .

وبالمثل ، يمكن أيضًا إنشاء خاصية CellValueToToStringConverter في الفئة الأساسية DataGridColumn لأنه سيكون من المفيد أن يكون لديك القدرة على تحويل أي قيمة خلية إلى نص بغض النظر عن الفئة الفرعية DataGridColumn يستخدم. على سبيل المثال ، عند نسخ صف إلى الحافظة ، يمكن تحويل كل قيمة خلية إلى نص. (يمكن وضع كل من التنسيقات النصية وغير النصية في نفس الوقت في الحافظة - وعادةً ما تقوم التطبيقات بذلك من أجل زيادة التوافق مع التطبيقات الأخرى.)

إعادة الفرز عند تحديد DataGridIconColumn أو DataGridImageColumn : من الواضح أن DataGrid لا يمكنها فرز الرموز أو الصور ، لذلك يمكنها استخدام أي من هذه الحلول:

• ما عليك سوى عدم السماح للمستخدمين بتحديد (فرز حسب) رأس عمود من النوع DataGridIconColumn أو DataGridImageColumn .
• أنشئ خاصية AlternativeText في فئة IconSource . عندما يفرز DataGridIconColumn الصفوف ، أو عندما يحول الخلية إلى نص للحافظة / النسخ ، فإنه سيستخدم الخاصية AlternativeText .
• قم بإنشاء خاصية Comparer قابلة للتعيين (من النوع System.Collections.IComparer ) إما في DataGridColumn أو DataGridIconColumn .

الوصول إلى الصفوف / العناصر المحددة

يُرجى مراعاة تحسين وظيفة الحصول على الصفوف / العناصر المحددة وتعيينها ، لأن الوظيفة الحالية غير كافية. هذه الخصائص موجودة حاليًا:

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

لقد وجدت أنه في بعض الأحيان كنت بحاجة إلى الوصول إلى مثيلات DataGridRow للصفوف المحددة ، لذلك آمل أن تتم إضافة الخصائص التالية إلى DataGrid:

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

بدلاً من ذلك ، إذا كان تنفيذ ما سبق صعبًا للغاية ، فإن الاختلاف التالي للقراءة فقط يكون أقل قوة ولكنه لا يزال مفيدًا:

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

إذا كان من الممكن إعادة استخدام مثيلات DataGridRow ، فيجب أن تحذر وثائق الخصائص المذكورة أعلاه من أن المعلومات التي تم إرجاعها صالحة مؤقتًا فقط ، وبالتالي يجب قراءتها / استخدامها على الفور وعدم الاحتفاظ بها لفترة زمنية أطول.

أيضًا ، تتيح خاصية SelectedIndex الموجودة مسبقًا الوصول إلى فهرس واحد محدد ، ولكن ماذا عن الوصول إلى جميع العناصر المحددة؟ لذلك أقترح إنشاء خاصية SelectedIndexes :

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

شخصيًا أجد اسم "SelectedIndex" محيرًا لأن DataGrid يُستخدم غالبًا مع قاعدة بيانات ومصطلح "index" له معنى مختلف تمامًا في قاعدة البيانات ، لذلك أقترح إعادة تسمية الخصائص على النحو التالي ، لكنني أتوقع أن اقتراح التسمية الخاص بي سيتم رفضه:

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

أرغب أيضًا في القدرة على تمرير DataGridRow و / أو DataGridColumn المحدد في العرض. هذه الطريقة موجودة حاليًا:

public void ScrollIntoView(object item, DataGridColumn column);

أقترح استبدال طريقة ScrollIntoView الموجودة مسبقًا بالطريقتين التاليتين:

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

احصل على ترتيب الفرز وعيّنه بضربة واحدة

عند فتح التطبيقات وإغلاقها ، فإنها تحتاج إلى القدرة على حفظ واستعادة تكوين المستخدم النهائي لـ DataGrid ، بما في ذلك ترتيب الفرز والإعدادات الأخرى. ترتيب الفرز يعني قائمة الأعمدة التي تم تحديدها من قبل المستخدم. لاحظ أن هذه قائمة وليست عمودًا واحدًا. يمكن تحديد أكثر من عمود واحد في وقت واحد ، مما يعني العمود الأساسي للفرز والعمود الثانوي للفرز والعمود الثالث للفرز ، إلخ.

لذلك يمكن إنشاء الخاصية التالية في DataGrid ، ولكن في الواقع هذه ليست سوى الفكرة الأولى وليست مثالية:

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

ما ورد أعلاه غير مثالي لأنه لا يدعم حفظ واستعادة DataGridColumn.SortDirection لكل عمود في ضربة واحدة . أدرك أن التطبيقات يمكنها القيام بذلك بخطوات متعددة:

1. قم بتعيين خاصية SortOrder المقترحة إلى قائمة الأعمدة المحددة.
2. قم بتعيين الخاصية SortDirection لكل عمود من الأعمدة المحددة (كرر هذه الخطوة لكل عمود).

لا يزال هذا يمثل مشكلة لأنه يضرب عدة مرات ، مما يعني أنه يتسبب في العديد من المنتجعات التي تستغرق وقتًا طويلاً في DataGrid. قد يلاحظ المستخدمون النهائيون ويعانون من تأخير كبير في DataGrid التي تحتوي على عدد كبير من الصفوف ، عندما يتم اللجوء إلى DataGrid عدة مرات دون داع. للتخلص من هذه المشكلة ، أقترح الحل التالي الذي يسمح للتطبيقات باستعادة ترتيب الفرز الكامل بضربة واحدة ولا يتسبب في أكثر من منتجع واحد.

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

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

ملاحظة لقد كتبت IReadOnlyList<DataGridColumnAndDirection> وليس IList<DataGridColumnAndDirection> عمدًا لأن التطبيقات لا يجب أن تكون قادرة على تعديل القائمة التي يتم إرجاعها بواسطة الخاصية SortOrder . بدلاً من تعديل القائمة ، يجب على التطبيقات تعيين الخاصية SortOrder إلى قائمة ستقوم DataGrid بنسخها واستخدامها لاستبدال قائمة ترتيب الفرز بالكامل. وبالتالي ستعمل في ضربة واحدة وتتجنب العديد من المنتجعات باهظة الثمن.

عندما يتم تعيين DataGrid.SortOrder إلى قائمة جديدة ، ستقوم DataGrid أيضًا بتعيين خاصية DataGridColumn.SortDirection المقابلة في كل عمود في قائمة SortOrder ، ولكن دون التسبب في عدة منتجعات. وبالتالي فإن DataGrid.SortOrder[i].SortDirection يعادل DataGridColumn.SortDirection .

احصل على ترتيب العمود المعروض وضبطه بضربة واحدة

عند فتح التطبيقات وإغلاقها ، فإنها تحتاج إلى القدرة على حفظ واستعادة ترتيب المستخدم النهائي للأعمدة ، ويفضل أن يكون ذلك بضربة واحدة. أعلم أن الخاصية الموجودة مسبقًا DataGridColumn.DisplayIndex قابلة للتعيين ، لذلك من الناحية النظرية يمكن للتطبيقات استعادة تكوين المستخدم النهائي من خلال التكرار عبر جميع الأعمدة في DataGrid.Columns وتعيين DisplayIndex لكل منها ، ولكن قد يتسبب هذا في حدوث أخطاء. على سبيل المثال ، قد يفشل DisplayIndex أو يتصرف بطريقة غير متوقعة عندما يحتاج التطبيق إلى تعيين DisplayIndex مؤقتًا لعمود واحد إلى نفس DisplayIndex لعمود آخر. أيضًا ، إذا لم يتم إجراؤها بضربة واحدة ، فقد تؤدي إلى عمليات إعادة سحب متعددة و / أو عمليات إعادة حساب باهظة الثمن.

لذلك أقترح إنشاء خاصية ColumnDisplayOrder في DataGrid:

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

نفس ما ذكرته سابقًا مقابل SortOrder ، ColumnDisplayOrder عمدًا IReadOnlyList<DataGridColumn> وليس IList<DataGridColumn> لأنه يجب أن يعمل في ضربة واحدة.
عندما يتم تعيين DataGrid.ColumnDisplayOrder إلى قائمة جديدة ، ستقوم DataGrid بتحديث DataGridColumn.DisplayIndex لكل عمود للمطابقة.

السماح للمستخدمين بإخفاء / إظهار الأعمدة

بما يتوافق مع الخصائص الموجودة مسبقًا DataGridColumn.CanUserReorder وما إلى ذلك ، أقترح إنشاء خاصية CanUserChangeVisibility في DataGridColumn . عندما يكون DataGridColumn.CanUserChangeVisibility صحيحًا ، سيتمكن المستخدم النهائي من إحداث تغييرات في الخاصية DataGridColumn.Visibility .

دعم عناصر واجهة المستخدم الرسومية التي يتم إنشاؤها ديناميكيًا في وقت التشغيل

اسمح بإنشاء واجهة المستخدم الرسومية لتفاصيل الصف دون الحاجة إلى استخدام DataGrid.RowDetailsTemplate ( Windows.UI.Xaml.DataTemplate ). من أجل تحقيق ذلك ، يجب وضع بعض الأفكار في واجهة برمجة التطبيقات ، ولكن هذه هي فكرتي الأولى حول كيفية القيام بذلك: ربما تفعل ذلك عبر الحدث الموجود مسبقًا DataGrid.LoadingRow عن طريق تغيير الخاصية DataGridRowDetailsEventArgs.DetailsElement لتكون قابلة للتعيين بحيث يمكن لمعالج الحدث إنشاء (أو تحديث) UIElement بنفسه ومنحه إلى DataGrid عن طريق تعيين خاصية DetailsElement .

السبب الذي يجعل الاستخدام الإلزامي لـ Windows.UI.Xaml.DataTemplate يمثل مشكلة: على الرغم من أن القوالب هي ميزة جيدة ، إلا أن مفهوم القالب يتوقع مقتطف / مستند XAML غير متغير تم كتابته مسبقًا بواسطة المطور. وبالتالي فإن القوالب تمثل مشكلة عندما يحتاج التطبيق إلى إنشاء واجهة المستخدم الرسومية ديناميكيًا في وقت التشغيل. وبالتالي أتمنى البدائل المذكورة أعلاه بـ DataTemplate .

سحب وإفلات الصفوف ، للداخل وللخارج

أقترح جعل القدرة على تمكين سحب وإفلات الصفوف بشكل اختياري. ستقوم DataGrid بتنفيذ السحب وليس الإفلات. عند حدوث الإفلات ، يقوم DataGrid بتشغيل حدث ويستجيب التطبيق للحدث من أجل تنفيذ الإجراء المطلوب عند إسقاط الصف خارج DataGrid.

أيضًا القدرة على تمكين السحب والإفلات الوارد للصفوف أو العناصر / الكائنات اختياريًا. ستقبل DataGrid عمليات السحب والإفلات الواردة ولكنها لا تنفذ عملية الإفلات. ستطلق DataGrid حدثًا عند إسقاط الصف / العنصر / الكائن ، ويستجيب التطبيق للحدث من أجل تنفيذ الإجراء المطلوب عند إسقاط الصف داخل DataGrid.

خلفيات الخلايا الفردية

لدينا طلب ميزة من عميل يريد تعديل الخلايا الفردية (عن طريق تغيير لون / فرشاة خلفية الخلية) في أوقات معينة (مثل عندما يكتشف تطبيقنا تغييرات أو قيمًا مهمة أو قيمًا خطيرة تتجاوز حدود الأمان وما إلى ذلك).

وبالتالي يمكنني اقتراح خاصية DataGridCell.Background (من النوع Brush ) ، لكنني أعتقد أن طريقة القيام بذلك ربما تكون معيبة لأن DataGrid تعيد تدوير مثيلات DataGridCell ، أليس كذلك؟ لذا أعتقد أن رفع مستوى الخلايا الفردية عن طريق تعيين خاصية DataGridCell.Background سيكون حلاً غير موثوق به.

قد تكون أفضل طريقة عبر الحدث DataGridColumn.DisplayingCell الذي اقترحته في رسالتي السابقة. يمكن لمعالج الحدث تعيين خاصية CellBackgroundBrush في DataGridDisplayingCellEventArgs .

استرجاع DataGrid الخفي للبيانات (قيم الخلية)

أعلم أن أصوات "غبية" سيئة للغاية ، لكن في الواقع سأحبها إذا كانت DataGrid غبية في مجال استرجاع البيانات (استرجاع قيم الخلايا التي سيتم عرضها بواسطة DataGrid).

تحاول DataGrid حاليًا إجراء استرداد البيانات بطريقة تلقائية مريحة عبر ملكيتها DataGrid.ItemsSource بالإضافة إلى تقنيات ربط البيانات (الخاصية DataGridBoundColumn.Binding ) ، وواجهات مثل System.ComponentModel.INotifyPropertyChanged .

نعم ، يعد ربط البيانات ميزة ملائمة ، لكنني في الواقع أفضل أن يكون لدي DataGrid تفعل _ليس _ في هذا القسم! تتسبب العديد من مكونات Microsoft في الواقع في صعوبات كبيرة بالنسبة لي من خلال سلوكهم المتمثل في محاولة أن أكون أذكياء ولكن في الواقع ينتهي بهم الأمر إلى كونهم أذكياء للغاية . بشكل عام ، كنت سأواجه بالفعل صعوبات أقل وعملًا أقل إذا توقفت هذه المكونات عن محاولة أن تكون ذكية / تلقائية / مريحة للغاية. عند تصميم سلوك تلقائي ، أجد أنه من المفيد أن نضع في اعتبارنا أن الصوت التلقائي يبدو رائعًا ولكن لديه القدرة على إحداث نتائج عكسية.

_ "فقط دعني أفعل ذلك بنفسي." _
أحيانًا يكون الحل الأفضل هو مجرد السماح للتطبيقات بأداء المهمة بنفسها ، بدلاً من المحاولة والفشل في القيام بها "تلقائيًا" داخل مكون مثل DataGrid. أتمنى أن تسمح لي DataGrid بإجراء استرداد البيانات بنفسي بشكل كامل ، بدلاً من محاولة استرداد البيانات تلقائيًا عبر الخصائص DataGridBoundColumn.Binding و DataGrid.ItemsSource .

من الناحية المثالية ، أود إلغاء شرط استخدام الخاصية DataGrid.ItemsSource لتزويد العناصر. ذكرت dotMorten مليون صف. في الوقت الحالي ، تجعل DataGrid التطبيقات إلزامية تعيين DataGrid.ItemsSource ، لكن من غير العملي إنشاء كائن قائمة يحتوي على مليون عنصر. وبالتالي أتمنى أن تتوقف DataGrid عن كونها ذكية في قسم استرداد البيانات ، وبدلاً من ذلك اسمح لي بإجراء استرداد البيانات بنفسي بالكامل ، دون استخدام DataGridBoundColumn.Binding و DataGrid.ItemsSource .

كتب anawishnoff :

يعد الأداء بالتأكيد أحد الدوافع الرئيسية لهذا المشروع وأحد التحسينات الرئيسية التي نريد تنفيذها ، من خلال قصة افتراضية جديدة للبيانات واستخدام عناصر التحكم الحديثة مثل ItemsRepeater.

أرى أنك قلت إن قصة المحاكاة الافتراضية للبيانات الجديدة ستعمل على تحسين الأداء ، وهذه أخبار جيدة ، ولكن هل ستلغي أيضًا مطلب استخدام الخاصية DataGridBoundColumn.Binding أجل توفير قيم الخلية التي تعرضها DataGrid؟

إذا تم الاستعانة بمصادر خارجية لمهمة استرداد البيانات بالكامل إلى التطبيق الذي يستخدم DataGrid ، فإن التطبيق يتمتع بمرونة كاملة لأداء استرداد البيانات بأي طريقة يحتاجها. سيمكن هذا العديد من سيناريوهات استرداد البيانات المختلفة ، بما في ذلك المليون صف التي ذكرتها dotMorten . ابكم ، من فضلك: ابتسم:

بعض الميزات غير الضرورية في WPF DataGrid؟

يحتوي إصدار WPF من DataGrid على بعض الميزات التي تبدو غير ضرورية أو غير عملية ، ويمكن تخطي هذه الميزات في WinUI DataGrid ، لكنني أتوقع أن يكون لبعض الأشخاص رأي مختلف حول هذه الميزات.

كم عدد الأشخاص الذين سيقدمون اعتراضًا إذا تخلى WinUI DataGrid عن الميزة حيث يمكن للمستخدمين النهائيين تحرير قيم الخلية المضمنة / مباشرة داخل DataGrid؟ في حالتنا ، في كل مكان نستخدم فيه DataGrid ، نقوم دائمًا بتعيين DataGrid.IsReadOnly على true لتعطيل ميزة التحرير المباشر / المضمّن. نسمح للمستخدمين بتحرير الصف المحدد في جزء أو لوحة منفصلة ، أو في تفاصيل الصف ( DataGrid.RowDetailsTemplate ) ، ولكن ليس مباشرة داخل DataGrid نفسها.

يبدو أن WinUI DataGrid قد تحرك بالفعل في اتجاه إسقاط الدعم للتحرير المضمن / المباشر لأن WPF DataGrid كان لديه CanUserAddRows و CanUserDeleteRows ولكن هذه الخصائص لم تعد موجودة في WinUI DataGrid. لماذا لا تذهب إلى إفلات ميزة التحرير المباشر / المضمن بالكامل؟ كم من الناس لديهم اعتراضات على هذه الفكرة؟

تحديد الخلية الفردي: يحتوي WPF DataGrid على خاصية SelectionUnit والتي يمكنك تعيينها إلى Cell أو FullRow أو CellOrRowHeader . في حالتنا ، قمنا دائمًا بتعيينها على FullRow ولم نجد أبدًا حاجة لتعيينها على Cell . ومع ذلك أرى شخصًا واحدًا هنا قد طلب بالفعل وضع اختيار خلية واحدة. سؤالي هو ما إذا كان وضع اختيار الخلية طلبًا شائعًا أم نادرًا.

من ناحية أخرى ، قد يكون تحديد الخلية الفردي مفيدًا عندما ينسخ المستخدم الصفوف / الخلايا إلى الحافظة. سيسمح للمستخدمين بنسخ خلية فردية (أو عدة خلايا متجاورة) إلى الحافظة بدلاً من نسخ الصف بأكمله. ومع ذلك ، فأنا لست متأكدًا مما إذا كانت هذه الميزة ذات قيمة حقًا أم لا.

| ميزة مشكوك فيها في WPF | التعليقات |
| : --- | : --- |
| DataGrid.IsReadOnly | ربما لا توجد حاجة حقيقية لتعيين IsReadOnly على خطأ؟ |
| DataGrid.CanUserAddRows | غير موجود في WinUI DataGrid. تم التخلي عنها بالفعل ، أو ربما لم يتم تنفيذها بعد (لا أعرف الخطة). |
| DataGrid.CanUserDeleteRows | غير موجود في WinUI DataGrid. تم التخلي عنها بالفعل ، أو ربما لم يتم تنفيذها بعد (لا أعرف الخطة). |
| DataGrid.SelectionUnit | غير موجود في WinUI DataGrid. |

واو ، مناقشة لا تصدق هنا. ❤️

أوافق أيضًا على WPF DataGrid API. WPF DataGrid هو بالفعل DataGrid الذي أريده لـ WinUI 3.0.

ولكن حتى WPF DataGrid يفتقر إلى بعض الميزات. في الماضي ، استخدم معظم عملائي شبكة DataGrid لجهة خارجية أكثر قوة للحصول على هذه الميزات:

• عوامل التصفية في رؤوس الأعمدة
• صف عامل التصفية الكامل أعلى DataGrid
• عرض قوي للبيانات الهرمية. تعمل بعض شبكات DataGrids التابعة لجهات خارجية مثل برنامج TreeView القوي مع DataGrids المتداخلة. بينما يسمح WPF DataGrid ببناء شيء من هذا القبيل ، فإنه لا يدعمه خارج الصندوق
• دعم لأنواع البيانات المختلفة. مثل على سبيل المثال عمود التاريخ والوقت. في DataGrid الخاصة بـ WPF ، يجب عليك استخدام DataGridTemplateColumn

ولكن على أي حال ، مهما فعلت ، أعتقد أن إنشاء DataGrid هو بيان قوي والتزام بـ WinUI 3.0. بالنسبة لتطبيقات LOB ، لا يمكنك التعامل بجدية مع إطار عمل واجهة مستخدم لا يحتوي على DataGrid مضمن. إنه لأمر رائع أن نرى هذا الاستثمار مخصصًا لـ WinUI!

تضمين التغريدة

بالنسبة لتطبيقات LOB ، لا يمكنك التعامل بجدية مع إطار عمل واجهة مستخدم لا يحتوي على DataGrid مضمن. إنه لأمر رائع أن نرى هذا الاستثمار مخصصًا لـ WinUI!

متفق! في حالتنا ، تعد DataGrid مكونًا أساسيًا للغاية نستخدمه في أماكن متعددة ولا يمكننا العيش بدونه.

عرض قوي للبيانات الهرمية. تعمل بعض شبكات DataGrids التابعة لجهات خارجية مثل برنامج TreeView القوي مع DataGrids المتداخلة.

أنا ممزق بشأن هذا الموضوع لأنني - مثلك - أجد DataGrid ذات التسلسل الهرمي مفيدًا في بعض المواقف ، ولكن ما يقلقني هو أنه إذا نفذت DataGrid وظائف هرمية ، فقد تصبح معقدة وصعبة بشكل مفرط ، وإصدار من المرجح أن يتأخر DataGrid بشكل كبير. سيكون من الصعب إضافة الميزات الجديدة بسبب تعقيد جعل الميزات الجديدة متوافقة مع الوظائف الهرمية وغير الهرمية.

للتخلص من مشكلة التعقيد / التأخير المذكورة أعلاه ، أقترح هذا الحل: إنشاء فئة منفصلة باسم HierarchicalDataGrid تستخدم داخليًا / تلتف بمثيل DataGrid . بدلاً من ذلك ، يمكن أن يرث HierarchicalDataGrid DataGrid علنًا لكنني أشك في أن هذا الميراث غير عملي ، لذلك أفضل اقتراح أن يرث Control HierarchicalDataGrid Control داخليًا وأن يكون لديه حقل خاص به. اكتب DataGrid . وبالتالي سيتم تنفيذ الوظيفة الهرمية في طبقة HierarchicalDataGrid التي توجه مثيلًا داخليًا غير هرمي DataGrid .

الميزة الرئيسية للحل أعلاه هو أنه سيوفر الميزات الهرمية المرغوبة _ دون _ التعثر في DataGrid ، دون جعل DataGrid معقدًا للغاية بحيث يصبح غير قابل للإدارة وبطيئة التطوير.

دعم لأنواع البيانات المختلفة. مثل على سبيل المثال عمود التاريخ والوقت.

أنا موافق. تحقق من DataGridDateTimeColumn و DataGridTimeSpanColumn التي اقترحتها في رسالة سابقة.

تضمين التغريدة

من السهل تصفية الصفحة بأكملها

تضمين التغريدة

المرشحات في رؤوس الأعمدة ؛ صف عامل التصفية الكامل في الجزء العلوي من DataGrid ؛

ستكون الفلاتر رائعة لمساعدة المستخدمين النهائيين في العثور بسرعة على صف أو صفوف ، بدلاً من الوضع الحالي المتمثل في إجبارهم على النظر يدويًا إلى عدد كبير من الصفوف للعثور على ما يبحثون عنه.

ولكن ماذا عن مشكلة مطابقة نص مرشح المستخدم مع أعمدة غير نصية؟ أعمدة المعنى بخلاف DataGridTextColumn ، مثل التصفية باستخدام DataGridTemplateColumn وما إلى ذلك؟ أقترح حل هذا بشيء تقريبًا مثل الحل التالي الذي يمنح DataGridColumn (والفئات الفرعية) القدرة على تحويل قيمة خلية إلى كلمات رئيسية لاستخدامها مع البحث / التصفية / المطابقة.

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

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

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

فيما يلي مثال على كيفية استخدام طريقة ConvertCellValueToKeywords :

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

بدلاً من ذلك ، يمكن تحويل قيمة الخلية إلى سلسلة واحدة بدلاً من مجموعة من الكلمات الرئيسية ، ولكن السبب وراء اقتراح مجموعة الكلمات الرئيسية هو أن الكلمات الرئيسية تجعل من الممكن استخدام خوارزميات البحث التي تعمل بسرعة عالية حتى عندما تكون كمية الصفوف كبير جدا.

نسخ سهل من Excel
الآن لا توجد طريقة لاستخدام ctrl + v لنسخ محتوى خلايا Excel إلى شبكة البيانات. الآن يقوم بنسخ محتوى جميع الخلايا إلى خلية واحدة في شبكة البيانات.

يرجى تقديم دعم مناسب للعناصر المتعددة المحددة ، عن طريق جعل SelectedItems كخاصية تبعية للسماح باستخدام ربط البيانات عند إدارة الصفوف المحددة.

verelpode يمكنني رؤية تحديد خلية فردي مفيد لأي تطبيق من أنواع جداول البيانات ، أليس كذلك؟ أعتقد أن الأمر أكثر أهمية في تحرير السيناريوهات مقابل سيناريوهات العرض. عند عرض البيانات في شبكة بيانات بدون تحرير ، أوافق على أنني لن أرى استخدامًا لتحديد الخلية الفردية ولدي دائمًا تحديد كامل للصف.

anawishnoff أعتقد أن @ Laz3rPanth3r سيوافقان ، وهناك مشكلتان هنا وهنا من مجموعة الأدوات التي تعتبر القدرة على استيعاب البيانات بسهولة وببساطة في DataGrid ميزة مهمة. يجب أن تكون قادرًا على تمهيد الشبكة عن طريق الربط بمجموعة من الكائنات أو توسيع كائنات في قائمة. إذا كان بإمكانه تحديد أعمدة للأرقام والسلاسل وأنواع البيانات الأساسية بذكاء ، فسيكون ذلك رائعًا. يمكن للمطور دائمًا القيام بالمزيد من العمل بعد ذلك لتخصيص الأعمدة الفردية بعد ذلك.

يمكنني رؤية تحديد الخلية الفردي مفيدًا لأي تطبيق من أنواع جداول البيانات ، أليس كذلك؟

في جدول بيانات ، تتم تسمية رؤوس الأعمدة بأحرف أبجدية تصاعدية ، A ، B ، C ، D ،… ويكون نوع كل عمود هو نفسه ، كما لو كان كل عمود يستخدم DataGridTextColumn ولا يوجد عمود آخر الكتابة مطلوبة ، ولا توجد حاجة بالفعل لأسماء الأعمدة إما لأنها تُنشأ تلقائيًا من الأبجدية.
هناك اختلاف آخر بين DataGrid وجدول البيانات وهو أن جدول البيانات لا يقوم بفرز الصفوف عند النقر فوق أي من رؤوس الأعمدة.

وجهة نظري هي أن هناك تشابهًا سطحيًا فقط (غالبًا تشابه مرئي) بين DataGrid وجدول البيانات. لا تعمل DataGrid حقًا مثل جدول البيانات. كما أن تقنية استرداد البيانات الخلوية الخاصة بـ DataGrid غير مناسبة أيضًا لجدول بيانات.

أنا أحب DataGrid ولكنها ستعمل بشكل سيئ إذا حاولت استخدامها لتنفيذ جدول بيانات. لا أعتقد أن DataGrid هو الخيار الصحيح لأي شخص يريد تنفيذ جدول بيانات.

يتماشى التصميم الحالي لـ DataGrid بشكل أفضل مع قاعدة بيانات SQL من جدول البيانات ، ويصرخ مطورو قاعدة بيانات SQL بصوت عالٍ إذا حاول شخص ما الادعاء بأن قاعدة البيانات هي "مجرد جدول بيانات".

verelpode مساهماتك مفصلة للغاية ومدروسة ، شكرًا جزيلاً لك على كل ذلك! أريد أن أتحدث عن فكرة ربط مصدر بيانات / خاصية ItemsSource الخاصة بـ DataGrid ، كما ذكرت ، كما فعل @ michael-hawker أيضًا.

تجعل DataGrid حاليًا من الضروري للتطبيقات تعيين DataGrid.emsSource ، ولكن من غير العملي إنشاء كائن قائمة يحتوي على مليون عنصر. وبالتالي ، أتمنى أن تتوقف DataGrid عن كونها ذكية في قسم استرداد البيانات ، وبدلاً من ذلك اسمح لي بإجراء استرداد البيانات بنفسي بالكامل ، دون استخدام DataGridBoundColumn.Binding و DataGrid.ItemsSource.

هذا مثير للاهتمام ، وأود أن أنظر إليه أكثر لأننا مهتمون حقًا بالأداء. ما نوع حالة / سيناريو البيانات الذي تبحث عنه على وجه التحديد؟ هل تريد توصيل DataGrid مباشرةً بنتيجة استعلام SQL ، أو قاعدة بيانات ، أو أي شيء من هذا القبيل؟

khoshroomahdi بالنسخ واللصق ، هل تقصد أنك تريد نسخ خلايا Excel إلى DataGrid في تطبيق قيد التشغيل ، ثم تعبئتها بهذه الطريقة؟ هذه حالة استخدام مثيرة للاهتمام ، أود أن أسمع المزيد.

alexyak ، هل يمكنك التوسع أكثر قليلاً؟ تتيح لك خاصية SelectedItems حاليًا الحصول على كافة العناصر المحددة في DataGrid (من خلال وضع التحديد الموسع ، وليس وضع التحديد المتعدد بدقة). أرى من بعض التعليقات الأخرى هنا أن التحديد داخل DataGrid يحتاج بالتأكيد إلى عمل ، لكني أريد أن أفهم طلبك بشكل أفضل.

anawishnoff نعم بالضبط.
لدي بعض البيانات في خلايا ممتازة وأريد نسخها في التطبيق قيد التشغيل.

بالنسبة للسيناريوهات غير المرتبطة بالبيانات ، يجب أن ننظر في كيفية دعم عنصر تحكم WinForms DataGridView ، الذي كتبته منذ سنوات عديدة ، للوضع الافتراضي: https://docs.microsoft.com/en-us/dotnet/api/system. windows.forms.datagridview.virtualmode

تجعل DataGrid حاليًا من الضروري للتطبيقات تعيين DataGrid.emsSource ، ولكن من غير العملي إنشاء كائن قائمة يحتوي على مليون عنصر. وبالتالي ، أتمنى أن تتوقف DataGrid عن كونها ذكية في قسم استرداد البيانات ، وبدلاً من ذلك اسمح لي بإجراء استرداد البيانات بنفسي بالكامل ، دون استخدام DataGridBoundColumn.Binding و DataGrid.ItemsSource.

أوافق على أن ذلك سيكون لطيفًا أيضًا. أفكر في شيء مثل ListBox حيث يمكنك إما إضافة العناصر يدويًا أو تعيين مصدر العناصر. ومع ذلك ، في الماضي ، قمت للتو بإنشاء DataTable جديد يمثل عرضًا جزئيًا لقاعدة البيانات الكاملة لتنفيذ الترحيل (وهي حالة استخدام جيدة لهذا الغرض). يمكن بعد ذلك تعيين طريقة عرض DataTable إلى مصدر العناصر. لذلك ، بينما أعتقد بالتأكيد أن هذا أمر جيد أن لا يبدو إلزاميًا للأداء العالي.

فيما يتعلق بجميع التعليقات التي تحول عنصر التحكم إلى مجموعة فرعية من Excel (r) أكثر أو أقل ، أعتقد أنه من خارج الصندوق ، يجب أن تدعم DataGrid تحديد الخلية والتحرير لكل خلية. ومع ذلك ، يجب أن يتعامل المطور مع أشياء مثل النسخ / اللصق بين التطبيقات الخارجية.

alexyak فيما يتعلق بطلبك لجعل SelectedItems انظر المناقشة هنا

كتب anawishnoff :

مساهماتك مفصلة للغاية ومدروسة ، شكرًا جزيلاً لك على كل ذلك!

شكرًا ، يسعدني أن أسمع أن مساهماتي مفيدة في تحسين DataGrid :)

ما نوع حالة / سيناريو البيانات الذي تبحث عنه على وجه التحديد؟ هل تريد توصيل DataGrid مباشرةً بنتيجة استعلام SQL ، أو قاعدة بيانات ، أو أي شيء من هذا القبيل؟

لا يزال هذا ذكيًا جدًا. يمنع هذا السلوك الذكي التطبيقات المختلفة من إجراء استرداد البيانات بطرق مختلفة. التطبيقات المختلفة لها ظروف مختلفة إلى حد كبير ، وبالتالي فإن نظام استرجاع البيانات "الأفضل" يختلف عن التطبيقات المختلفة - لا يوجد "أفضل" واحد. على سبيل المثال ، لا تعرض بعض التطبيقات أبدًا أكثر من بضع مئات من الصفوف ، في حين أن بعض التطبيقات الأخرى قد تعمل مع مليون صف مثل dotMorten المذكور ، وبالتالي فإن حجم حذاء واحد لا يناسب الجميع.

أقترح حقًا تقليله إلى هذا المستوى:

1. قررت DataGrid أنها بحاجة إلى عرض (أو استخدام) القيمة الموجودة في العمود 5 من الصف 9001 في نظام تخزين البيانات الخارجية.
2. يقوم DataGrid بإعلام التطبيق بأنه يحتاج إلى قيمة العمود 5 من الصف 9001.
3. يسترد التطبيق قيمة العمود 5 من الصف 9001. قد يتضمن ذلك استعلام SQL غير متزامن أو مهمة C # غير متزامنة أو أي نظام بيانات آخر. من الناحية المثالية ، يجب أن تسمح DataGrid لهذه الخطوة بأن تكون غير متزامنة.
4. يخطر التطبيق DataGrid بأنه انتهى من استرداد القيمة للعمود 5 من الصف 9001. يعطي التطبيق هذه القيمة إلى DataGrid.
5. تستخدم DataGrid القيمة بأي طريقة تحتاجها ، مثل عرض القيمة كما هو مذكور في الخطوة 1.

RBrid كتب:

بالنسبة للسيناريوهات غير المرتبطة بالبيانات ، يجب أن ننظر في كيفية دعم عنصر تحكم WinForms DataGridView ، الذي كتبته منذ عدة سنوات ، للوضع الافتراضي:

نعم نعم نعم! لم أستخدم برنامج WinForms DataGridView مطلقًا ، لكني قرأت التوثيق الآن وأعتقد أنك قد أصبت بالمسمار الأول. صفحة الويب التي قمت بالربط بها تقول:
_ "تم تصميم الوضع الافتراضي للاستخدام مع مخازن كبيرة جدًا من البيانات." _

أرى أن WinForms DataGridViewCellValueEventArgs يحتوي على هذه الخصائص:

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

هذا ممتاز ، باستثناء أنه يجب تحديثه بشكل مثالي لدعم الكلمات الرئيسية الحديثة C # async و await ، أو ما يعادل UWP ( IAsyncOperation<TResult> ) ، أو بالأحرى أي نوع من التأخير الزمني بين DataGrid التي تطلب قيمة الخلية والتطبيق الذي يقدم قيمة الخلية إلى DataGrid. وبالتالي لتحديثه لدعم عدم التزامن ، قم بما يلي:

1. احتفظ بالحدث CellValueNeeded .
2. قم بإزالة الخاصية DataGridViewCellValueEventArgs.Value .
3. قم بإنشاء طريقة في DataGrid تسمى شيئًا مثل SupplyCellValue سيستدعيها التطبيق ، بدلاً من مطالبتك بتعيين الخاصية على الفور / بشكل متزامن DataGridViewCellValueEventArgs.Value .

يمكن تعريف طريقة SupplyCellValue على النحو التالي:

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

وبالتالي في وقت التشغيل يكون الإجراء:

1. قررت DataGrid أنها بحاجة إلى عرض (أو استخدام) القيمة الموجودة في العمود 5 من الصف 9001 في نظام تخزين البيانات الخارجية.
2. تقوم DataGrid بتشغيل الحدث CellValueNeeded وتعيين DataGridViewCellValueEventArgs.RowIndex إلى 9001 و DataGridViewCellValueEventArgs.ColumnIndex إلى 5.
3. يبدأ معالج الحدث (التطبيق) في تشغيل مهمة غير متزامنة تقوم باسترداد القيمة للعمود 5 من الصف 9001.
4. عند انتهاء تشغيل المهمة غير المتزامنة ، أي عندما يسترد التطبيق القيمة ، يستدعي التطبيق الطريقة DataGrid.SupplyCellValue .

هذه التقنية الخافتة أكثر قوة ومرونة من التقنية الآلية الذكية DataGridBoundColumn.Binding و DataGrid.ItemsSource .

alexyak ، هل يمكنك التوسع أكثر قليلاً؟ تتيح لك خاصية SelectedItems حاليًا الحصول على كافة العناصر المحددة في DataGrid (من خلال وضع التحديد الموسع ، وليس وضع التحديد المتعدد بدقة). أرى من بعض التعليقات الأخرى هنا أن التحديد داخل DataGrid يحتاج بالتأكيد إلى عمل ، لكني أريد أن أفهم طلبك بشكل أفضل.

نحن بحاجة إلى قاعدة بيانات مناسبة ثنائية الاتجاه لنماذج العرض لإدارة التحديدات المتعددة

verelpode ، لقد قمنا بتصميم نموذج WinForms DataGridView بعد عناصر تحكم Win32 ComCtl32 الأقدم. على وجه الخصوص ، أفكر في كيفية استخدام عنصر تحكم عرض القائمة لرسالة LVN_GETDISPINFO في الوضع الافتراضي (راجع https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview # التعامل مع رموز الإعلام الافتراضية - list-view-control و https://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo). أشياء قديمة من التسعينيات.

على أي حال ، أعتقد أن الطريقة التي ينبغي بها معالجة جانب استرجاع البيانات غير المتزامن هي من خلال "الأحداث المؤجلة".
تستخدم عناصر تحكم WinUI بالفعل الأحداث المؤجلة مرتين:

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

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

إنه النمط الذي يريد حدث CellValueNeeded الجديد الخاص بـ DataGrid اعتماده. يسمح لمعالج الأحداث بتوفير البيانات بشكل غير متزامن وإخبار عنصر التحكم عند القيام بذلك. راجع https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferral.

تضمين التغريدة
نقطة جيدة أن GetDeferral() هو النمط القياسي الجديد. في هذه الحالة المحددة من CellValueNeeded ، يبدو أن استخدام Deferral أكثر صعوبة مما هو عليه في الحالات / الأحداث الأخرى. صححني إذا كنت مخطئًا ، لكنني أعتقد أن مشكلة استخدام GetDeferral() في هذه الحالة بالذات هي أن GetDeferral() يُنشئ كائنًا جديدًا في كل مرة يتم استدعاؤه ، وقد يؤدي ذلك إلى زيادة يتم تكرار قدر كبير من إنشاء الكائن وتنظيفه لكل خلية في كل صف لعدد كبير من الصفوف. لم أر الكود المصدري للعديد من تطبيقات GetDeferral() لذلك قد أكون مخطئًا في هذا الأمر.

بعبارة أخرى ، ما لم يكن Deferral يدعم إعادة التدوير أو لديه طريقة أخرى لجعل GetDeferral() أكثر كفاءة ، فإنه لا يزال ذكيًا جدًا. يتجنب اقتراحي المبهم باستخدام الطريقة SupplyCellValue تكبد النفقات العامة لإنشاء مثيل Deferral جديد واستكماله والتخلص منه لكل خلية في كل صف قابل للتطبيق.

1. GetDeferral()
2. تأجيل
3. تأجيل
4. كرر الخطوات المذكورة أعلاه عدة مرات.

مهمة استرداد قيمة الخلية ليست مهمة إدارة البيانات الوحيدة التي قد يتم الاستعانة بمصادر خارجية للتطبيق. الفرز قد يكون أيضا الاستعانة بمصادر خارجية. لذلك قد يكون من المفيد التفكير في واجهة بدلاً من حدث واحد CellValueNeeded . سيعطي التطبيق DataGrid وحدة نمطية لإدارة البيانات في شكل كائن يقوم بتنفيذ واجهة معينة. ستستدعي DataGrid هذه الواجهة لاسترداد قيم الخلايا ، ولكن أيضًا من المحتمل أن تستدعي مهام أخرى مثل الفرز.

لدعم الملايين من الصفوف التي ذكرتها dotMorten ، لن يحل CellValueNeeded وحده المشكلة الأخرى التي تحدث عندما ينقر المستخدم فوق رأس عمود وتحاول DataGrid فرز مليون صف. وبالتالي ، يمكن الاستعانة بمصادر خارجية لاسترداد الخلية وفرزها إلى التطبيق عبر الوحدة / الواجهة المذكورة أعلاه.

إذا كان التطبيق لا يوفر أي وحدة / كائن لإدارة البيانات إلى DataGrid ، فمن الأفضل أن تستخدم DataGrid وحدة افتراضية لإدارة البيانات. وبالتالي ، سيتم نقل جميع التعليمات البرمجية لربط البيانات الموجودة في DataGrid خارج DataGrid إلى فئة جديدة منفصلة - الفئة التي تنفذ وحدة إدارة البيانات الافتراضية من خلال العمل مع DataGridBoundColumn.Binding إلخ.

على سبيل المثال ، عندما يتم الاستعانة بمصادر خارجية للتطبيق أو وحدة إدارة البيانات الخاصة به ، فإن هذا يفتح الباب أمام حلول متنوعة تدعم مليون صف ، مثل كتابة وحدة إدارة بيانات ترشد خادم SQL لإجراء الفرز ، بدلاً من محاولة- وفشل إجراء الفرز لمليون صف داخل DataGrid في وقت أقل من 10 أو 20 ساعة بعد أن ينقر المستخدم فوق رأس العمود لبدء الفرز.

verelpode ، نعم هذا مصدر قلق صحيح. أتوقع أن تمتلك DataGrid مجموعة من كائنات Windows.Foundation.Deferral القابلة لإعادة التدوير. سنحتاج إلى تأكيد الجدوى والكمال بالتأكيد.

بعد الاعتماد على مجموعة أدوات مجتمع Windows DataGrid التي تحتوي على تفاصيل الصف كميزة (وإن كان ذلك مع وجود خلل خطير في الأداء ولكن مع حل بديل) ، نود حقًا أن يكون لشبكة البيانات الجديدة هذه ميزة أيضًا - بنفس الخيار للحصول على تفاصيل متعددة في نفس الوقت. استخدامه لخادم لعميل سيناريو تدفق البيانات.

ري مليون صف مقابل واجهة المستخدم الرسومية الترحيل، كتبrobloo:

أوافق على أن [دعم مليون صف] سيكون أمرًا رائعًا أيضًا. .... ومع ذلك ، في الماضي ، قمت للتو بإنشاء DataTable جديد يمثل عرضًا جزئيًا لقاعدة البيانات الكاملة لتنفيذ الترحيل (وهي حالة استخدام جيدة لهذا الغرض). يمكن بعد ذلك تعيين طريقة عرض DataTable إلى مصدر العناصر. لذلك ، بينما أعتقد بالتأكيد أن هذا أمر جيد أن لا يبدو إلزاميًا للأداء العالي.

يعد Paging أسلوبًا مفيدًا وجدير بالذكر ، ولكن له عيوبًا كبيرة: فهو يجعل ميزة فرز DataGrid غير مجدية عمليًا. وبالمثل بالنسبة لميزة التصفية في الإصدار التالي من DataGrid. يجعل الترحيل الفرز والتصفية عديم الجدوى أو على الأقل أقل فائدة بكثير.

على سبيل المثال ، تخيل أن عمودين أو ثلاثة أعمدة هي أعمدة تاريخ ، ويريد المستخدم عرض الصفوف التي تحتوي على أحدث تاريخ (أو أقدم) في عمود التاريخ الثاني. وبالتالي ، ينقر المستخدم فوق رأس عمود التاريخ الثاني لفرز DataGrid حسب هذا العمود ، وينقر أيضًا لتغيير اتجاه الفرز من تنازلي إلى تصاعدي أو العكس. يعمل هذا بشكل رائع إذا لم يكن هناك أي صفحات قيد الاستخدام ، أو إذا كانت الكمية الإجمالية للصفوف صغيرة بما يكفي بحيث لا تتجاوز صفحة واحدة ، ولكنها تتعطل في حالة وجود عدة صفحات.

يحتاج المستخدم إلى العثور على أحدث تاريخ (أو أقدم) عبر جميع الصفوف ، لكن واجهة المستخدم الرسومية DataGrid المُقسمة إلى صفحات تُظهر فقط أحدث (أو أقدم) تاريخ في الصفحة الحالية ، وليس عبر جميع الصفوف ، وبالتالي فإن الترحيل يجعل الفرز (والتصفية) عمليًا عديم الفائدة.

هذا يثير تساؤلاً حول أي من الصفوف تقع في أي صفحة. الإجابة هي أن كل صفحة تحتوي عادةً على مجموعة فرعية عشوائية عمليًا من الصفوف ، عندما يتم الحصول على الصفحات / الصفوف عبر استعلام SQL SELECT الذي لا يستخدم ORDER BY . (أعني عشوائيًا من وجهة نظر المستخدم ، وليس عشوائيًا حقًا.)

العشوائية الزائفة غير مفيدة للمستخدمين النهائيين. للتخلص من هذه العشوائية المسببة للمشاكل ، يمكننا التفكير في استخدام SQL ORDER BY (جنبًا إلى جنب مع الكلمة الرئيسية ASC أو DESC للتحكم في اتجاه الفرز) ، ثم نعم ، الصفحات لا أطول عشوائيًا ، لكنه لا يزال معطلاً لأن هذا الاستخدام لـ ORDER BY يفرز دائمًا حسب نفس العمود ونفس اتجاه الفرز ، مما يعني أن ترتيب الفرز غالبًا ما يكون مختلفًا عن ترتيب الفرز الذي يختاره المستخدم النهائي بالنقر فوق أحد الأعمدة رأس في DataGrid.

لإصلاحها ، ستحتاج إلى استخدام استعلام SQL مختلف في كل مرة ينقر فيها المستخدم على رأس عمود مختلف. يجب الاحتفاظ بـ SQL ORDER BY ... ASC/DESC كما هو الحال مع أي ترتيب فرز يختاره المستخدم النهائي لـ DataGrid. DataGrid لا يدعم هذا حاليًا.

يوجد حل مقترح في رسالتي السابقة : لقد اقترحت أن تسمح DataGrid بالفرز بالاستعانة بمصادر خارجية للتطبيق (أو إلى "وحدة إدارة البيانات"). ستتيح هذه الفكرة للتطبيق (أو "وحدة إدارة البيانات") تغيير SQL ORDER BY ... ASC/DESC عندما يغير المستخدم النهائي ترتيب فرز DataGrid عن طريق النقر فوق رؤوس الأعمدة وما إلى ذلك.

قد يكون من المفيد أيضًا إعطاء الحدث الموجود مسبقًا DataGrid.Sorting خاصية قابلة للتعيين في الحدث args الذي يسمح للتطبيقات (معالج الحدث) بإلغاء الفرز وتولي المهمة. من الناحية المثالية ، ستحدد قوائم الحدث أيضًا ما إذا كان قد تم طلب تغيير ترتيب الفرز برمجيًا مقابل طلب المستخدم النهائي بالنقر فوق رؤوس الأعمدة وما إلى ذلك. في هذه الحالة ، قد يكون من المفيد أيضًا إعادة تسمية الحدث DataGrid.Sorting إلى شيء أقل غموضًا لأن الهدف والغرض من حدث Sorting غير واضح حاليًا. راجع أيضًا الحدث المقترح

بعد الاعتماد على مجموعة أدوات مجتمع Windows DataGrid التي تحتوي على Row
التفاصيل كميزة (على الرغم من وجود خلل خطير في الأداء ولكن مع وجود حل بديل) ، سنفعل
أحب حقًا شبكة البيانات الجديدة هذه للحصول على ذلك كميزة أيضًا - مع نفس الخيار
تفاصيل متعددة الصفوف في وقت واحد. استخدامه لخادم لعميل سيناريو تدفق البيانات.

ارتباط بمشكلة أداء تفاصيل الصف: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2842
Repro: https://github.com/observito/DataGridRowDetailsPerfTest

تتمثل نقطة البداية الجيدة في النظر إلى شريكك Telerik باستخدام RadDataGrid (UWP Open Source). مع أحد عملائي ، استخدمته وهو يعمل بشكل جيد بالفعل. إنه سريع للغاية ومتعدد الاستخدامات. الشيء الوحيد الصعب هو الكود الخاص بهم ، ولا توجد طريقة لتعديل أي شيء من محركهم دون فهم جيد للهندسة المعمارية.

أتوقع أن تكون DataGrid الجديدة بنفس أداء Telerik.

تعد ميزات شبكة syncfusion رائعة ولكنها ليست صديقة لـ mvvm. لذلك يمكنك أن تفعل ما هو أفضل.

مرحبًا جميعًا مرة أخرى! دعنا نستمر في هذه المحادثة. ما هي أفكارك حول وثائق DataGrid الموجودة حاليًا؟

فيما يلي رابط إلى صفحة التوثيق الرئيسية التي ترتبط بجميع الصفحات الأخرى ذات الصلة.

إذا أنشأنا DataGrid جديدًا ، فنحن نريد التأكد من أن الوثائق المصاحبة لها ستكون من الدرجة الأولى وسهلة الفهم وتعالج جميع المشكلات والسيناريوهات المهمة لمطورينا.

_ما هي بعض المواضيع التي تتمنى أن تكون لدينا؟ ما هي بعض المواضيع التي يمكن توضيحها؟ _

مرحبًا جميعًا مرة أخرى! دعنا نستمر في هذه المحادثة. ما هي أفكارك حول وثائق DataGrid الموجودة حاليًا؟

فيما يلي رابط إلى صفحة التوثيق الرئيسية التي ترتبط بجميع الصفحات الأخرى ذات الصلة.

إذا أنشأنا DataGrid جديدًا ، فنحن نريد التأكد من أن الوثائق المصاحبة لها ستكون من الدرجة الأولى وسهلة الفهم وتعالج جميع المشكلات والسيناريوهات المهمة لمطورينا.

_ما هي بعض المواضيع التي تتمنى أن تكون لدينا؟ ما هي بعض المواضيع التي يمكن توضيحها؟ _

قد تكون الصور التي تعرض إعدادات DataGrid النموذجية ، جنبًا إلى جنب مع xaml والتعليمات البرمجية لعملها ، مفيدة.

قد تكون الصور التي تعرض إعدادات DataGrid النموذجية ، جنبًا إلى جنب مع xaml والتعليمات البرمجية لعملها ، مفيدة.

mdtauk هل هناك أي إعدادات DataGrid محددة تجدها "نموذجية" ، أو حالات استخدام تجد فيها باستمرار أن DataGrid هو الخيار الأفضل للاستخدام؟

قد تكون الصور التي تعرض إعدادات DataGrid النموذجية ، جنبًا إلى جنب مع xaml والتعليمات البرمجية لعملها ، مفيدة.

mdtauk هل هناك أي إعدادات DataGrid محددة تجدها "نموذجية" ، أو حالات استخدام تجد فيها باستمرار أن DataGrid هو الخيار الأفضل للاستخدام؟

أعتقد بالنسبة للإطار الزمني WinUI 3.0 ، والذي يعرض سيناريوهات عرض شبكة / رمز بيانات WPF و Win32 الشائعة. بالإضافة إلى ما تعتبره Microsoft تصاميم Fluent / Modern DataGrid UI.

هذا إذا كانت الفكرة وراء التحكم هي تشجيع الانتقال من واجهات المستخدم القديمة إلى WinUI 3

anawishnoff أعتقد أن بعض الأسئلة التي

• التصميم / إعادة القوالب / المحاذاة
• ربط البيانات (بشكل عام وفي XAML)
• معالجة / غلاف الحدث / التحديد
• سلوكيات التحرير (خاصة التحرير عند النقر)
• متعدد الصفحات (والذي يجب أن يقترن جيدًا مع # 60 و # 268)
  
  
  
  • تحميل تنسيق الرسوم المتحركة أثناء تحميل البيانات
  
  
• نسخ / لصق / تنسيق
• أنواع بيانات العمود المختلفة (والأنواع المخصصة) (مثل التعدادات)
• قوائم السياق
• إمكانية الوصول

لقد لاحظت أن Toolkit DataGrid الحالية تتطلب IEnumerable لخاصية ItemsSource الخاصة بها. بينما يبدو هذا قرارًا منطقيًا ، فإنه يجعل تعيين الكائن الذي تم إرجاعه بواسطة Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector () لأن هذه الخاصية مستحيلة. (ما لم تكن هناك طريقة لإرجاع الكائن) علاوة على ذلك ، فإن عناصر التحكم الأخرى مثل ListView و GridView تدعم تعيين خاصية ItemsSource الخاصة بها إلى قيمة من نوع الكائن. لست متأكدًا ، لكن دعم ذلك قد يسمح على الأرجح بواجهة مستخدم أكثر استجابة أثناء عمليات التخزين.

mdtauk هل هناك أي إعدادات DataGrid محددة تجدها "نموذجية" ، أو حالات استخدام تجد فيها باستمرار أن DataGrid هو الخيار الأفضل للاستخدام؟

أعتقد بالنسبة للإطار الزمني WinUI 3.0 ، والذي يعرض سيناريوهات عرض شبكة / رمز بيانات WPF و Win32 الشائعة. بالإضافة إلى ما تعتبره Microsoft تصاميم Fluent / Modern DataGrid UI.

هذا إذا كانت الفكرة وراء التحكم هي تشجيع الانتقال من واجهات المستخدم القديمة إلى WinUI 3

مثال Win32 (مستكشف الملفات)

مثال WPF

مثال على شبكة النسيج

مثال UWP

mdtauk شكرا لهذه

@ michael-hawker رهيبة. أرى بالفعل بعض الموضوعات التي تم طرحها عدة مرات في هذا الموضوع ، لذا فهذه بالتأكيد مكان جيد للبدء.

@ duke7553 لست متأكدًا بنسبة 100٪ من إيجاد حل لذلك ، أو إذا كان من الحكمة دعم نوع كائن. ربما RBrid يمكن أن تتناغم؟

anawishnoff & @ duke7553 ، سأبني عنصر تحكم DataGrid الجديد أعلى عنصر تحكم WinUI ItemsRepeater الجديد. ويكشف هذا التحكم مصدر العناصر الخاص به ككائن:
Object ItemsSource { get; set; };

آمل أن تدعم CellDecorationStyleSelector كما في Telerik.

تضمين التغريدة

نحن مهتمون بتخريجها إلى عنصر تحكم WinUI أصلي

هممممم عندما تقول "تخرج" ، هل سيشمل ذلك تخفيضه إلى ++ C؟ حاليًا تتم كتابة DataGrid الخاصة بـ WinUI بلغة C #. آمل ألا تعني كلمة "خريج" "الرجوع إلى إصدار سابق". الأهم من ذلك ، يحتاج WinUI إلى الوصول إلى نقطة يمكن لفريق WinUI أن يقول فيها إن WinUI أفضل من WPF من كل النواحي المهمة ، ولكن هذا الهدف قد تأخر كثيرًا. سيصبح هذا الهدف أكثر تأخراً إذا تم إهدار الوقت / الموارد في تخفيضات غير ضرورية للرمز مثل DataGrid من C # إلى C ++.

على الرغم من وجود سبب أصلاً لكتابة WinRT / UWP / WinUI في C ++ ، إلا أن هذا السبب لم يؤت ثماره ، واستحوذ Google / Android على معظم حصة سوق الهاتف الذكي ، وبالتالي فإن السبب الأصلي لاستخدام C ++ لم يعد قابلاً للتطبيق (بسهولة قال في الإدراك المتأخر ، ولكن ليس من السهل قول ذلك في وقت سابق). إذا تمت كتابة WinUI بلغة C # من البداية ، فإن الهدف الأفضل من WPF قد تحقق قبل 3 سنوات ، ولكن الآن مرت 8 سنوات ولم يتحقق بعد ، ولا أحد قادر على تحديد متى سيتم الوصول إلى الهدف بدقة. نأمل ألا يتأخر هدف أفضل من WPF وأهداف WinUI DataGrid "التخرج" بسبب التحويل غير الضروري إلى لغة برمجة أقدم وأقل إنتاجية.

أنا متحيز لصالح C ++ لأنني بدأت البرمجة بلغة C ++ قبل وجود C # ، ويفضل الناس التمسك بما تعلموه في الأصل ، ويتذكرون باعتزاز _ "الأيام الخوالي" _. على الرغم من تحيزي لصالح C ++ ، فقد توقفت عن كتابة C ++ ، وأعتقد أنه لا ينبغي إرجاع DataGrid إلى C ++ وتأخيرها. اتركه كـ C # وركز على أشياء أكثر أهمية مثل إجراء التحسينات المختلفة التي اقترحها الأشخاص في هذه المسألة ، وتحقيق هدف أفضل من WPF قبل الوصول إلى عقد واحد.

أحب العديد من جوانب WinUI ، وأقدر العديد من التحسينات الذكية فيه ، وأنا أكتب كود تطبيق لـ WinUI ، لكن هل تريد معرفة الحقيقة الصادقة؟ الحقيقة هي ، للأسف ، لم أقم بإطلاق أي تطبيق WinUI للمستخدمين على الإطلاق. البرنامج الذي تم إصداره للمستخدمين مكتوب باستخدام WPF ، ولا يهتم المستخدمون لأن البرنامج يعمل بشكل جيد ويتضمن تحديثات واجهة المستخدم الرسومية. على الرغم من أنني كتبت مجموعة كاملة من أكواد التطبيق لـ WinUI ، إلا أنها كلها تحضيرات وتخطيط واختبار وانتظار وليست في الواقع قيد الاستخدام من قبل المستخدمين. نأمل أن يتم إطلاق أول مكون WinUI في العام المقبل للمستخدمين ، لكنني سأقدر هذا التبديل أكثر بكثير مما سيفعلونه. لن يلاحظ المستخدمون التبديل ، إذا سارت الأمور على ما يرام.

من وجهة نظر Microsoft ، WinRT / UWP هو برنامج ذو جودة إصدار ، يتم نشره للمستخدمين منذ عام 2012 ، ولكن من وجهة نظري ، لا يزال UWP تجربة كبيرة. بالنسبة لي ، UWP (بما في ذلك WinUI) هو نسخة تجريبية كبيرة كنت ألعب بها منذ سنوات.

خلال السنوات القليلة الأولى من UWP ، كنت أفكر كل عام: _ "errr ... سأنتظر حتى العام المقبل. لا يزال هناك الكثير من الأشياء في WPF مفقودة في UWP. بالتأكيد سيكون العام المقبل أفضل." _
ثم جاء العام التالي وكررت نفس الفكرة. ثم جاء العام التالي وكررت نفس الفكرة. آمل أن يكون هذا العام هو العام الأخير لقول ذلك ، أو على الأقل هذه هي نيتي.

لا تستطيع WinUI تحمل المزيد من التأخيرات. اترك DataGrid لـ WinUI كرمز C #. ابدأ في كتابة المزيد من كود WinUI في C # لزيادة الإنتاجية. لقد مرت الآن 8 سنوات وحصلت Android على حصة سوقية ضخمة. هذا وضع صعب.

بالمناسبة ، كنت في الواقع لطيفًا / كريمًا عندما قلت إن UWP لا يزال إصدارًا تجريبيًا ، لأن UWP تقنيًا يطابق تعريف إصدار ألفا ، وليس تجريبيًا. لكي تكون نسخة تجريبية حقيقية ، يجب أن تكون كاملة الميزات ، لكن UWP لم تصل بعد إلى حالة اكتمال الميزات ، لذلك لا يزال UWP هو ألفا. على سبيل المثال ، تقول مقالة "دورة حياة إصدار البرنامج" في ويكيبيديا :

"تبدأ المرحلة التجريبية عمومًا عند اكتمال ميزة البرنامج ولكن من المحتمل أن تحتوي على عدد من الأخطاء المعروفة أو غير المعروفة."
"قد لا يحتوي برنامج Alpha على جميع الميزات المخطط لها للإصدار النهائي."

تعرف ويكيبيديا "الميزة كاملة" على النحو التالي:

"يحتوي الإصدار الكامل للميزة من أحد البرامج على جميع ميزاته الأساسية المخطط لها أو التي تم تنفيذها ولكنها ليست نهائية بعد بسبب الأخطاء أو مشكلات الأداء أو الاستقرار. ويحدث هذا في نهاية اختبار ألفا للتطوير."

سيكون من غير المعقول وصف UWP بأنه مكتمل للميزات لأنه إذا كان مكتمل الميزات حقًا ، فيجب أن يتمتع UWP بجميع إمكانيات Windows 95 بالإضافة إلى المزيد ، ولكنه لا - لا يتجاوز UWP نظام Windows 95 في جميع المجالات . تم إصدار Windows 95 منذ 25 عامًا. عندما تم إصدار UWP / WinRT قبل 7-8 سنوات ، تكبدت Microsoft خسارة 900 مليون دولار ونقص شديد في التطبيقات في متجر Windows. لقد كانت نسخة ألفا تم تصنيفها على أنها نسخة إصدار ، وبالتالي انتظر مطورو التطبيق وشاهدوا. اليوم ، بعد مرور ما يقرب من 8 سنوات ، لا يزال إصدار ألفا متأخرًا جدًا ، وما زلت أنتظر وأراقب وأنتظر.

سيكون من المفيد جدًا لشركة Microsoft والمطورين أن تتخذ Microsoft قرارًا / التزامًا جادًا بإعطاء الأولوية لإنتاج نسخة تجريبية حقيقية من UWP ، ليتبعها بسرعة إصدار مرشح حقيقي. سيكون هذا موصى به للغاية ومسار عمل معقول للغاية. سيكون ممتازًا للجميع.

UWP لا يزال alpha / غير مكتمل لعدة أسباب ، على سبيل المثال: منذ 25 عامًا ، كان من السهل استخدام وظيفة "MoveFile" في نظام التشغيل Windows 95 لنقل ملف أو مجلد (على الرغم من أن الوظيفة كانت تسمى "MoveFile" ، إلا أنها تدعم كلا الملفين والمجلدات). هل يمكن لـ UWP نقل المجلدات؟ لا ليس بعد. من الواضح أن القدرة على نقل المجلدات هي إحدى الميزات الأساسية الأساسية ، ولكن UWP لا يزال يفتقد هذه الميزة الأساسية وغيرها ، لذلك سيكون من غير المعقول وصف UWP بأنه مكتمل الميزات ، لذلك لم يصل UWP بعد إلى حالة بيتا ، على الرغم من تم إصداره منذ 7-8 سنوات. تحتاج Microsoft إلى إعطاء الأولوية لإصدار تجريبي حقيقي من UWP.

لا يوجد حتى الآن مستودع GitHub عام لتتبع مشكلات UWP (بخلاف مشكلات واجهة المستخدم) ، على حد علمي (أو في حالة وجود مستودع UWP ، لم أتمكن من العثور عليه). مرة أخرى ، يتطابق هذا مع تعريف إصدار ألفا لأن إعادة الشراء العامة لتتبع المشكلات غالبًا ما تكون غير مرغوب فيها أثناء مرحلة ألفا. إذا كان إصدارًا تجريبيًا أو إصدارًا حقيقيًا ، فسيكون قد تم بالفعل فتح مستودع عام لتتبع المشكلات ، وسيشمل UWP جميع ميزات Windows 95 و Windows 7 والمزيد.

كيف يؤثر هذا الموقف على DataGrid ؟ بالنظر إلى أن إصدار تجريبي كامل الميزات من UWP قد فات موعد استحقاقه بشكل رهيب ، وبالنظر إلى خطورة هذا الموقف والخسارة التي تكبدتها Microsoft بمليارات الدولارات نتيجة لذلك ، فلن يكون من المبرر والمعقول إضاعة المزيد من الوقت عن طريق تحويل WinUI DataGrid إلى كود غير مُدار ولغة برمجة أقدم. صرحت Microsoft مرارًا وتكرارًا أن الميزة الكبيرة لـ C # و "التعليمات البرمجية المُدارة" هي زيادة الإنتاجية ، ويمكنني القول إن ادعاءات Microsoft حول "التعليمات البرمجية المُدارة" كانت صحيحة بالتأكيد في تجربتي مع كل من C ++ و C #. كان UWP قد وصل إلى حالة بيتا الحقيقية منذ عدة سنوات إذا تمت كتابته بشكل أساسي باستخدام التعليمات البرمجية المُدارة بدءًا من الإصدار 1.0. لذلك آمل ألا يصبح الموقف أسوأ من خلال إجراء المزيد من هذه التخفيضات غير الضرورية من التعليمات البرمجية المُدارة إلى التعليمات البرمجية غير المُدارة.

للمقارنة ، تم إكمال معظم WPF بنجاح في 4 سنوات من 2006 إلى 2010. WPF هو رمز مُدار بشكل أساسي ، على عكس UWP. UWP هو رمز غير مُدار وبعد 8 سنوات من التطوير ، لا يزال Windows 95 يتفوق على UWP في عدد قليل من المجالات ، لذلك كانت Microsoft على صواب عندما ادعت Microsoft أن الكود المُدار يزيد الإنتاجية. هذه المشكلة تحتاج إلى حل في أسرع وقت ممكن. كان من المفترض أن يكون إنشاء WinUI أسهل / أسرع في الإنشاء من WPF لأن كلا المشروعين لهما نفس المالك (Microsoft) ، وبالتالي يُسمح لـ WinUI بنسخ الكود من WPF بحرية. وبالتالي ، كان من المفترض أن يتطلب WinUI نصف وقت تطوير WPF تقريبًا. في الواقع ، لم يكن يجب أن يبدأ WinUI مطلقًا ، بل كان ينبغي على Microsoft تطوير ميزات WinUI في الإصدارات الجديدة من WPF - كان يجب أن يكون WinUI هو WPF 5.0. لذلك ، كان الموقف فوضى كبيرة وسيكون من المفيد جدًا لشركة Microsoft إعطاء الأولوية للتنظيف المتبقي لهذه الفوضى ، والتوقف عن القيام بالأشياء التي تجعل الخطأ الذي تبلغ قيمته عدة مليارات من الدولارات أسوأ مما كان عليه بالفعل (ولا يزال كذلك عندما تنظر في حالة مشاركة سوق الهاتف الذكي اليوم).

هذا يعني ، من أجل منع المزيد من الخسائر ، ستستفيد Microsoft من خلال تذكر ما قالته / عرفته Microsoft بالفعل في الماضي:

• تعمل التعليمات البرمجية المُدارة على زيادة الإنتاجية ، وفقًا لادعاءات Microsoft الخاصة. عندما تنظر إلى UWP لمدة 8 سنوات مقارنة بـ WPF 4 سنوات ، يجب أن تكون النتيجة أن Microsoft كانت صحيحة فيما يتعلق بإعادة فوائد التعليمات البرمجية المُدارة.
• لغات البرمجة هي لغات البرمجة النصية ، ولغات البرمجة مخصصة للبرمجة. JavaScript و PowerShell جيدان للأغراض المقصودة (البرمجة النصية) ، لكن من الواضح أنهما خيارات غير مناسبة لبرمجة التطبيقات.
• لكي تكون ناجحًا ، يجب أن تتقدم Microsoft من إصدار alpha إلى beta إلى الإصدار ، ولن ينجح هذا إلا إذا كان إصدارًا حقيقيًا ، وليس إصدارًا غير مكتمل يسمى "إصدار". وبالتالي ، كان متجر Microsoft فارغًا في الغالب لفترة طويلة جدًا.
• يعمل مهندسو البرمجيات والموظفون الآخرون بشكل أفضل عندما يعملون مقابل أجر معقول وعدد معقول من ساعات العمل وبيئة عمل صحية. من الواضح أن خسارة مايكروسوفت التي تقدر بمليارات الدولارات لن يتم عكسها أبدًا عن طريق استخدام المتعصبين / المتعصبين بدون أجر وما يسمى بـ "وظائف اليوم" و "الوظائف الليلية" وظروف عملهم غير المستدامة / غير الصحية.
• لم يكن فوز Android الضخم في السوق بفضل المتعصبين الذين لم يحصلوا على أجر. إذا كان المتعصبون الذين لا يحصلون على أجر هم سبب الفوز ، فلن يفشل نظام Linux. التفسير أبسط بكثير: سعر أجهزة Android اللوحية والهواتف الذكية أقل بكثير من الأجهزة اللوحية والهواتف الذكية التي تعمل بنظام Windows. من الواضح أن المستخدمين النهائيين لا يهتمون بالأديان / الأيديولوجية "مفتوحة المصدر" (لا يعرف المستخدمون حتى ما هو ذلك) ، بل إنهم ببساطة يحبون الأسعار الرخيصة لأجهزة Android.
• Win16 عفا عليه الزمن للغاية. إنها تقنية منذ 20 إلى 30 عامًا ، منذ أيام البرمجة الأولى "الغرب المتوحش". لذلك ، توقف عن كتابة رمز جديد يعتمد على Win16. تسميته "Win32" لا يغير حقيقة أنه لا يزال أساسًا Win16. Win32 هو نفس الشيء مثل Win16 إلا مع زيادة حجم المؤشرات من 16 بت إلى 32 بت. تستمر مجموعات كثيرة جدًا في Microsoft في كتابة رمز جديد استنادًا إلى Win16 / 32. هذا غير فعال للغاية وإهدار كبير للموارد.

تضمين التغريدة

نحن مهتمون بتخريجها إلى عنصر تحكم WinUI أصلي

راجع أيضًا مقالة ويكيبيديا "تكلفة الغرق" :

تأثير التكلفة الغارقة (أو تأثير الكونكورد) هو حقيقة أن السلوك يتبع غالبًا مغالطة التكلفة الغارقة ؛ يُظهر الأشخاص "ميلًا أكبر لمواصلة مسعى بمجرد الاستثمار في المال أو الجهد أو الوقت". يمكن وصف هذا السلوك بأنه "إلقاء المال الجيد بعد السيئ" ، ورفض الاستسلام له يمكن وصفه بأنه "تقليص الخسائر".

وبالمثل "تحيز استمرارية الخطة" :

إن الانحياز المستمر للخطة ، أو الوصول إلى هناك ، أو الضغط على الأمر هو نزعة غير حكيمة للاستمرار في خطة فاشلة. يعد هذا خطرًا خطيرًا على قباطنة السفن أو طياري الطائرات الذين قد يلتزمون بالدورة المخطط لها حتى عندما يؤدي ذلك إلى كارثة قاتلة ويجب عليهم إجهاضها بدلاً من ذلك. ..... غالبًا ما تعاني المشاريع من تجاوزات التكلفة والتأخير بسبب مغالطة التخطيط والعوامل ذات الصلة بما في ذلك التفاؤل المفرط وعدم الرغبة في الاعتراف بالفشل والتفكير الجماعي والنفور من خسارة التكاليف الغارقة.

تسبب WinRT / UWP في تكبد Microsoft خسارة 900 مليون دولار في السنة الأولى أو الثانية ، ومتجر تطبيقات فارغ لفترة طويلة جدًا. كان WinRT / UWP فشلًا ذريعًا ، وبالتالي كان يجب إجهاضه في السنة الثانية ، لكنه استمر بسبب "تحيز استمرار الخطة" والنفور من خسارة التكاليف الغارقة. يتم تدريس هذه الأشياء في دورات الإدارة. هل أدى استمرار الخطة في النهاية إلى محو أو عكس الفشل الذريع لنظام WinRT / UWP؟ لا ، لا يزال الفشل ذريعًا اليوم إذا نظرت من حيث حصة سوق الهاتف الذكي. هذه الأوصاف في ويكيبيديا تصف بدقة وضع UWP.

اليوم علينا جميعًا أن نتفق على أنه في الوقت الحالي ، بعد 7-8 سنوات من إصدار WinRT / UWP ، فقد فات الأوان الآن لإلغاء UWP ، ولكن هذا يعني أننا سنقع مرة أخرى ضحية "تحيز استمرار الخطة "والنفور من خسارة التكاليف الغارقة.

إذن ما الذي يمكن القيام به بشكل معقول لإنقاذ الموقف؟ لا يمكننا إنقاذ الموقف عن طريق إلغاء UWP ، على الرغم من أنه كان يجب بالتأكيد إلغاؤه منذ سنوات. ما يمكننا القيام به هو هذا: قبول الضرر الهائل الذي أحدثته WinRT ، ولكن لا تتسبب في أي ضرر إضافي ، وإجراء تغييرات على إجراءات / سياسات المشروع. هذا يعني ، التوقف عن تكرار / استمرار نفس أخطاء WinRT الكارثية. على سبيل المثال ، توقف عن إرجاع مثل هذه الكميات الكبيرة من التعليمات البرمجية المُدارة إلى كود "أصلي" قديم وغير مُدار. التأخير في الوصول إلى الحالة التجريبية الحقيقية كبير جدًا بالفعل - لماذا يجعل التأخير أسوأ؟

يستمر خطأ "انحياز استمرارية الخطة" / التكلفة الغارقة إذا تم إرجاع DataGrid إلى رمز "أصلي" غير مُدار. عند حدوث خطأ فادح مثل WinRT / UWP ، يصبح الأمر أسوأ بكثير عندما يتكرر هذا الخطأ نفسه مرارًا وتكرارًا. للحد من الضرر ، من الضروري التوقف عن تكرار نفس الخطأ. لقد حان الوقت حقًا للتعلم من الفشل الذريع لـ WinRT والبدء في وضع الضمادات لوقف فقدان الدم المستمر.

إن تحويل DataGrid إلى تعليمات برمجية غير مُدارة يشبه الذهاب إلى مكتبة واستعارة جميع أفضل كتب إدارة المشاريع من أفضل المؤلفين ذوي المعرفة / الخبرة ، ثم إلقاء كل هذه الكتب الإدارية الممتازة في نار مشتعلة ومشاهدتها تحترق.

verelpode أشعر بالفضول ما هي وجهة نظرك هنا من خلال مشاركتك الكبيرة جدًا التي كتبت DataGrid. أنا شخصياً لا أفهم حقًا ما ورد أعلاه من ردود الفعل على وجه التحديد لتحسين عنصر تحكم OOB DataGrid. الشيء الوحيد الذي حصلت عليه هو أنك قلق من أن تحويله إلى كود أصلي مضيعة للوقت ، لكن هذا لا يعالج أولئك الذين يستخدمون WinUI من C ++. لا يزال لك مطلق الحرية في استخدام التنفيذ المُدار الحالي إذا كنت موافقًا على النفقات العامة لتحميل وقت التشغيل المُدار. يبدو أن كل شيء آخر يتعلق بـ WinRT ونموذج تطبيق UWP ، ولا ينطبق أي منهما حقًا على WinUI ، لأنه أصبح غير مرتبط تمامًا بذلك مع الإصدار 3.

dotMorten - السبب في أنني كتبت تفاصيل إضافية في تلك الرسائل هو أنني إذا لم أشرح المشكلة بشكل كافٍ ، فلن يفهمها الناس. لكن للأسف الآن أرى أن التفاصيل الإضافية فشلت ولم يتم فهمها على أي حال. هذا محبط للغاية. هذا هو السبب الذي يجعل الكثير من الناس لا يكلفون أنفسهم عناء كتابة أي ملاحظات على الإطلاق ، لأنهم يعتقدون أنه من غير المجدي محاولة شرح هذه الأنواع من القضايا للناس ، وحتى إذا تم فهم الرسالة بنجاح ، فمن الطبيعة البشرية تصوير الشخص الذي ينقل الأخبار السيئة ، فمن الأفضل عدم قول أي شيء على الإطلاق ، أو الابتسام "بأدب" مع التفكير في عكس ذلك.

نظرًا لأنه أصبح غير ملتزم تمامًا بهذا الإصدار مع v3.

لا يمنع فك ربط الإصدار 3 هذا تكرار نفس الأخطاء. "الانحياز لاستمرار الخطة" لا يزال قائما.

انتقل إلى الصفحة الرئيسية لـ Microsoft:
https://www.microsoft.com/en-us/
الآن قم بالتمرير لأسفل الصفحة الرئيسية حتى ترى Windows Phone. أوه! انظر إلى ذلك! لقد وصلنا إلى نهاية الصفحة الرئيسية ولم يتم ذكر Windows Phone في أي مكان على صفحة Microsoft الرئيسية! ماذا يعني هذا؟ هذا يعني ، استيقظ. هذا يعني أن UWP كان فشلًا ذريعًا كما قلت. هذا يعني أنه من المهم التوقف عن تكرار نفس الأخطاء التي أدت إلى فشل UWP. يعني ، تغيير الخطة من أجل الإنقاذ والتعافي من الكارثة.
سيكون خطأ إداريًا إذا استمر WinUI و DataGrid في تكرار نفس الأخطاء كما حدث في فشل UWP.

"في مايو 2016 ، أجهضت شركة Microsoft أعمالها المتنقلة ... تطوير التطبيق. "
- https://en.wikipedia.org/wiki/Microsoft_Mobile

تسرد Ana 5 نقاط لتقديم ملاحظات حول Wrt DataGrid. أي من هذه النقاط تعلق عليها؟ أعتقد أن هذا هو الشيء الذي لا أحصل عليه مما تكتبه. UWP لا يلبي حاجة الجميع ، لكن WinUI3 لا يفرض استخدام نموذج تطبيق UWP ، ويبدو أنك في الغالب ضد UWP؟ لذلك يجب أن تكون بخير هناك.

لقد ذكرت أن DataGrid يجب ألا تستمر في ارتكاب نفس الأخطاء التي ارتكبتها. إذن ما هي تلك الأخطاء المكتوبة في DataGrid الموجودة على وجه التحديد ، وكيف تقترح تصحيحها؟ (بصرف النظر عن أنك لا تريد أن يتم تنفيذه في C ++ لسبب ما)

تضمين التغريدة

تسرد Ana 5 نقاط لتقديم ملاحظات حول Wrt DataGrid. أي من هذه النقاط تعلق عليها؟

الجزء الذي اقتبست فيه عن آنا في بداية رسالتي. أعلق على جزء من رسالة آنا التي نقلتها في بداية رسالتي.

لا يفرض WinUI3 استخدام نموذج تطبيق UWP

هذا لا علاقة له برسالتي. كون WinUI 3 غير مقيد ومتاح عبر الحزمة nuget لا علاقة له بمسألة ما إذا كان WinUI 3 يواصل نفس أخطاء الإدارة التي أدت إلى فشل UWP و Windows Phone وخسارة Microsoft بمليارات الدولارات.

كيف تقترح أنه ينبغي تصحيحها؟

النقاط الست في نهاية رسالتي السابقة . تتعلق النقطة الثانية (البرمجة النصية) بـ WinUI و UWP بشكل عام ، ولكنها لا تتعلق بـ DataGrid. النقطة الأولى هي الأهم إذا كنت تسأل على وجه التحديد عن DataGrid.
كتبت أيضًا: توقف عن خفض تصنيف مثل هذه الكميات الكبيرة من التعليمات البرمجية المُدارة إلى كود "أصلي" قديم وغير مُدار. التأخير في الوصول إلى الحالة التجريبية الحقيقية كبير جدًا بالفعل - لماذا يجعل التأخير أسوأ؟

كتب anawishnoff :

نحن مهتمون بتخريجها إلى عنصر تحكم WinUI أصلي

يشكل "تخريجها إلى عنصر تحكم WinUI أصلي" عمليا استمرار / تكرار لبعض الأخطاء نفسها التي أدت إلى "الخسائر في حصة السوق ونقص تطوير التطبيقات" المذكورة في ويكيبيديا:

"في مايو 2016 ، أجهضت شركة Microsoft أعمالها المتنقلة ... تطوير التطبيق. "
- https://en.wikipedia.org/wiki/Microsoft_Mobile

لماذا يجب أن تستمر DataGrid على نفس المسار الذي دمر أعمال الأجهزة المحمولة لشركة Microsoft؟

تضمين التغريدة

يستمر WinUI 3 في نفس الأخطاء الإدارية التي أدت إلى فشل UWP و Windows Phone وخسارة Microsoft بمليارات الدولارات.

أنا لا أعمل لدى Microsoft ولكن لدي فضول لماذا تقول أن WinUI يرتكب أخطاء إدارية.
مما أرى أن حقيقة أن WinUI مفتوحة المصدر وأن الجميع يمكنهم المساهمة في المحادثات والقرارات يساعد في الواقع في تحديد ماهية WinUI ويجب أن يمنع حدوث الأخطاء.
لقد ذكرت أن DataGrid يستمر على نفس المسار مثل الهاتف المحمول ولكن لم أراه يذكر الهاتف المحمول في أي مكان في الملعب. ربما يمكنك الاحتفاظ بملاحظاتك مباشرة حول ما تناقشه هذه المشكلة.
إذا كنت تشعر أن هناك خطوات لسوء الإدارة مع WinUI ، فربما يمكنك إنشاء مشكلة منفصلة تتعلق بمخاوفك ولكني لا أعتقد حقًا أن تعليقاتك لها أي علاقة بالتحكم في DataGrid.

verelpode يرجى الاحتفاظ بتعليقاتك هنا حول الموضوع. إذا كانت لديك مخاوف بشأن WinUI أو UWP بشكل عام ، فيرجى بدء موضوع مناقشة جديد أو الاتصال بي مباشرة (أرسل لي بريدًا إلكترونيًا أو أرسل رسالة مباشرة على twitter). أو يمكنك التفكير في مناقشة موضوع موجود مثل # 717 أو # 1531.

لقد شاركت مخاوفك بشأن إعادة كتابة DataGrid في C ++ ، ولكن في الواقع لم يذكر الاقتراح الأصلي أي شيء عن ذلك. يحاول anawishnoff جمع ملاحظات حول مجموعة ميزات DataGrid. من ناحية التنفيذ ، إذا كان من المنطقي الاحتفاظ بها في C # ، فسنقوم بذلك (ويمكن أن تظل قابلة للاستدعاء من C ++ إذا فعلناها كمكون WinRT).

jevansaks - كانت ملاحظاتي متعلقة بالموضوع ، لكن من الطبيعة البشرية إطلاق النار على الرسول الذي ينقل الأخبار السيئة. ردك يحزنني ويخيب أملي. حسنًا ، سأتوقف عن محاولة المساعدة ، لأن مساعدتي غير مرغوب فيها لأنها صادقة ومباشرة للغاية وتتطرق إلى المشكلات المؤلمة التي يصعب الاعتراف بها وحلها (يثير الفشل الكارثي لـ WinRT الكثير من المشاعر وبالتالي يسهل محوه من الذاكرة واستمر في نفس خطة WinRT الأصلية القديمة كما لو أن الكارثة لم تحدث أبدًا). سأخرج من هذه المناقشة ولن أشارك أكثر في تطوير DataGrid لأن الاستمرار في الحديث بصدق ومباشرة عن المشاكل الحقيقية لن يؤدي إلا إلى إزعاج الناس.

verelpode لا أحد "أطلق النار على الرسول الذي يسلم الأخبار السيئة" هنا. دعاكjevansaks لفتح إصدار جديد لمشاركة مخاوفك الواسعة حول UWP / WinUI / WinRT في هذا المستودع. هذه المشكلة تتعلق فقط بـ DataGrid ، وبينما كان أحد مخاوفك بالفعل حول DataGrid ، كانت الغالبية العظمى حول UWP / WinUI / WinRT بشكل عام. أنا متأكد مما إذا كنت ستنظر إلى هذه المناقشة مرة أخرى ، فسترى أن فريق WinUI يطلب منك فقط إبقاء هذه المشكلة مركزة فقط على اقتراح DataGrid وفتح قضية جديدة / استخدام مشكلة حالية لمخاوفك الأوسع حول برنامج.

يمكن أن تكون المخاوف التي ذكرتها أساسًا لمناقشة شيقة يشارك فيها كل من فريق WinUI والمجتمع ، ولكن هذه المشكلة بالذات ليست مناسبة لمثل هذه المناقشة.

تضمين التغريدة
أنا متأكد من أن Microsoft Pivot Viewer Control لم يكن html. من فضلك انظر الى الوراء كانت القدرة على تصور مجموعات كبيرة من البيانات باستخدام شيء من هذا القبيل شيئًا أردنا القيام به في بعض الأحيان. كان متوفرا في Silverlight على ما أعتقد. https://www.microsoft.com/silverlight/pivotviewer/default# استخدم ميزة Deep Zoom لوظائفها. إضافة إمكانية التكبير العميق إلى WinUI 3.0 سيكون أمرًا رائعًا! ليس Datagrid حقًا ، ولكن عنصر تحكم في عرض البيانات. هناك الكثير من الأفكار "المهجورة" منذ الأيام الأولى لـ WPF مثل Deep Zoom التي لم تتحول أبدًا إلى عنصر تحكم WPF للإنتاج والذي سيكون رائعًا لإعادة الحياة إلى WinUI 3.0 بمرور الوقت. هيك اذهب وأخرج الدكتور WPF من الطابق السفلي واجعله ينشر مرة أخرى !!! نريده أن يعود. نحن بحاجة لبدء الحركة. إحضار د. WPF !!!!! أين ذهبت؟ دكتور وينوي !!!

PaulMontgomerySP يبدو أنه يجب عليك فتح إصدار جديد لمناقشة عنصر التحكم المحوري. لا تتردد في الرجوع إلى المناقشة السابقة التي جرت حول هذا الموضوع من مجموعة أدوات مجتمع Windows هنا: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/770

تم تغيير الحدث المحدد لكل صف أنتقل إليه باستخدام لوحة المفاتيح.
سيكون من الجيد أن يكون لديك حدث فقط من أجل النقر بالماوس أو النقر على الخلية ، بدلاً من الحدث الذي تم تغيير التحديد فقط.

حدث تغيير التحديد النيران لكل من النقر ولوحة المفاتيح. من المفيد جدًا أن يكون لديك حدث للنقر فقط.

@ Going-Gone أنا فضولي ما هي حالة الاستخدام لذلك؟ لماذا تريد معرفة الفرق؟ كما لا يمكنك استخدام الحدث المستغل؟

أحد القيود التي وضعتها للتو مع DataGrid الخاص بـ UWP Toolkit هو أن DataGridTemplateColumn يحتوي على قالب CellTemplate ، لكنه لا يحتوي على CellTemplateSelector (ونفسه مفقود مقابل CellEditingTemplate ). سيؤدي ذلك إلى تبسيط تكييف واجهة المستخدم في كل خلية مع البيانات باستخدام نهج المحدد ، بدلاً من الاضطرار إلى القيام بذلك بمستوى إضافي من عناصر تحكم واجهة المستخدم الموجودة أسفلها للتعامل مع ذلك.

يرجى أيضًا إتاحة إمكانية تحديد الصفوف ليس فقط بترتيب متتالي كما أوضحت بالتفصيل هنا:
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

في أي ترتيب معين للأشياء التي يطلبها العملاء غالبًا والتي يجب أن تدعمها الشبكة

1- القدرة على حفظ وتحميل وبناء الفلاتر. على سبيل المثال ، عامل التصفية إلى تعبير linq ، والتصفية إلى استعلام SQL ، والتصفية إلى شجرة التعبير والعكس. مثال - https://querybuilder.js.org/demo.html

1. إمكانات بيانات الوقت الحقيقي عالية السرعة ، والأداء مهم. معدلات التحديث أقل من 1 مللي ثانية لتطبيق التداول مقابل أكثر من مليون صف لها اعتبارات أداء مختلفة.
2. القدرة على تحديد ترتيب الفرز ، على سبيل المثال i. فرز مرتفع / منخفض ، ثانيا. فرز منخفض / مرتفع وثالثا. لا نوع أو أنا. فرز منخفض / مرتفع ، ثانيا. فرز مرتفع / منخفض وثالثا. بدون فرز
3. تصفية تشبه Excel
4. القدرة على تطبيق تنسيق css على الخلايا ، التنسيق الشرطي
5. القدرة على حفظ / تحميل إعدادات الشبكة بسهولة ، مثل المرشحات وعرض الأعمدة والفرز وما إلى ذلك
6. التمرير الذي يعمل ، على سبيل المثال لا تتم إعادة تعيينه بعد تحديث البيانات ، بسلاسة.
7. يجب أن تحتوي أحداث جمع البيانات على خيارات لإطلاق الأحداث بعد نطاقات التحميل بدلاً من الكائنات الفردية. على سبيل المثال ، أعتقد أن ObservableCollection يتطلب فئة فرعية لمنع إطلاق INotifyPropertyChange لكل كائن فردي تمت إضافته.
8. أحداث أفضل عند تحميل / تحميل البيانات ، بدء تحميل البيانات ، تحميل البيانات ، تحميل البيانات خاصة في حالة استخدام التحميل غير المتزامن.
9. غالبًا ما ترتبط الشبكات بعناصر تحكم أخرى مثل عوامل تصفية البيانات واختيار النطاق والتصفية المتقاطعة (مثل https://github.com/dc-js/dc.js) والمخططات والجداول المحورية وما إلى ذلك.
10. الفرز الذكي الذي يتعامل مع البيانات الأبجدية الرقمية ، مثل ترتيب الفرز ABC11 و ABC12 و ABC111 بدلاً من ABC11 و ABC111 و ABC12
11. مستويات غير محدودة من الشبكات الهرمية ، على سبيل المثال https://docs.telerik.com/devtools/wpf/controls/radgridview/hierarchical-gridview/hierachy-overview

موارد مفيدة: - تصميم جداول بيانات أفضل
https://news.ycombinator.com/item؟id=21460966
https://uxdesign.cc/design-better-data-tables-4ecc99d23356

لن أكون قادرًا على الارتباط بعرض العمود مباشرة من الرأس. في WPF يجب أن أستخدم BindingProxy Object في هذه الحالة.

تغيير الحجم الديناميكي الملائم للصف النشط لتسهيل التحرير.
تحكم كامل في قوائم السياق في وضع التحرير.

آمل أن تدعم CellDecorationStyleSelector كما في Telerik.

إمكانية الوصول!
ذكرها حتى يتم توثيقها ، ولكن يجب أن تكون أداة التحكم هذه قابلة للوصول بالكامل.
يحتوي إصدار مجموعة الأدوات الحالي على بعض القيود في هذا المجال: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3400 & https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079
أيضًا ، بينما يحتوي Telerik RadDataGrid على بعض الميزات الرائعة ، يبدو أنه

مع دفع Microsoft الكبير من أجل D&I ، أنا مندهش من أن الاحتياجات لجميع عناصر التحكم لتكون متاحة بشكل كامل لم يتم تحديدها كمتطلب في كل مكان.

ربما يكون هذا ممكنًا بالفعل ، ولا أعرف كيفية إنجازه بعد ... ولكن ماذا عن: تصميم صف أو خلية مخصص؟

ستكون القدرة على استهداف صف معين ، وتغيير الخلفية ولون النص أمرًا رائعًا.

بالمقارنة مع WCT UWP DataGrid:
1) الأداء
2) المزيد من أنواع الأعمدة المضمنة (أفترض أن هذه لها أداء أفضل من أعمدة القوالب)
3) القدرة على ربط أحداث الماوس في كل خلية ، مثل النقر والضغط بزر الماوس الأيمن والتمرير بالماوس (أو المؤشر لأسفل أو أي شيء آخر)
4) أحداث لوحة المفاتيح لكل خلية
5) إذا كان الرقم (3) غير عملي ، فيمكننا محاكاة ما إذا وصلنا إلى وظيفة الاختبار
6) الأداء

كم عدد الأشخاص الذين سيقدمون اعتراضًا إذا تخلى WinUI DataGrid عن الميزة حيث يمكن للمستخدمين النهائيين تحرير قيم الخلية المضمنة / مباشرة داخل DataGrid؟

هل يتذكر أي شخص VB6؟ دعم VB6 DataGrid التحرير والحذف والإضافة الجديدة خارج منطقة الجزاء. كانت الإضافة متاحة كصف فارغ تمت إضافته تلقائيًا إلى نهاية القائمة. أكمل الصف وسيظهر صف فارغ آخر.

يجب أن يكون لدى DataGrid خيار دعم إدخال البيانات ، حتى إذا كان معظم المطورين يفضلون هذه الميزة على وضع إيقاف التشغيل الافتراضي.

عند نقل تطبيق VB6 إلى UWP ، كان علينا كتابة شبكة البيانات الخاصة بنا لدعم الإضافة / التحرير / الحذف.

يبدو أن معظم الذين يساهمون هنا هم أشخاص WPF / Xaml ، وهذا يساوي سنتان من شخص ليس من رجال xaml.

أستخدم ضوابط DataGrid كثيرًا في برنامجي. التحرير هو المكان المهم! بعض أمنياتي / نقاط الألم هي:

1. القدرة على تخصيص قائمة السياق عندما تكون في وضع التحرير.
2. أداء أفضل ومزيد من التحكم عند تحديد حجم الأعمدة تلقائيًا. أريد أن يكون المستخدم قادرًا على التحكم في الأحجام إذا لزم الأمر ولكن في الغالب لا يحتاج إلى ذلك. لا أريد أن تتغير أحجام الأعمدة باستمرار ، لكنني أريدها بطريقة ما أن تستند إلى البيانات دون الحاجة إلى قياس ما يعادل مليون صف من البيانات.
3. عند التحرير ، أريد أن أكون قادرًا على النقر فوق عنصر تحكم / زر مختلف يقوم بشيء ما (أو باستخدام) البيانات التي يتم تحريرها دون إنهاء التعديل. (سيكون هذا أقل أهمية إذا تم تنفيذ رقم 1 - رغم أنه لا يزال مفيدًا.)
4. الطريقة الحالية للتعامل مع الاستثناءات باستخدام حدث DataError تقريبية. (آسف ، أواجه مشكلة في تحديد هذا الأمر ، لكنني أعلم أنه تسبب لي في الألم عدة مرات في الماضي.)
5. ستكون إمكانية التمرير التلقائي المدمجة رائعة: http://stackoverflow.com/questions/2567809/how-to-autoscroll-a-datagridview-during-drag-and-drop
6. القدرة على عرض "علامة مائية" تشير عندما تكون البيانات "قذرة" (انظر BetterGrid للحصول على بعض التحسينات المفيدة الإضافية إلى DataGridView.
7. القدرة على التخلي عن صف (بدون خطأ في التحقق من الصحة) عندما تُترك خلية "المفتاح" المطلوبة فارغة.
8. قدرة مضمنة على عدم عرض أي صورة (بدلاً من علامة X حمراء) لصف أضافه المستخدم. انظر: https://stackoverflow.com/questions/937919/datagridviewimagecolumn-red-x
9. السماح لعمود خانة الاختيار بالالتزام فورًا عند التغيير: https://stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

متى يتوقع إصدار ألفا؟ هل ستكون مفتوحة للمساهمات؟ محاولة التخلص من شبكة البيانات القديمة والتطلع حقًا إلى ذلك ، وخاصة ميزة المحاكاة الافتراضية.

آسف لوضع إدخال متأخر جدًا في هذا الموضوع ، لكنه بالنسبة لي "جديد" ؛)
_ تم تعديله بعد معرفة المزيد عن سلوك عنصر التحكم_

أثناء العمل مع DataGrid من أجل إنشاء مستكشف مثل واجهة محركات الأقراص السحابية ، وجدت أن تحديد الصف والخلية التي يتم النقر عليها قد يكون أكثر تعقيدًا مما يجب أن يكون (IMHO)

في تصميم تطبيقي ، تمثل الصفوف الملفات أو المجلدات (DriveItems). يُظهر عرض التفاصيل مزيدًا من التفاصيل حول العنصر.

كنت أرغب في إنشاء إمكانية للنقر فوق عنصر مجلد ، وجعل الواجهة تقفز وإنشاء قائمة بهذه العناصر ، مما يسمح بالتنقل في جميع أنحاء محرك الأقراص.

على سبيل المثال ، إذا قمت بالنقر فوق إدخال العمود "الأصل" الخاص بالعنصر ، /drive/root:/Documents/Vital%20Documents هنا ، فستتم إعادة تعيين الواجهة إلى هذا المجلد وتسرد الملفات هناك.

على الرغم من أنه يمكن للمرء الحصول على حدث تم النقر فوقه للخلية ، إلا أنه لا يبدو أن هذا الحدث يحتوي على سياق المعالج لتحديد الخلية التي تم النقر عليها (صف ، نعم ، ولكن ليس عمودًا) ، ولست متأكدًا من أن سيسمح لي عنصر التحكم بالحصول على سلوك نقر الخلية وسلوك التفاصيل المفتوحة تلقائيًا (لا يزال التحقيق فيما قد أسميه "الاختراقات" التي من شأنها أن تسمح بذلك ، ولكن علينا أن نذكر أنفسنا أنه عندما يبدأ المصممون في تجاوز الأداء الطبيعي لعنصر التحكم ، خاصةً ليست سلوكيات موثقة ، فهم يخاطرون بتعطل التصميم بسبب التغييرات في سلوك عنصر التحكم.

بعد كل ما قيل ، يبدو أن DataGrid تدعم السيناريو الخاص بي من خلال جعل الحدث الذي يقوم حاليًا بإرجاع DriveItem كـ CurrentItem ، يجب أن يتضمن أيضًا CurrentColumn والذي سيكون الكائن DataGridColumn بالكامل الذي تم النقر عليه بداخله ، من خلال والذي سيكون من الممكن استخراج اسم العمود. أدرك الآن أن لدينا كائن CurrentColumn الذي يمكننا التحقيق فيه من الحدث ، لذلك ، على الرغم من أنني أرغب في ذلك بشكل أفضل كما هو متوقع ، يجب أن يعمل هذا.

أيضًا ، قد يكون التحكم الأكثر صرامة في سلوك التفاصيل هو أن التفاصيل لن يتم توسيعها تلقائيًا إلا بناءً على النقر فوق عمود معين ، بدلاً من التوسيع كلما نقر أحدهم في أي مكان في الصف.

ربما الفئة الأساسية من DataGridColumn كائن يمكن أن يكون له ExpandDetails الممتلكات التي يمكن تعيينها إلى true افتراضيا لكل عمود، وهو ما يعني أن عمود معين يتم النقر على أسباب الخلاف في التوسع. البعض الآخر حيث الخاصية خاطئة لن تكون كذلك.

في تصميمي ، على سبيل المثال ، العمود الأول هو نوع العنصر ، كما هو الحال في ملف أو مجلد ، أو صورة أو صورة ، أو صوت ، وما إلى ذلك. قد أتصور أن يكون هذا العمود هو العمود الوحيد الذي يتسبب في سلوك التوسيع التلقائي ، ثم النقر فوق عمود المسار قد يتسبب في حدوث سلوك "الحصول على قائمة بهذا المسار" الذي وصفته أعلاه.

بالنسبة للفرز ، قد يبدو من المهم منطقيًا تنفيذ تحكم كافٍ للسماح للمصممين بالحصول على فرز متعدد المستويات. لم أقم بالتحقيق لتحديد كيف يمكن لعنصر التحكم الحالي أن يدعم ذلك من خلال ربط / تجاوز الأحداث وعمليات رد الاتصال ، لكن الأمر لا يبدو واضحًا.

أخيرًا ، أعلم أنك تدرك جيدًا هذا ، ولكن (حتى عندما أطلب المزيد من الوظائف) ، دعنا نتجنب محاولة إضافة مجموعة من السلوكيات المعقدة التي يمكن للمستخدمين تنفيذها بأنفسهم فوق DataGrid. من بين هذه الأشياء التي لن أستخدمها في DataGrid ، هناك أي منها يتعلق بتخزين عوامل التصفية أو الأنواع خارجيًا ، وما إلى ذلك. كما أنني أتجنب جعل عنصر التحكم هذا في نسخة Excel.

-شكرا ، عمل رائع!
-e

المجموعات الثابتة: عند تصفح مجموعات البيانات ذات المجموعات الكبيرة ، يجب أن يكون هناك سياق حول المجموعة (أو المجموعات ، مثل مسار التنقل) التي يتم عرضها. يبدو أن هذا ميزة أساسية لقابلية الاستخدام لجميع طرق العرض الهرمية القائمة على القوائم: طرق عرض القائمة المجمعة ومخازن البيانات وطرق عرض الشجرة.

أود إنشاء عنصر تحكم DataGrid الجديد أعلى عنصر تحكم WinUI ItemsRepeater الجديد. ويكشف هذا التحكم مصدر العناصر الخاص به ككائن:
Object ItemsSource { get; set; };

RBrid العودة إلى هذا ~ بعد عام واحد. أدركت أن ItemsRepeater ، على الرغم من أنها تحتوي على كائن ItemsSource ، إلا أنها لا تحتوي فعليًا على دعم مضمن للواجهات التالية الضرورية للعمل مع مصادر البيانات الافتراضية:

• دعم التحميل الإضافي
• IItemsRangeInfo
• ISelectionInfo

-ماذا عن الحصول على MVP هناك الآن حتى نتمكن من استخدام Datagrid من c ++.