अधिक दृश्य मोड। फ़ाइल एक्सप्लोरर और उसके चिह्न दृश्य पर एक नज़र डालें। डेटाग्रिड समूहीकरण के साथ-साथ शीर्ष पंक्तियों और स्तंभों के साथ ग्रिड में आइकन/आइटम दिखाने में सक्षम होना चाहिए।

मुझे पता है कि यह संभव नहीं हो सकता है, या दायरे से बाहर हो सकता है - लेकिन यह WinUI बनाम Win32 का एक पहलू है जो 1: 1 जितना आसान नहीं है - और फ़ाइल एक्सप्लोरर का एक आधुनिक संस्करण, या सामान्य फ़ाइल संवाद - की आवश्यकता हो सकती है इस तरह के नियंत्रण का। यह वह नियंत्रण हो सकता है, आंतरिक कस्टम नियंत्रण नहीं।

मेरी इच्छा सूची : मेरे लिए एक अच्छे डेटाग्रिड में डिफ़ॉल्ट रूप से निम्नलिखित सभी विशेषताएं शामिल होती हैं। मैं html दुनिया से कुछ स्क्रीनशॉट उधार ले रहा हूँ।

पसंदीदा पंक्ति गणना के साथ पूरे पृष्ठ को आसान फ़िल्टर करें।

दृश्यमान कॉलम, कॉलम सॉर्टिंग, कॉपी, प्रिंट . का चयन / चयन रद्द करें

विशिष्ट प्रारूप में डेटा निर्यात करें।

स्तंभ खींचकर स्तंभ पुन: क्रमित करना।

कॉलम फ़िल्टरिंग

फिक्स्ड हैडर - जहां स्क्रॉल करते समय भी हेडर शीर्ष पर रहता है

विवरण के लिए एक्सएएमएल टेम्पलेट के साथ पंक्ति विवरण।

पंक्ति समूहन

पंक्ति क्रम खींचें और छोड़ें

मेरी राय में उपरोक्त विशेषताएं सभी डेटाग्रिड में मानक होनी चाहिए।

यदि आप डेटाग्रिड को html की दुनिया से अलग बनाना चाहते हैं तो मैं निम्नलिखित को भी शामिल करूंगा। मैं खुद को कई बार डेटाग्रिड को देखता हूं और फिर एक सूचीदृश्य पर बसता हूं क्योंकि डेटाग्रिड में इन सुविधाओं की कमी होती है।

संपादित करें, हटाएं, ध्वज आदि जैसी सुविधाओं को शामिल करने के लिए पंक्ति को साइड स्वाइप करें।

उपरोक्त विशेषताएं मुख्य रूप से "डेटा की प्रस्तुति" को संभालती हैं, जो अभी भी WinUI से कमी है, वह है जो मेरा मानना ​​​​है कि Microsoft Pivot Control की तरह एक मूल WinUI सुविधा (नियंत्रण) होनी चाहिए

एमएस के पास पहले से ही इसके लिए स्रोत कोड है और यह उन दिनों में एक पूर्ण भयानक नियंत्रण था।

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

अब आप डेटा की प्रस्तुति और विज़ुअलाइज़ेशन को कवर करते हैं जो कि WinUI को सभी मूलभूत सुविधाओं से अलग करने के लिए न्यूनतम होना चाहिए।

सबसे महत्वपूर्ण बात यह है कि यह वास्तव में "देशी ऐप्स" की शक्ति को प्रदर्शित करता है जिसमें भयानक एनिमेशन और नेत्रहीन आकर्षक नियंत्रण शामिल होना चाहिए जो शक्तिशाली है और वास्तव में अच्छा दिखता है।

मैं इसे एक कदम आगे ले जा सकता हूं और कह सकता हूं कि उपरोक्त सुविधाओं (विज़ुअलाइज़ेशन) के बाद हम 2 डी / 3 डी एनिमेशन शामिल कर सकते हैं जो डेटा में गहराई की अवधारणा बनाता है और हमें एक अलग समताप मंडल में ले जाएगा, लेकिन मुझे लगता है कि यह एक और दिन के लिए है; ))

एक अच्छा प्रारंभिक बिंदु आपके पार्टनर टेलीरिक को उनके रेडडाटाग्रिड (यूडब्ल्यूपी ओपन सोर्स) के साथ देख रहा है। अपने ग्राहकों में से एक के साथ, मैंने इसका इस्तेमाल किया और यह वास्तव में अच्छी तरह से काम करता है। यह हाइपर फास्ट और बहुमुखी है। केवल एक चीज जो कठिन है वह है उनका कोड, आर्किटेक्चर की अच्छी समझ के बिना उनके इंजन से कुछ भी संशोधित करने का कोई तरीका नहीं है।

मैं उम्मीद करता हूं कि नया डेटाग्रिड टेलीरिक के रूप में प्रदर्शनकारी होगा।

मुझे यह देखकर बहुत खुशी हुई कि WinUI टीम डेटाग्रिड नियंत्रण पर विचार कर रही है।

टूलकिट डेटाग्रिड को बदलने के लिए मैं एक नए नियंत्रण से सबसे महत्वपूर्ण सुधार देखना चाहता हूं:

• अनुक्रमणिका द्वारा DataGridRow पुनर्प्राप्त करने की क्षमता
• DataGridRows के लिए विशिष्ट ईवेंट स्वयं। उदाहरण के लिए, डबलटैप्ड और राइटटैप्ड।
• स्मूद स्क्रॉलिंग
• सेल नामों के लिए इनपुट सत्यापन
• एक DataGridColumn विशेष रूप से पंक्ति चिह्नों के लिए डिज़ाइन किया गया
• रंगों का आसान अनुकूलन, आदि।

एक संपादन बटन रखने का विकल्प जो ऑर्डर को स्थानांतरित करने के लिए प्रत्येक पंक्ति के बगल में खींचने योग्य आइकन रखता है, एक उपयोगी सुविधा होगी। यह भी बहुत अच्छा होगा कि पंक्ति के पीछे की कुछ छायाओं को ऊपर उठाया और स्थानांतरित किया जाए (चूंकि मुख्य धाराप्रवाह विशेषताओं में से एक गहराई है)। माउस इनपुट के साथ पंक्तियों को अधिक आसानी से स्थानांतरित करने के लिए ड्रैगिंग आइकन के बगल में छोटे ऊपर और नीचे तीर अच्छे हो सकते हैं। यदि तीरों का उपयोग करके एक पंक्ति को स्थानांतरित किया जाता है, तो एक सूक्ष्म स्लाइडिंग एनीमेशन एक अच्छा स्पर्श होगा। टच इनपुट के साथ, एक पंक्ति को होल्ड करने और एडिट बटन दबाने की आवश्यकता के बिना इसे स्थानांतरित करने का विकल्प भी अच्छी तरह से काम कर सकता है। मुझे यकीन नहीं है कि यह पहले से ही समर्थित है, लेकिन मैं फ़ाइल एक्सप्लोरर जैसे चयन चेक बॉक्स देख सकता हूं जो स्पष्ट करता है कि कौन सा डेटाग्रिड पंक्ति चयन का समर्थन करता है और केवल समग्र यूएक्स में सुधार करता है। आईओएस रिमाइंडर ऐप में इनमें से कुछ विचार हैं (उदाहरण नीचे चित्रित)। IOS स्टॉक्स ऐप में भी चल पंक्तियों के साथ इसी तरह का सौदा होता है। इनमें से अधिकतर विचार कॉलम के लिए भी बहुत अच्छे काम करेंगे।

@NoahFeller उस प्रकार की कार्रवाई सूची दृश्य के लिए अधिक समझ में आती है। ग्रिड व्यू के साथ आप ऑर्डर को पुनर्व्यवस्थित नहीं कर रहे हैं, सॉर्ट विकल्प होना चाहिए लेकिन उपयोगकर्ता चीजों को इधर-उधर नहीं खींच रहा है।

*संपादित करें
इसके बारे में थोड़ा और सोचने के बाद, मैं देखता हूं कि ऐसा विकल्प कैसे उपयोगी हो सकता है। हालांकि, मुझे निश्चित रूप से नहीं लगता कि यह डिफ़ॉल्ट व्यवहार होना चाहिए।

@NoahFeller उस प्रकार की कार्रवाई सूची दृश्य के लिए अधिक समझ में आती है। ग्रिड व्यू के साथ आप ऑर्डर को पुनर्व्यवस्थित नहीं कर रहे हैं, सॉर्ट विकल्प होना चाहिए लेकिन उपयोगकर्ता चीजों को इधर-उधर नहीं खींच रहा है।

*संपादित करें
इसके बारे में थोड़ा और सोचने के बाद, मैं देखता हूं कि ऐसा विकल्प कैसे उपयोगी हो सकता है। हालांकि, मुझे निश्चित रूप से नहीं लगता कि यह डिफ़ॉल्ट व्यवहार होना चाहिए।

हाँ आप शायद सही कह रहे हैं @yaichenbaum। मैं उन सुझावों को एक कस्टम सॉर्ट करने की क्षमता के रूप में देख रहा था और मुझे लगा कि इसके लिए ड्रैगिंग उपयोगी हो सकती है। तो मैं सहमत हूं, निश्चित रूप से डिफ़ॉल्ट नहीं है लेकिन यह एक विकल्प के रूप में बहुत उपयोगी हो सकता है। प्रतिपुष्टि के लिए धन्यवाद!

डेटाग्रिड फ़ंक्शन के लिए डेटाटेबल डब्ल्यूपीएफ की सादगी। मैं वास्तव में पिछले हफ्ते से लड़ रहा हूं या इसलिए काम करने के लिए यूडब्ल्यूपी डाटाग्रिड प्राप्त करने की कोशिश कर रहा हूं कि मेरे पास यह डब्ल्यूपीएफ में कैसे था जहां मैं डेटाग्रिड को डेटाव्यू में बांध सकता था, फिर डेटाव्यू को डेटाटेबल के साथ एसक्यूएल से भर सकता था। डिफॉल्टव्यू। ग्रिड ने तब डेटा तालिका प्रदर्शित की। यह करना आश्चर्यजनक रूप से सरल था, और UWP ने अब तक इसे हास्यास्पद रूप से जटिल बना दिया है।

इसे क्रॉस प्लेटफॉर्म बनाएं

मैं सिंगल सेल सिलेक्शन मोड, एक्सेल स्टाइल का अनुरोध करना चाहूंगा।
अंतिम लक्ष्य WinForms DataGridView के सटीक व्यवहार के साथ एक मोड है।

वर्चुअलाइजेशन विकल्पों का एक वर्गीकरण होना जो विभिन्न उपयोग के मामलों का समर्थन कर सकता है (सादे स्क्रॉलिंग वर्चुअलाइजेशन विकल्पों जैसे रीसाइक्लिंग से लेकर डेटा पेजिंग जैसी अन्य अवधारणाओं तक)
अक्सर (इसका समर्थन करने वाले समान डेस्कटॉप नियंत्रणों में) अद्वितीय डेटा वाले स्तंभों के लिए कस्टम टेम्प्लेट के साथ उपयोग किए जाने पर इनमें से कुछ विकल्प विफल होने लगते हैं। उन मामलों में वे जितना अधिक समर्थन कर सकते हैं, उतना अच्छा है।

यदि संभव हो तो, पेजिंग कंट्रोल #268 प्रस्ताव को सिंक किया जाना चाहिए, और किसी भी आवश्यक हुक को डेटाग्रिड नियंत्रण में जोड़ा जाना चाहिए।

यह अच्छी खबर है! समुदाय टूलकिट में दिखाई देने के बाद से मैं कुछ समय से डेटाग्रिड के मोर्चे पर किसी आधिकारिक चीज़ की प्रतीक्षा कर रहा था। यह वास्तव में WinUI 3.0 से गायब अंतिम नियंत्रण है जिसके लिए समुदाय टूलकिट के पास कोई अच्छा विकल्प नहीं है।

सबसे पहले, कृपया, पहिया को फिर से न लगाएं। आधार के रूप में डेटाग्रिड के डब्ल्यूपीएफ कार्यान्वयन के साथ शुरू होता है (मुझे पता है कि आप कोड का उपयोग नहीं कर सकते हैं लेकिन कृपया एपीआई का 100% उपयोग करें) - सिल्वरलाइट नहीं। डब्ल्यूपीएफ डाटाग्रिड अधिक फीचर-पूर्ण था और मेरे परीक्षण में कम बग हैं।

सामुदायिक टूलकिट डेटाग्रिड का उपयोग करने में मैंने निम्नलिखित एपीआई परिवर्धन का भी अनुरोध किया जो विभिन्न उपयोग के मामलों के लिए यहां चर्चा में आए :

• RowPressed : जैसा कि ऊपर चर्चा की गई है। इंगित करता है कि एक पंक्ति को दबाया गया है ताकि आगे की प्रक्रिया या संदर्भ मेनू हो सके।
• RowDoublePressed : RowPressed के समान, बस डबल क्लिक संस्करण।
• ColumnHeaderPressed : जब भी कोई कॉलम हेडर दबाया जाता है तब होता है। किसी भी प्रकार की दिशा के आंतरिक अद्यतनों को प्राथमिकता देनी चाहिए। यह कस्टम फ़िल्टरिंग मेनू या कॉलम को चालू/बंद करने के लिए राइट क्लिक विकल्पों की अनुमति देगा।
• ColumnHeaderDoublePressed : ColumnHeaderPressed के समान, बस डबल क्लिक संस्करण।
• ColumnHeaderWidthChanged : तब होता है जब उपयोगकर्ता कॉलम हेडर की चौड़ाई का आकार बदलता है। यह इस जानकारी को साफ तरीके से सहेजने की अनुमति देगा। UI स्थिति को पुनर्स्थापित करते समय आमतौर पर इसकी आवश्यकता होती है।

आइटम्ससोर्स बदलने के बाद मुझे समुदाय के साथ बहुत सी समस्याएं आती हैं, डेटाग्रिड स्क्रॉल स्थिति को शीर्ष पर रीसेट कर रहा है। इसे ठीक करने की आवश्यकता है ताकि ऑफ़सेट को डब्ल्यूपीएफ की तरह संरक्षित किया जा सके; हालाँकि, हमें इसे नियंत्रित करने में सक्षम होने की भी आवश्यकता है, इसलिए मैं निम्नलिखित एपीआई का भी सुझाव दूंगा:

• FirstRowInView() : राज्य को पुनर्स्थापित करने के लिए प्रयुक्त डेटाग्रिड में दिखाई देने वाली पहली पंक्ति देता है।
• VerticalOffset : स्क्रॉलबार की स्थिति को पुनर्स्थापित करने के लिए फिर से प्राप्त करें/सेट करें
• क्षैतिज ऑफसेट: स्क्रॉलबार की स्थिति को पुनर्स्थापित करने के लिए प्राप्त/सेट करें

@RBrid ने यहां कुछ विश्लेषण में भी मदद की:

सुझाए गए नए इवेंट और पहले से मौजूद इवेंट में कुछ सुधार:

| घटना | टिप्पणियाँ |
| :--- | :--- |
| ContextRequestedForColumnHeader | स्तंभ शीर्षलेख पर राइट-क्लिक किए जाने पर संदर्भ मेनू (या अन्य फ़्लायआउट) दिखाने में सहायता के लिए। Windows.UI.Xaml.UIElement.ContextRequested लेकिन संपूर्ण डेटाग्रिड के बजाय कॉलम हेडर के लिए। |
| ContextCanceledForColumnHeader | Windows.UI.Xaml.UIElement.ContextCanceled लेकिन संपूर्ण डेटाग्रिड के बजाय कॉलम हेडर के लिए। |
| ContextRequestedForRow | किसी पंक्ति पर राइट-क्लिक करने पर संदर्भ मेनू (या अन्य फ़्लायआउट) दिखाने में सहायता के लिए। Windows.UI.Xaml.UIElement.ContextRequested लेकिन संपूर्ण डेटाग्रिड के बजाय पंक्तियों के लिए। |
| ContextCanceledForRow | Windows.UI.Xaml.UIElement.ContextCanceled लेकिन संपूर्ण डेटाग्रिड के बजाय पंक्तियों के लिए। |
| RowTapped | पहले से चुनी गई पंक्ति को टैप करने के मामले पर भी ध्यान दें। |
| RowDoubleTapped | Windows.UI.Xaml.UIElement.DoubleTapped लेकिन संपूर्ण डेटाग्रिड के बजाय पंक्तियों के लिए। |
| RowRightTapped | Windows.UI.Xaml.UIElement.RightTapped लेकिन संपूर्ण डेटाग्रिड के बजाय पंक्तियों के लिए। ContextRequestedForRow भी देखें। |
| PointerPressedInRow | Windows.UI.Xaml.UIElement.PointerPressed लेकिन संपूर्ण डेटाग्रिड के बजाय पंक्तियों के लिए। |
| PointerReleasedInRow | Windows.UI.Xaml.UIElement.PointerReleased लेकिन संपूर्ण डेटाग्रिड के बजाय पंक्तियों के लिए। |
| PointerMovedInRow | Windows.UI.Xaml.UIElement.PointerMoved लेकिन संपूर्ण डेटाग्रिड के बजाय पंक्तियों के लिए। संभवतः PointerMovedInRow केवल तभी ट्रिगर होगा जब पॉइंटर कैप्चर किया जाएगा। |
| ColumnHeaderTapped | पहले से चयनित कॉलम हेडर को टैप करने के मामले पर भी ध्यान दें। |
| ColumnHeaderDoubleTapped | Windows.UI.Xaml.UIElement.DoubleTapped लेकिन संपूर्ण डेटाग्रिड के बजाय कॉलम हेडर के लिए। |
| ColumnHeaderRightTapped | Windows.UI.Xaml.UIElement.RightTapped लेकिन संपूर्ण डेटाग्रिड के बजाय कॉलम हेडर के लिए। ContextRequestedForColumnHeader भी देखें। |
| ColumnHeaderWidthChanged | वैकल्पिक रूप से नाम दिया जा सकता है ColumnHeaderResized । घटना args में, एक बूलियन गुण शामिल करें जो निर्दिष्ट करता है कि क्या यह उपयोगकर्ता द्वारा बदला गया था बनाम प्रोग्रामेटिक रूप से बदला गया था। स्पष्ट रूप से घटना तर्कों को यह भी निर्दिष्ट करना चाहिए कि कौन सा कॉलम हेडर का आकार बदला/बदला गया था। |
| SortOrderChanged | जब चयनित कॉलम हेडर की सूची बदलती है तो ट्रिगर किया जाना चाहिए। जब किसी भी चयनित कॉलम को आरोही बनाम अवरोही क्रम के बीच स्विच किया जाता है, तो भी ट्रिगर होता है। ईवेंट args में, एक बूलियन प्रॉपर्टी शामिल करें जो निर्दिष्ट करती है कि उपयोगकर्ता द्वारा सॉर्ट ऑर्डर बदल दिया गया था या प्रोग्रामेटिक रूप से बदला गया था। पहले से मौजूद ईवेंट Sorting भी देखें। मुझे लगता है कि एक नया ईवेंट SortOrderChanged ट्रिगर होने के बाद Sorting ईवेंट ट्रिगर हो जाएगा, अगर सॉर्टिंग रद्द नहीं की जाती है। |
| Sorting | पहले से मौजूद है, लेकिन ईवेंट आर्ग्स में एक सेटटेबल बूलियन प्रॉपर्टी जोड़ने पर विचार करें जो सॉर्टिंग अनुरोध को रद्द करने की अनुमति देता है। उदाहरण के लिए, सॉर्टिंग अमान्य हो सकती है या निष्पादित करने में असमर्थ हो सकती है और इसे रद्द करने की आवश्यकता है। यह निर्दिष्ट करने के लिए एक बूलियन गुण भी जोड़ें कि उपयोगकर्ता बनाम प्रोग्रामेटिक रूप से सॉर्टिंग का अनुरोध किया गया था या नहीं। |
| ColumnSortDirectionChanged | यह ईवेंट बनाया जा सकता है लेकिन यह अनावश्यक हो सकता है यदि उपरोक्त SortOrderChanged ईवेंट बनाया जाता है, यदि सॉर्ट-दिशा में परिवर्तन होने पर SortOrderChanged भी ट्रिगर होता है। |
| ColumnDisplayIndexChanged | पहले से मौजूद है लेकिन कृपया एक बूलियन संपत्ति जोड़ने पर विचार करें (ईवेंट args में) जो निर्दिष्ट करता है कि क्या इसे उपयोगकर्ता द्वारा बदला गया था बनाम प्रोग्रामेटिक रूप से बदला गया था। साथ ही, कृपया दस्तावेज़ करें कि ColumnDisplayIndexChanged और ColumnReordered ईवेंट का होना क्यों आवश्यक है। वैकल्पिक रूप से, इनमें से किसी एक घटना को समाप्त करें। |
| ColumnReordered | पहले से मौजूद है लेकिन कृपया एक बूलियन संपत्ति जोड़ने पर विचार करें जो निर्दिष्ट करती है कि क्या इसे उपयोगकर्ता द्वारा बदला गया था बनाम प्रोग्रामेटिक रूप से बदला गया था। |
| SelectionChanged | पहले से मौजूद है लेकिन कृपया एक बूलियन संपत्ति जोड़ने पर विचार करें (ईवेंट args में) जो निर्दिष्ट करता है कि क्या इसे उपयोगकर्ता द्वारा बदला गया था बनाम प्रोग्रामेटिक रूप से बदला गया था। |
| CopyingRowClipboardContent | पहले से मौजूद है, लेकिन कृपया ईवेंट args में एक बूलियन प्रॉपर्टी जोड़ने पर विचार करें जो निर्दिष्ट करता है कि कॉपी के बजाय ऑपरेशन काटा गया है या नहीं। वैकल्पिक रूप से कट के लिए एक अलग कार्यक्रम बनाएं। |
| CuttingRowClipboardContent | मौजूद नहीं है। जब उपयोगकर्ता पंक्तियों को काटने का प्रयास करता है (कंट्रोल-एक्स हॉटकी, संदर्भ मेनू, या अन्यथा के माध्यम से) ट्रिगर होने वाली घटना बनाने पर विचार करें। वैकल्पिक रूप से उपरोक्त बूलियन संपत्ति बनाएं जो CopyingRowClipboardContent को कॉपी और कट ऑपरेटोइन दोनों के लिए ट्रिगर करने की अनुमति देगी |
| PastingRowClipboardContent | मौजूद नहीं है। एक ऐसी घटना बनाने पर विचार करें जो तब ट्रिगर होती है जब उपयोगकर्ता पेस्ट करने का प्रयास करता है (कंट्रोल-वी हॉटकी, संदर्भ मेनू, या अन्यथा के माध्यम से)। |

मुझे लगता है कि मेरे लिए सबसे महत्वपूर्ण विशेषता लाखों पंक्तियों को स्मृति में लोड किए बिना आसानी से एक लाख पंक्तियों या अधिक को संभालने की क्षमता होगी। ISupportIncrementalLoading इंटरफ़ेस इसके लिए पर्याप्त नहीं है, क्योंकि स्क्रॉल बार केवल यह दर्शाता है कि आपने अब तक कितनी पंक्तियों को लोड किया है (कुल गणना नहीं), और पंक्ति 1 मिलियन तक पहुंचने के लिए, आपको अंत तक स्क्रॉल करते रहना होगा। और अधिक से अधिक डेटा लोड करें, और आशा करें कि मेरी स्मृति समाप्त नहीं होगी। लेकिन अगर मुझे पता है कि मेरे पास 1 मिलियन डेटा रिकॉर्ड हैं, तो मैं डेटाग्रिड को बता दूं, और अगर मैं तेजी से स्क्रॉल करता हूं या अंत तक कूदता हूं, तो मुझे केवल अंतिम कुछ पंक्तियां प्रदान करने के लिए कहा जा सकता है।
डेटाबेस में पंक्तियों की एक सूची के माध्यम से स्क्रॉल करने के बारे में सोचें जिसे मैं गतिशील रूप से खींचूंगा।

मुझे लगता है कि मेरे लिए सबसे महत्वपूर्ण विशेषता लाखों पंक्तियों को स्मृति में लोड किए बिना आसानी से एक लाख पंक्तियों या अधिक को संभालने की क्षमता होगी। ISupportIncrementalLoading इंटरफ़ेस इसके लिए पर्याप्त नहीं है, क्योंकि स्क्रॉल बार केवल यह दर्शाता है कि आपने अब तक कितनी पंक्तियों को लोड किया है (कुल गणना नहीं), और पंक्ति 1 मिलियन तक पहुंचने के लिए, आपको अंत तक स्क्रॉल करते रहना होगा। और अधिक से अधिक डेटा लोड करें, और आशा करें कि मेरी स्मृति समाप्त नहीं होगी। लेकिन अगर मुझे पता है कि मेरे पास 1 मिलियन डेटा रिकॉर्ड हैं, तो मैं डेटाग्रिड को बता दूं, और अगर मैं तेजी से स्क्रॉल करता हूं या अंत तक कूदता हूं, तो मुझे केवल अंतिम कुछ पंक्तियां प्रदान करने के लिए कहा जा सकता है।
डेटाबेस में पंक्तियों की एक सूची के माध्यम से स्क्रॉल करने के बारे में सोचें जिसे मैं गतिशील रूप से खींचूंगा।

इस।

'मॉडर्न' का अर्थ है हल्का और तेज़, और एंटरप्राइज़ ऐप्स आमतौर पर उचित रिकॉर्ड खोजने और तलाशने के लिए टन के आंतरिक डेटा के माध्यम से सॉर्ट करने के बारे में हैं। पेजिंग, सॉर्टिंग, एसिंक्स इंक्रीमेंटल लोडिंग, अंतहीन स्क्रॉलिंग - ये सभी डेस्कटॉप ऐप के स्टेपल हैं जो डेटा ग्रिड का लाभ उठाते हैं।

एमएस को एक नमूना ऐप तैयार करना चाहिए जो इन सुविधाओं को नए ग्रिड में हाइलाइट करता है और इन अनुभवों को बेहतर बनाने के लिए समय के साथ एंटरप्राइज़ डेवलपर्स से फीडबैक एकत्र करता है। क्या इसकी प्रभावशीलता प्रदर्शित करने के लिए वर्ल्ड वाइड इंपोर्टर्स जैसे बड़े डेटासेट से बाहर चला गया है।

@dotMorten

मुझे लगता है कि मेरे लिए सबसे महत्वपूर्ण विशेषता लाखों पंक्तियों को स्मृति में लोड किए बिना आसानी से एक लाख पंक्तियों या अधिक को संभालने की क्षमता होगी।

मेरी भी यही कामना है। एक लाख पंक्तियों का समर्थन करने में सहायता करने के लिए (और मेरा मतलब है सहायता, जरूरी नहीं कि पूर्ण समाधान), मेरा सुझाव है कि डेटाग्रिड को अपनी वर्तमान डेटा-बाइंडिंग तकनीक को वैकल्पिक बनाना चाहिए। मेरा मानना ​​है कि वर्तमान में डेटा-बाइंडिंग अनिवार्य है (जब तक कि मेरा ज्ञान डेटाग्रिड के नवीनतम संस्करण के साथ अद्यतित नहीं है)। डेटाग्रिड को Windows.UI.Xaml.Data.Binding उपयोग की आवश्यकता नहीं होनी चाहिए क्योंकि प्रत्येक दृश्यमान पंक्ति में प्रत्येक सेल/कॉलम के मानों को पुनर्प्राप्त करने का एकमात्र समर्थित तरीका है।

मेरा सुझाव है कि डेटाग्रिड ऐप्स को डेटाग्रिड को एक प्रतिनिधि या इंटरफ़ेस उदाहरण देने की अनुमति देता है, जब भी डेटाग्रिड को किसी पंक्ति में सेल/कॉलम के मान को पुनर्प्राप्त करने की आवश्यकता होती है (वैकल्पिक रूप से, यह प्रतिनिधि या इंटरफ़ेस पूरी पंक्ति को पुनर्प्राप्त कर सकता है - सभी कॉलम मान एक निर्दिष्ट पंक्ति के लिए)।

आदर्श रूप से (यदि संभव हो), डेटाग्रिड इस प्रतिनिधि या इंटरफ़ेस को एसिंक्रोनस रूप से संचालित करने की अनुमति देगा। उदाहरण के लिए, प्रतिनिधि या इंटरफ़ेस अनुरोधित मान को तुरंत वापस करने के बजाय Task या IAsyncOperation<TResult> लौटा सकता है।

वैकल्पिक रूप से, अतुल्यकालिक समर्थन Task और IAsyncOperation<TResult> बिना भी संभव है, यदि डेटाग्रिड निम्नलिखित प्रक्रिया के समान कार्य करता है:

1. डेटाग्रिड निर्णय लेता है कि उसे पंक्ति आईडी 50001 में सेल/कॉलम 5 के मान को पुनः प्राप्त करने की आवश्यकता है। वैकल्पिक रूप से डेटाग्रिड पंक्ति आईडी 50001 के लिए सभी कॉलम मानों को पुनः प्राप्त करने का निर्णय लेता है।
2. डेटाग्रिड एक प्रतिनिधि या इंटरफ़ेस इंस्टेंस या ईवेंट हैंडलर को आमंत्रित करता है जो ऐप को सूचित करता है कि डेटाग्रिड ने निर्दिष्ट कॉलम/पंक्ति या पूरी पंक्ति के डेटा मानों को लोड करने का अनुरोध किया है।
3. ऐप अनुरोधित पंक्ति डेटा को अतुल्यकालिक रूप से पुनर्प्राप्त करता है। उदाहरण के लिए, यह अतुल्यकालिक रूप से SQL डेटाबेस क्वेरी निष्पादित कर सकता है।
4. ऐप अनुरोधित पंक्ति डेटा को पुनर्प्राप्त करना समाप्त कर देता है। ऐप डेटाग्रिड में एक विधि का आह्वान करता है जो डेटाग्रिड को पंक्ति डेटा देता है।
5. डेटाग्रिड पंक्ति डेटा प्रदर्शित करता है, या डेटा के साथ जो कुछ भी करने की आवश्यकता होती है वह करता है।

सबसे पहले, वाह !! अपने विचारों का योगदान देने वाले सभी लोगों को बहुत-बहुत धन्यवाद। मेरे पास नीचे कुछ विशिष्ट प्रतिक्रियाएं हैं, लेकिन कुल मिलाकर मैं यह कहना चाहता हूं कि मैं इन टिप्पणियों में से एक टन सहेज रहा हूं और वास्तव में यह सुनकर आनंद ले रहा हूं कि हम एक शानदार आधुनिक डेटाग्रिड कैसे बना सकते हैं। आने दो!

@Pinox उस विस्तृत प्रतिक्रिया और स्क्रीनशॉट के लिए बहुत बहुत धन्यवाद। आपकी इच्छा सूची बहुत बढ़िया है (विशेषकर वे अच्छे एनिमेशन!) - मैं मानता हूं कि html में पाई जाने वाली विशेषताएं एक अच्छा प्रेरणा बिंदु हैं और सरल हैं लेकिन जीवन की गुणवत्ता में काफी सुधार करती हैं। भविष्य में संदर्भ के लिए निश्चित रूप से इस टिप्पणी को सहेज रहा होगा!

@verelpode , @robloo , @ duke7553 हाँ

@dotMorten , @jkewley , @verelpode प्रदर्शन निश्चित रूप से इस परियोजना के लिए मुख्य प्रेरणाओं में से एक है और मुख्य सुधारों में से एक है जिसे हम लागू करना चाहते हैं, एक नई डेटा वर्चुअलाइजेशन कहानी और आधुनिक नियंत्रण जैसे ItemsRepeater के उपयोग के माध्यम से। एक बार हमारे पास और विशिष्टियां होने पर आप सभी को अपडेट रखेंगे - लेकिन आपके द्वारा सुझाए गए इन विवरणों के लिए फिर से धन्यवाद।

@ Laz3rPanth3r, @robloo, @keeganatorr हम आप जोर से सुना है और datagrids कि WPF और अन्य यूआई चौखटे के हैं पसंद करने के बारे स्पष्ट - हम निश्चित रूप से इस ताज़ा में खाते में ले जा रहे हैं!

डेटाग्रिड पर शानदार काम और प्रतिक्रिया के अनुरोध के लिए धन्यवाद! यहां कुछ और सुझाए गए संवर्द्धन हैं।

DataGridColumn के अधिक उपवर्गों की आवश्यकता है

DataGridColumn वर्तमान उपवर्ग/कार्यान्वयन अपर्याप्त हैं। मैं DataGridColumn के निम्नलिखित नए उपवर्ग बनाने का सुझाव देता हूं:

| प्रस्तावित उपवर्ग | विवरण |
| :--- | :--- |
| DataGridIconColumn | एक सूची की प्रत्येक पंक्ति में एक आइकन प्रदर्शित करने के लिए एक सामान्य आवश्यकता है, इसलिए मेरा सुझाव है कि DataGridColumn नामक एक उपवर्ग बनाया जाए जिसका नाम DataGridIconColumn है जो पुनर्प्राप्त सेल मान को Windows.UI.Xaml.Controls.IconSource टाइपकास्ट करता है और प्रस्तुत करता है IconSource उदाहरण (प्रत्येक सेल में एक अलग IconSource उदाहरण प्रस्तुत किया गया है)। |
| डेटाग्रिड इमेज कॉलम | DataGridImageColumn के रूप में प्रस्तावित एक ही काम करते हैं चाहिए DataGridIconColumn सिवाय इसके कि यह प्रस्तुत करना चाहिए Windows.UI.Xaml.Media.ImageSource के बजाय Windows.UI.Xaml.Controls.IconSource । |
| डेटाग्रिडडेटटाइम कॉलम | सेटिंग्स के आधार पर दिनांक और/या समय प्रदर्शित करता है। सेल मान को System.DateTimeOffset या System.DateTime (दोनों समर्थित) टाइपकास्ट करता है और इसे सेल में प्रदर्शित होने के लिए टेक्स्ट में परिवर्तित करता है। पाठ में रूपांतरण को DataGridDateTimeColumn वर्ग में स्वरूपण सेटिंग्स/गुणों द्वारा नियंत्रित किया जाना चाहिए। स्पष्ट रूप से दिनांक/समय के अनुसार छँटाई का भी समर्थन किया जाना चाहिए। |
| डेटाग्रिडटाइमस्पैनकॉलम | सेल मान को System.TimeSpan टाइपकास्ट करता है और इसे सेल में प्रदर्शित होने वाले टेक्स्ट में परिवर्तित करता है। पाठ में रूपांतरण को DataGridTimeSpanColumn वर्ग में स्वरूपण सेटिंग्स/गुणों द्वारा नियंत्रित किया जाना चाहिए। स्पष्ट रूप से छँटाई भी समर्थित होनी चाहिए, और इसे TimeSpan उदाहरणों को क्रमबद्ध करना चाहिए न कि प्रदर्शित पाठ को। |
| DataGridDataSizeColumn | सेल मान को System.Int64 , UInt64 , Int32 , या UInt32 (सभी समर्थित) टाइपकास्ट करता है और इसे आकार-इन-बाइट्स में परिवर्तित करता है (पाठ के रूप में) ) प्रदर्शित किया जाना है। उदाहरण के लिए, 1572864 को "1.5 एमबी" के रूप में प्रदर्शित किया जाएगा क्योंकि 1572864/1024/1024 = 1.5। टेक्स्ट में रूपांतरण DataGridDataSizeColumn वर्ग में सेटिंग्स/गुणों द्वारा नियंत्रित किया जाना चाहिए। छँटाई मूल पूर्णांक मान का उपयोग करके की जानी चाहिए न कि प्रदर्शित पाठ का। |
| डेटाग्रिड कस्टम कॉलम | यह पहले से मौजूद के लिए इसी तरह काम करते हैं चाहिए DataGridTemplateColumn बिना छोड़कर Windows.UI.Xaml.DataTemplate । इसे प्रदर्शित जीयूआई तत्व उपट्री को उत्पन्न और/या अद्यतन करने के लिए एक प्रतिनिधि/कॉलबैक या घटना का आह्वान करना चाहिए। |
| डेटाग्रिड टेक्स्ट कॉलम | पहले से मौजूद है लेकिन कृपया ऐसे गुण या ईवेंट जोड़ने पर विचार करें जो ऐप्स को ऑब्जेक्ट-टू-टेक्स्ट रूपांतरण और सॉर्टिंग के लिए तुलना फ़ंक्शन को ओवरराइड करने की अनुमति देते हैं। मैं इसे बाद में अपने संदेश में और अधिक विस्तार से समझाता हूं। |

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 सबट्री, और फिर डेटाग्रिड इसे प्रदर्शित करेगा।

अगली बार जब डेटाग्रिड इस ईवेंट को ट्रिगर करता है, तो डेटाग्रिड को संपत्ति DataGridDisplayingCellEventArgs.CellUIElement को UIElement इंस्टेंस पर सेट करना चाहिए जो पहले ईवेंट हैंडलर द्वारा जेनरेट किया गया था, ताकि ईवेंट हैंडलर को पुन: उपयोग/रीसायकल और अपडेट करने की अनुमति मिल सके। वही UIElement सबट्री (संभावित रूप से DataGridDisplayingCellEventArgs.CellValue में भिन्न मान के साथ)। ईवेंट हैंडलर को या तो उसी UIElement सबट्री को रीसायकल करने की अनुमति है या संपत्ति DataGridDisplayingCellEventArgs.CellUIElement को नए बनाए गए UIElement सबट्री में सेट करने की अनुमति है।

उपवर्ग DataGridCustomColumn बनाने के बजाय नए DisplayingCell ईवेंट को सीधे बेस क्लास DataGridColumn में बनाने की संभावना पर भी विचार करें। इस प्रकार घटना DataGridColumn.DisplayingCell DataGridColumn के प्रत्येक उपवर्ग के लिए उत्पन्न UIElement के अनुकूलन या ओवरराइडिंग की अनुमति दे सकती है।

पहले से मौजूद DataGridTextColumn , वर्तमान में सेल वैल्यू/ऑब्जेक्ट को System.Object.ToString आह्वान करके डिस्प्ले के लिए टेक्स्ट में कनवर्ट किया जाता है। कृपया एक प्रतिनिधि/कॉलबैक या ईवेंट बनाने पर विचार करें जो ऐप्स को इस मूल्य-से-पाठ रूपांतरण को ओवरराइड करने की अनुमति देता है। कृपया उस प्रॉपर्टी पर भी विचार करें जो ऐप्स को सॉर्टिंग व्यवहार को ओवरराइड करने के लिए System.Collections.IComparer इंस्टेंस निर्दिष्ट करने की अनुमति देती है।

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

public delegate string DataGridCellValueToToStringConverter(object sourceObject);

वैकल्पिक रूप से, Comparer संपत्ति को DataGridTextColumn में बनाने के बजाय, अनुमति देने के लिए Comparer संपत्ति को सीधे बेस क्लास DataGridColumn में बनाने की संभावना पर विचार करें। ऐप्स DataGridColumn के सभी उपवर्गों के लिए सॉर्टिंग व्यवहार को नियंत्रित करने के लिए।

इसी तरह CellValueToToStringConverter संपत्ति को बेस क्लास DataGridColumn में भी बनाया जा सकता है क्योंकि DataGridColumn उपवर्ग की परवाह किए बिना किसी भी सेल वैल्यू को टेक्स्ट में बदलने की क्षमता होना उपयोगी होगा। प्रयोग किया जाता है। उदाहरण के लिए, क्लिपबोर्ड पर एक पंक्ति की प्रतिलिपि बनाते समय, प्रत्येक सेल मान को टेक्स्ट में बदला जा सकता है। (पाठ और गैर-पाठ प्रारूप दोनों को एक साथ क्लिपबोर्ड में रखा जा सकता है - ऐप्स आमतौर पर अन्य ऐप्स के साथ संगतता बढ़ाने के लिए ऐसा करते हैं।)

DataGridIconColumn या DataGridImageColumn चुने जाने पर पुन: छँटाई करना: स्पष्ट रूप से डेटाग्रिड आइकन या छवियों को सॉर्ट नहीं कर सकता है, इसलिए यह इनमें से किसी एक समाधान का उपयोग कर सकता है:

• बस अंतिम-उपयोगकर्ताओं को DataGridIconColumn या DataGridImageColumn प्रकार के कॉलम हेडर का चयन (क्रमबद्ध) करने की अनुमति न दें।
• IconSource वर्ग में AlternativeText संपत्ति बनाएं। जब DataGridIconColumn पंक्तियों को सॉर्ट करता है, या जब यह सेल को क्लिपबोर्ड/कॉपी के लिए टेक्स्ट में परिवर्तित करता है, तो यह AlternativeText संपत्ति का उपयोग करेगा।
• या तो DataGridColumn या DataGridIconColumn एक सेटटेबल Comparer संपत्ति (प्रकार System.Collections.IComparer ) बनाएं।

चयनित पंक्तियों/वस्तुओं तक पहुंच

कृपया चयनित पंक्तियों/वस्तुओं को प्राप्त करने और सेट करने के लिए कार्यक्षमता में सुधार करने पर विचार करें, क्योंकि वर्तमान कार्यक्षमता अपर्याप्त है। वर्तमान में ये गुण मौजूद हैं:

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

मैंने पाया कि कभी-कभी मुझे चयनित पंक्तियों के डेटाग्रिडरो उदाहरणों तक पहुंच की आवश्यकता होती है, इस प्रकार मुझे आशा है कि निम्नलिखित गुण डेटाग्रिड में जोड़े जा सकते हैं:

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.

व्यक्तिगत रूप से मुझे "चयनित इंडेक्स" नाम भ्रमित लगता है क्योंकि डेटाग्रिड अक्सर डेटाबेस के संयोजन के साथ प्रयोग किया जाता है और "इंडेक्स" शब्द का डेटाबेस में एक बिल्कुल अलग अर्थ होता है, इसलिए मैं निम्नानुसार गुणों का नाम बदलने का सुझाव देता हूं, लेकिन मुझे उम्मीद है कि मेरा नामकरण सुझाव खारिज कर दिया जाएगा:

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

मैं निर्दिष्ट डेटाग्रिडरो और/या डेटाग्रिड कॉलम को देखने में स्क्रॉल करने की क्षमता भी चाहता हूं। वर्तमान में यह विधि मौजूद है:

public void ScrollIntoView(object item, DataGridColumn column);

मैं इन 2 विधियों के साथ पहले से मौजूद ScrollIntoView पद्धति को बदलने का सुझाव देता हूं:

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

एक हिट में सॉर्ट-ऑर्डर प्राप्त करें और सेट करें

जब ऐप्स खोले और बंद किए जाते हैं, तो उन्हें डेटाग्रिड के अंतिम-उपयोगकर्ता के कॉन्फ़िगरेशन को सहेजने और पुनर्स्थापित करने की क्षमता की आवश्यकता होती है, जिसमें सॉर्ट ऑर्डर और अन्य सेटिंग्स शामिल हैं। क्रमबद्ध क्रम का अर्थ है उपयोगकर्ता द्वारा चुने गए स्तंभों की सूची। ध्यान दें कि यह एक सूची है, एक कॉलम नहीं। एक से अधिक स्तंभों का एक साथ चयन किया जा सकता है, जिसका अर्थ है छँटाई के लिए प्राथमिक स्तंभ, और छँटाई के लिए द्वितीयक स्तंभ, और छँटाई के लिए तृतीयक स्तंभ, आदि।

इसलिए डेटाग्रिड में निम्नलिखित संपत्ति बनाई जा सकती है, लेकिन वास्तव में यह केवल पहला विचार है और यह आदर्श नहीं है:

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

उपरोक्त गैर-आदर्श है क्योंकि यह एक हिट में प्रत्येक कॉलम के DataGridColumn.SortDirection को सहेजने और पुनर्स्थापित करने का समर्थन नहीं करता है। मुझे एहसास है कि ऐप्स इसे कई चरणों में कर सकते हैं:

1. प्रस्तावित SortOrder प्रॉपर्टी को चयनित कॉलम की सूची में सेट करें।
2. प्रत्येक चयनित कॉलम की SortDirection प्रॉपर्टी सेट करें (प्रत्येक कॉलम के लिए इस चरण को दोहराएं)।

यह अभी भी समस्याग्रस्त है क्योंकि यह कई हिट है, जिसका अर्थ है कि यह डेटाग्रिड के कई समय लेने वाले रिसॉर्ट्स का कारण बनता है। जब डेटाग्रिड को अनावश्यक रूप से कई बार सहारा दिया जाता है, तो अंतिम-उपयोगकर्ता बड़ी संख्या में पंक्तियों वाले डेटाग्रिड में नोटिस कर सकते हैं और एक महत्वपूर्ण देरी का सामना कर सकते हैं। इस समस्या को खत्म करने के लिए, मैं निम्नलिखित समाधान सुझाता हूं जो ऐप्स को एक हिट में संपूर्ण सॉर्ट-ऑर्डर को पुनर्स्थापित करने की अनुमति देता है और एक से अधिक रिसॉर्ट का कारण नहीं बनता है।

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.SortOrder को एक नई सूची में सेट किया जाता है, तो डेटाग्रिड नई SortOrder सूची में प्रत्येक कॉलम में संबंधित DataGridColumn.SortDirection प्रॉपर्टी भी सेट करेगा, लेकिन कई रिसॉर्ट्स पैदा किए बिना। इस प्रकार DataGrid.SortOrder[i].SortDirection DataGridColumn.SortDirection बराबर है।

एक हिट में प्रदर्शित कॉलम ऑर्डर प्राप्त करें और सेट करें

जब ऐप्स खोले और बंद किए जाते हैं, तो उन्हें कॉलम के अंतिम-उपयोगकर्ता के क्रम को सहेजने और पुनर्स्थापित करने की क्षमता की आवश्यकता होती है, अधिमानतः एक हिट में। मुझे पता है कि पहले से मौजूद संपत्ति DataGridColumn.DisplayIndex व्यवस्थित है, इसलिए सैद्धांतिक रूप से ऐप्स DataGrid.Columns में सभी स्तंभों के माध्यम से पुनरावृति करके अंतिम उपयोगकर्ता के कॉन्फ़िगरेशन को पुनर्स्थापित कर सकते हैं और प्रत्येक के DisplayIndex सेट कर सकते हैं, लेकिन यह बग का कारण बन सकता है। उदाहरण के लिए, DisplayIndex विफल हो सकता है या अप्रत्याशित तरीके से व्यवहार कर सकता है जब किसी ऐप को अस्थायी रूप से एक कॉलम के DisplayIndex को दूसरे कॉलम के समान DisplayIndex पर सेट करने की आवश्यकता होती है। साथ ही, यदि इसे एक हिट में नहीं किया जाता है, तो यह कई महंगे पुनर्रचनाओं और/या पुनर्गणनाओं को ट्रिगर कर सकता है।

इसलिए मैं डेटाग्रिड में ColumnDisplayOrder संपत्ति बनाने का सुझाव देता हूं:

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

जैसा कि मैंने पहले SortOrder लिए उल्लेख किया था, ColumnDisplayOrder जानबूझकर IReadOnlyList<DataGridColumn> न कि IList<DataGridColumn> क्योंकि इसे एक हिट में संचालित होना चाहिए।
जब DataGrid.ColumnDisplayOrder को एक नई सूची में सेट किया जाता है, तो डेटाग्रिड मिलान करने के लिए प्रत्येक कॉलम के DataGridColumn.DisplayIndex को अपडेट करेगा।

अंतिम उपयोगकर्ताओं को कॉलम छिपाने/दिखाने की अनुमति दें

पहले से मौजूद गुणों के अनुरूप DataGridColumn.CanUserReorder आदि, मैं CanUserChangeVisibility में DataGridColumn संपत्ति बनाने का सुझाव देता हूं। जब DataGridColumn.CanUserChangeVisibility सत्य है, तो अंतिम उपयोगकर्ता संपत्ति DataGridColumn.Visibility परिवर्तन करने में सक्षम होगा।

रनटाइम पर गतिशील रूप से उत्पन्न GUI तत्वों का समर्थन करें

DataGrid.RowDetailsTemplate ( Windows.UI.Xaml.DataTemplate ) के उपयोग की आवश्यकता के बिना पंक्ति-विवरण जीयूआई उत्पन्न करने की अनुमति दें। इसे प्राप्त करने के लिए, कुछ विचारों को एपीआई में डालने की आवश्यकता है, लेकिन इसे कैसे करना है, इसके लिए मेरा पहला विचार यह है: शायद इसे पहले से मौजूद घटना DataGrid.LoadingRow माध्यम से संपत्ति DataGridRowDetailsEventArgs.DetailsElement बदलकर करें सेट करने योग्य होने के लिए ताकि ईवेंट हैंडलर UIElement को स्वयं उत्पन्न (या अपडेट) कर सके और DetailsElement संपत्ति सेट करके इसे डेटाग्रिड को दे सके।

Windows.UI.Xaml.DataTemplate अनिवार्य उपयोग का कारण एक समस्या है: हालांकि टेम्प्लेट एक अच्छी विशेषता है, टेम्पलेट अवधारणा एक पूर्वनिर्मित अपरिवर्तनीय XAML स्निपेट/दस्तावेज़ की अपेक्षा करती है जो डेवलपर द्वारा अग्रिम रूप से लिखा गया था। इस प्रकार टेम्प्लेट एक समस्या है जब ऐप को रनटाइम पर जीयूआई को गतिशील रूप से उत्पन्न करने की आवश्यकता होती है। इस प्रकार मैं उपरोक्त विकल्पों की कामना करता हूं DataTemplate ।

पंक्तियों को अंदर और बाहर की ओर खींचें और छोड़ें

मैं सुझाव देता हूं कि पंक्तियों के आउटगोइंग ड्रैग-एंड-ड्रॉप को वैकल्पिक रूप से सक्षम करने की क्षमता बनाएं। डेटाग्रिड ड्रैग को लागू करेगा लेकिन ड्रॉप को नहीं। जब ड्रॉप होता है, तो डेटाग्रिड एक ईवेंट ट्रिगर करेगा और डेटाग्रिड के बाहर पंक्ति को छोड़े जाने पर वांछित कार्रवाई करने के लिए ऐप ईवेंट का जवाब देता है।

साथ ही पंक्तियों या वस्तुओं/वस्तुओं के आने वाले ड्रैग-एंड-ड्रॉप को वैकल्पिक रूप से सक्षम करने की क्षमता। डेटाग्रिड आने वाले ड्रैग-एंड-ड्रॉप को स्वीकार करेगा लेकिन ड्रॉप को लागू नहीं करता है। डेटाग्रिड एक ईवेंट ट्रिगर करेगा जब पंक्ति/आइटम/ऑब्जेक्ट गिरा दिया जाता है, और ऐप डेटाग्रिड के अंदर पंक्ति को गिराए जाने पर वांछित कार्रवाई करने के लिए ईवेंट का जवाब देता है।

व्यक्तिगत सेल पृष्ठभूमि

हमारे पास एक ग्राहक से एक सुविधा अनुरोध है जो चाहता है कि अलग-अलग कोशिकाओं को निश्चित समय पर (सेल पृष्ठभूमि रंग/ब्रश बदलकर) हिलाया जाए (जैसे कि जब हमारा ऐप परिवर्तनों या महत्वपूर्ण मूल्यों या सुरक्षा सीमा से अधिक खतरनाक मूल्यों आदि का पता लगाता है)।

इस प्रकार मैं एक DataGridCell.Background संपत्ति (प्रकार Brush ) का प्रस्ताव कर सकता था, लेकिन मुझे लगता है कि ऐसा करने का यह तरीका शायद दोषपूर्ण है क्योंकि डेटाग्रिड DataGridCell उदाहरणों को पुन: चक्रित करता है, है ना? इसलिए मुझे लगता है कि DataGridCell.Background संपत्ति सेट करके अलग-अलग कक्षों को हिलाना एक अविश्वसनीय समाधान होगा।

घटना DataGridColumn.DisplayingCell माध्यम से एक बेहतर तरीका हो सकता है जिसे मैंने अपने पिछले संदेश में प्रस्तावित किया था। ईवेंट हैंडलर CellBackgroundBrush संपत्ति को DataGridDisplayingCellEventArgs सेट कर सकता है।

डंब-डाउन डेटाग्रिड डेटा की पुनर्प्राप्ति (सेल मान)

मुझे पता है कि "गूंगा" बहुत बुरा लगता है, लेकिन वास्तव में मुझे यह अच्छा लगेगा यदि डेटा-रिट्रीवल (डेटाग्रिड द्वारा प्रदर्शित किए जाने वाले सेल मानों की पुनर्प्राप्ति) के क्षेत्र में डेटाग्रिड को गूंगा बना दिया गया था।

वर्तमान में डेटाग्रिड अपनी संपत्ति DataGrid.ItemsSource प्लस डेटा-बाइंडिंग तकनीकों (संपत्ति DataGridBoundColumn.Binding ), और इंटरफेस जैसे System.ComponentModel.INotifyPropertyChanged माध्यम से सुविधाजनक स्वचालित तरीके से डेटा पुनर्प्राप्ति करने का प्रयास करता है।

हां डेटा-बाइंडिंग एक सुविधाजनक सुविधा है, लेकिन वास्तव में मैं उस विभाग में डेटाग्रिड को _less_ करना पसंद करूंगा! कई Microsoft घटक वास्तव में स्मार्ट बनने की कोशिश करने के अपने व्यवहार के माध्यम से मेरे लिए बड़ी कठिनाइयों का कारण बनते हैं लेकिन वास्तव में बहुत स्मार्ट होने के कारण समाप्त होते हैं। कुल मिलाकर मुझे वास्तव में कम कठिनाइयों और कम काम का अनुभव होगा यदि ये घटक इतने स्मार्ट/स्वचालित/सुविधाजनक होने की कोशिश करना बंद कर देंगे। एक स्वचालित व्यवहार को डिजाइन करते समय, मुझे यह ध्यान रखना उचित लगता है कि स्वचालित ध्वनि बहुत अच्छी है लेकिन इसमें बैकफायर की क्षमता है।

_ "बस मुझे इसे अपने आप करने दो।"_
कभी-कभी सबसे अच्छा समाधान यह है कि डेटाग्रिड जैसे घटक के अंदर "स्वचालित रूप से" करने की कोशिश करने और असफल होने के बजाय, केवल ऐप्स को स्वयं कार्य करने की अनुमति दें। मेरी इच्छा है कि डेटाग्रिड मुझे DataGridBoundColumn.Binding और DataGrid.ItemsSource गुणों के माध्यम से डेटा को स्वचालित रूप से पुनर्प्राप्त करने का प्रयास करने के बजाय, डेटा पुनर्प्राप्ति को पूरी तरह से करने की अनुमति देगा।

आदर्श रूप से मैं वस्तुओं की आपूर्ति के लिए संपत्ति DataGrid.ItemsSource का उपयोग करने की आवश्यकता को समाप्त करना चाहता हूं। @dotMorten ने एक लाख पंक्तियों का उल्लेख किया। वर्तमान में डेटाग्रिड ऐप्स के लिए DataGrid.ItemsSource सेट करना अनिवार्य बनाता है, लेकिन एक सूची ऑब्जेक्ट बनाना अव्यावहारिक है जिसमें एक मिलियन आइटम शामिल हैं। इस प्रकार मैं चाहता हूं कि डेटाग्रिड डेटा-पुनर्प्राप्ति विभाग में स्मार्ट होना बंद कर दे और इसके बजाय मुझे DataGridBoundColumn.Binding और DataGrid.ItemsSource का उपयोग किए बिना डेटा पुनर्प्राप्ति को पूरी तरह से स्वयं करने दें।

@anawishnoff ने लिखा:

प्रदर्शन निश्चित रूप से इस परियोजना के लिए मुख्य प्रेरणाओं में से एक है और उन मुख्य सुधारों में से एक है जिसे हम एक नई डेटा वर्चुअलाइजेशन कहानी और आधुनिक नियंत्रण जैसे आइटम रिपीटर के उपयोग के माध्यम से कार्यान्वित करना चाहते हैं।

मैंने देखा है कि आपने कहा है कि नई डेटा वर्चुअलाइजेशन कहानी प्रदर्शन में सुधार करेगी, और यह अच्छी खबर है, लेकिन क्या यह डेटाग्रिड प्रदर्शित सेल मूल्यों की आपूर्ति के लिए संपत्ति DataGridBoundColumn.Binding का उपयोग करने की आवश्यकता को भी समाप्त कर देगा?

यदि संपूर्ण डेटा पुनर्प्राप्ति कार्य डेटाग्रिड का उपयोग करने वाले ऐप को आउटसोर्स किया जाता है, तो ऐप में डेटा पुनर्प्राप्ति को किसी भी तरीके से करने के लिए पूर्ण लचीलापन है जिसकी उसे आवश्यकता है। यह कई अलग-अलग डेटा-पुनर्प्राप्ति परिदृश्यों को सक्षम करेगा, जिसमें लाखों पंक्तियां शामिल हैं जिनका @dotMorten ने उल्लेख किया है। इसे शांत करें, कृपया :मुस्कुराएं:

डब्ल्यूपीएफ डाटाग्रिड में कुछ अनावश्यक विशेषताएं?

डेटाग्रिड के डब्ल्यूपीएफ संस्करण में कुछ विशेषताएं हैं जो अनावश्यक या अव्यवहारिक लगती हैं, और इन सुविधाओं को विनयूआई डेटाग्रिड में छोड़ दिया जा सकता है, लेकिन मुझे उम्मीद है कि कुछ लोगों की शायद इन सुविधाओं के बारे में एक अलग राय है।

कितने लोग आपत्ति करेंगे यदि WinUI डेटाग्रिड ने उस सुविधा को छोड़ दिया जहां एंड-यूज़र डेटाग्रिड के अंदर/सीधे सेल मानों को संपादित करने में सक्षम हैं? हमारे मामले में, हर जगह जहां हम डेटाग्रिड का उपयोग करते हैं, हम इनलाइन/प्रत्यक्ष संपादन सुविधा को अक्षम करने के लिए हमेशा DataGrid.IsReadOnly को सत्य पर सेट करते हैं। हम उपयोगकर्ताओं को चयनित पंक्ति को एक अलग फलक या पैनल में, या RowDetails ( DataGrid.RowDetailsTemplate ) में संपादित करने की अनुमति देते हैं, लेकिन सीधे डेटाग्रिड के अंदर नहीं।

ऐसा लगता है कि WinUI डेटाग्रिड पहले ही इनलाइन/प्रत्यक्ष संपादन के लिए समर्थन छोड़ने की दिशा में आगे बढ़ चुका है क्योंकि wpf डेटाग्रिड के पास CanUserAddRows और CanUserDeleteRows लेकिन ये गुण अब WinUI डेटाग्रिड में मौजूद नहीं हैं। इनलाइन/प्रत्यक्ष संपादन सुविधा को पूरी तरह से छोड़ने के लिए सभी तरह से क्यों नहीं जाते? कितने लोगों को इस विचार पर आपत्ति है?

व्यक्तिगत सेल चयन: डब्ल्यूपीएफ डाटाग्रिड में SelectionUnit संपत्ति है जिसे आप Cell , FullRow , या CellOrRowHeader । हमारे मामले में, हम इसे हमेशा FullRow पर सेट करते हैं और इसे कभी भी Cell पर सेट करने की आवश्यकता नहीं पाते हैं। हालाँकि मैं देख रहा हूँ कि यहाँ एक व्यक्ति ने पहले ही सिंगल सेल सिलेक्शन मोड का अनुरोध किया है। मेरा प्रश्न यह है कि क्या सेल चयन मोड एक सामान्य या दुर्लभ अनुरोध है।

दूसरी ओर, व्यक्तिगत सेल चयन उपयोगी हो सकता है जब उपयोगकर्ता क्लिपबोर्ड पर पंक्तियों/कोशिकाओं की प्रतिलिपि बनाता है। यह उपयोगकर्ताओं को पूरी पंक्ति को कॉपी करने के बजाय एक व्यक्तिगत सेल (या कई सन्निहित सेल) को क्लिपबोर्ड पर कॉपी करने की अनुमति देगा। हालाँकि मुझे यकीन नहीं है कि यह सुविधा वास्तव में मूल्यवान है या नहीं।

| डब्ल्यूपीएफ में संदिग्ध फीचर | टिप्पणियाँ |
| :--- | :--- |
| DataGrid.IsReadOnly | हो सकता है कि कभी भी IsReadOnly को गलत पर सेट करने की कोई वास्तविक आवश्यकता न हो? |
| DataGrid.CanUserAddRows | WinUI डेटाग्रिड में मौजूद नहीं है। पहले ही छोड़ दिया गया है, या शायद अभी तक लागू नहीं किया गया है (मुझे योजना की जानकारी नहीं है)। |
| DataGrid.CanUserDeleteRows | WinUI डेटाग्रिड में मौजूद नहीं है। पहले ही छोड़ दिया गया है, या शायद अभी तक लागू नहीं किया गया है (मुझे योजना की जानकारी नहीं है)। |
| DataGrid.SelectionUnit | WinUI डेटाग्रिड में मौजूद नहीं है। |

वाह, यहाँ अविश्वसनीय चर्चा। ❤️

मैं डब्ल्यूपीएफ डाटाग्रिड एपीआई से भी सहमत हूं। डब्ल्यूपीएफ डाटाग्रिड वास्तव में डेटाग्रिड है जिसे मैं WinUI 3.0 के लिए चाहता हूं।

लेकिन यहां तक ​​कि डब्ल्यूपीएफ डाटाग्रिड में भी कुछ विशेषताओं का अभाव है। अतीत में, मेरे अधिकांश ग्राहकों ने इन सुविधाओं को प्राप्त करने के लिए अधिक शक्तिशाली तृतीय पक्ष डेटाग्रिड का उपयोग किया था:

• कॉलम हेडर में फिल्टर
• डेटाग्रिड के शीर्ष पर एक पूर्ण फ़िल्टर पंक्ति
• पदानुक्रमित डेटा का शक्तिशाली प्रदर्शन। कुछ तृतीय पक्ष डेटाग्रिड वास्तव में नेस्टेड डेटाग्रिड के साथ एक शक्तिशाली ट्री व्यू की तरह काम करते हैं। जबकि डब्ल्यूपीएफ डाटाग्रिड ऐसा कुछ बनाने की इजाजत देता है, यह बॉक्स के बाहर इसका समर्थन नहीं करता है
• विभिन्न डेटा प्रकारों के लिए समर्थन। उदाहरण के लिए डेटटाइम कॉलम की तरह। डब्ल्यूपीएफ के डेटाग्रिड में आपको डेटाग्रिड टेम्पलेट कॉलम का उपयोग करना होगा

लेकिन फिर भी, आप जो कुछ भी करते हैं, मुझे लगता है कि डेटाग्रिड बनाना एक शक्तिशाली कथन है और WinUI 3.0 के प्रति प्रतिबद्धता है। एलओबी अनुप्रयोगों के लिए आप यूआई ढांचे को गंभीरता से नहीं ले सकते हैं जिसमें अंतर्निहित डेटाग्रिड शामिल नहीं है। और WinUI के लिए किए गए इस निवेश को देखकर बहुत अच्छा लगा!

@thomasclaudiushuber

एलओबी अनुप्रयोगों के लिए आप यूआई ढांचे को गंभीरता से नहीं ले सकते हैं जिसमें अंतर्निहित डेटाग्रिड शामिल नहीं है। और WinUI के लिए किए गए इस निवेश को देखकर बहुत अच्छा लगा!

माना! हमारे मामले में, डेटाग्रिड एक महत्वपूर्ण रूप से आवश्यक घटक है जिसका उपयोग हम कई स्थानों पर करते हैं और इसके बिना नहीं रह सकते हैं।

पदानुक्रमित डेटा का शक्तिशाली प्रदर्शन। कुछ तृतीय पक्ष डेटाग्रिड वास्तव में नेस्टेड डेटाग्रिड के साथ एक शक्तिशाली ट्री व्यू की तरह काम करते हैं।

मैं उस विषय पर फटा हुआ हूं क्योंकि - आप की तरह - मुझे कुछ स्थितियों में एक पदानुक्रमित डेटाग्रिड उपयोगी लगेगा, लेकिन मेरी चिंता यह है कि यदि डेटाग्रिड पदानुक्रमित कार्यक्षमता को लागू करता है, तो यह अत्यधिक जटिल और कठिन हो सकता है, और रिलीज हो सकता है डेटाग्रिड में काफी हद तक देरी होने की संभावना है। नई सुविधाओं को पदानुक्रमित और गैर-श्रेणीबद्ध कार्यक्षमता दोनों के साथ संगत बनाने की जटिलता के कारण नई सुविधाओं को जोड़ना मुश्किल होगा।

उपरोक्त जटिलता/देरी की समस्या को खत्म करने के लिए, मैं इस समाधान का सुझाव देता हूं: HierarchicalDataGrid नामक एक अलग वर्ग बनाएं जो आंतरिक रूप से DataGrid उदाहरण का उपयोग/लपेटता है। वैकल्पिक रूप से HierarchicalDataGrid सार्वजनिक रूप से DataGrid उत्तराधिकारी हो सकता है लेकिन मुझे संदेह है कि यह विरासत अव्यावहारिक है, इसलिए मैं यह सुझाव देना पसंद करता हूं कि HierarchicalDataGrid विरासत में Control और आंतरिक रूप से एक निजी क्षेत्र है DataGrid टाइप करें। इस प्रकार पदानुक्रमित कार्यक्षमता HierarchicalDataGrid परत में लागू की जाएगी जो एक आंतरिक गैर-पदानुक्रमित DataGrid उदाहरण को निर्देशित करती है।

इसके बाद के संस्करण समाधान के प्रमुख लाभ यह है कि उद्धार होगा वांछित श्रेणीबद्ध सुविधाओं फंसा _without_ है DataGrid , बनाने के बिना DataGrid इतना जटिल है कि यह अनियंत्रित और विकसित करने के लिए धीमी गति से हो जाता है।

विभिन्न डेटा प्रकारों के लिए समर्थन। उदाहरण के लिए डेटटाइम कॉलम की तरह।

मैं सहमत हूं। DataGridDateTimeColumn और DataGridTimeSpanColumn जो मैंने पिछले संदेश में प्रस्तावित किया था।

@पिनॉक्स

पूरे पृष्ठ को आसानी से फ़िल्टर करें

@thomasclaudiushuber

कॉलम हेडर में फिल्टर; डेटाग्रिड के शीर्ष पर एक पूर्ण फ़िल्टर पंक्ति;

फ़िल्टर अंतिम-उपयोगकर्ताओं को जल्दी से एक पंक्ति या पंक्तियों को खोजने में मदद करने के लिए बहुत अच्छे होंगे, बजाय इसके कि वे जो खोज रहे हैं उसे खोजने के लिए बड़ी संख्या में पंक्तियों को मैन्युअल रूप से देखने के लिए मजबूर किया जाए।

लेकिन गैर-पाठ स्तंभों के साथ उपयोगकर्ता के फ़िल्टर पाठ के मिलान की समस्या के बारे में क्या? मतलब कॉलम 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);
    }
}

वैकल्पिक रूप से, सेल वैल्यू को कीवर्ड के संग्रह के बजाय एक स्ट्रिंग में परिवर्तित किया जा सकता है, लेकिन इसका कारण यह है कि मैंने कीवर्ड संग्रह का सुझाव दिया है कि कीवर्ड खोज एल्गोरिदम का उपयोग करना संभव बनाते हैं जो पंक्तियों की मात्रा होने पर भी उच्च गति से चलते हैं। बहुत बड़ा।

एक्सेल से आसान कॉपी पास्ट
अब एक्सेल सेल सामग्री को डेटाग्रिड में कॉपी करने के लिए ctrl+v का उपयोग करने का कोई तरीका नहीं है। अब यह डेटा ग्रिड में सभी सेल सामग्री को एक सेल में कॉपी करता है।

चयनित पंक्तियों को प्रबंधित करते समय डेटा बाइंडिंग का उपयोग करने की अनुमति देने के लिए SelectedItems को एक निर्भरता संपत्ति के रूप में बनाकर, एक उचित एकाधिक चयनित आइटम समर्थन प्रदान करें।

@verelpode मैं देख सकता हूं कि व्यक्तिगत सेल चयन किसी भी स्प्रेडशीट प्रकार के एप्लिकेशन के लिए उपयोगी है, नहीं? मुझे लगता है कि यह परिदृश्यों को संपादित करने बनाम परिदृश्यों को देखने में अधिक मायने रखता है। डेटाग्रिड में बिना संपादन के डेटा देखते समय, मैं सहमत हूं कि मैं व्यक्तिगत सेल चयन के लिए उपयोग नहीं देखूंगा और हमेशा पूर्ण पंक्ति चयन होता है।

@anawishnoff मुझे लगता है कि @ Laz3rPanth3r सहमत होंगे और टूलकिट से यहां और यहां कुछ मुद्दे जो डेटाग्रिड में आसानी से और आसानी से डेटा डालने में सक्षम हैं, एक महत्वपूर्ण विशेषता है। आप किसी सूची में ऑब्जेक्ट्स या एक्सपेंडो ऑब्जेक्ट्स के संग्रह के लिए बाध्य करके ग्रिड को बूट-स्ट्रैप करने में सक्षम होना चाहिए। यदि यह संख्याओं और स्ट्रिंग्स और बुनियादी डेटा प्रकारों के लिए बुद्धिमानी से कॉलम चुन सकता है, तो यह बहुत अच्छा होगा। इसके अलावा अलग-अलग कॉलम को कस्टमाइज़ करने के बाद डेवलपर हमेशा अधिक काम कर सकता है।

मैं देख सकता हूँ कि व्यक्तिगत सेल चयन किसी भी स्प्रैडशीट प्रकार के अनुप्रयोग के लिए उपयोगी है, नहीं?

एक स्प्रैडशीट में, कॉलम हेडर्स को वर्णमाला के आरोही अक्षरों, ए, बी, सी, डी, ... के साथ नामित किया गया है और प्रत्येक कॉलम का प्रकार समान है, जैसे कि प्रत्येक कॉलम DataGridTextColumn का उपयोग करता है और कोई अन्य कॉलम नहीं प्रकार की आवश्यकता है, और स्तंभ नामों की वास्तव में या तो आवश्यकता नहीं है क्योंकि वे वर्णमाला से स्वचालित रूप से उत्पन्न होते हैं।
डेटाग्रिड और स्प्रैडशीट के बीच एक और अंतर यह है कि जब आप किसी कॉलम हेडर पर क्लिक करते हैं तो स्प्रेडशीट पंक्तियों को सॉर्ट नहीं करती है।

मेरा कहना है, डेटाग्रिड और एक स्प्रेडशीट के बीच केवल एक सतही समानता (ज्यादातर एक दृश्य समानता) मौजूद है। डेटाग्रिड वास्तव में स्प्रेडशीट की तरह काम नहीं करता है। डेटाग्रिड की सेल डेटा पुनर्प्राप्ति तकनीक भी स्प्रेडशीट के लिए खराब रूप से अनुकूल है।

मुझे डेटाग्रिड पसंद है लेकिन अगर मैं स्प्रेडशीट को लागू करने के लिए इसका इस्तेमाल करने की कोशिश करता हूं तो यह खराब काम करेगा। मुझे नहीं लगता कि जो कोई स्प्रेडशीट लागू करना चाहता है उसके लिए डेटाग्रिड सही विकल्प है।

डेटाग्रिड का मौजूदा डिज़ाइन स्प्रैडशीट की तुलना में SQL डेटाबेस के साथ कहीं बेहतर तरीके से संरेखित होता है, और SQL डेटाबेस डेवलपर ज़ोर से चिल्लाते हैं यदि कोई यह दावा करने का प्रयास करता है कि डेटाबेस "सिर्फ एक स्प्रेडशीट" है।

@verelpode आपका योगदान इतना विस्तृत और

वर्तमान में डेटाग्रिड ऐप्स के लिए DataGrid.ItemsSource सेट करना अनिवार्य बनाता है, लेकिन एक सूची ऑब्जेक्ट बनाना अव्यावहारिक है जिसमें एक मिलियन आइटम शामिल हैं। इस प्रकार मैं चाहता हूं कि डेटाग्रिड डेटा-पुनर्प्राप्ति विभाग में स्मार्ट होना बंद कर दे और इसके बजाय मुझे डेटाग्रिडबाउंड कॉलम। बाइंडिंग और डेटाग्रिड.आइटम्ससोर्स का उपयोग किए बिना डेटा पुनर्प्राप्ति को पूरी तरह से करने दें।

यह दिलचस्प है, और मैं इसमें और अधिक देखना चाहता हूं क्योंकि हम वास्तव में प्रदर्शन में रुचि रखते हैं। आप किस प्रकार की डेटा स्थिति/परिदृश्य की तलाश कर रहे हैं, विशेष रूप से? क्या आप डेटाग्रिड को सीधे SQL क्वेरी परिणाम, या डेटाबेस, या उन पंक्तियों के साथ कुछ कनेक्ट करना चाहते हैं?

@khoshroomahdi कॉपी और पेस्ट करके, क्या आपका मतलब है कि आप एक्सेल सेल को एक चल रहे ऐप में

@alexyak , क्या आप थोड़ा और विस्तार कर सकते हैं? SelectedItems प्रॉपर्टी वर्तमान में आपको डेटाग्रिड में सभी चयनित आइटम प्राप्त करने की अनुमति देती है (विस्तारित चयन मोड के माध्यम से, सटीक रूप से एकाधिक चयन मोड नहीं)। मैं यहां कुछ अन्य टिप्पणियों से देखता हूं कि डेटाग्रिड के भीतर चयन को निश्चित रूप से काम करने की ज़रूरत है, लेकिन मैं आपके अनुरोध को बेहतर ढंग से समझना चाहता हूं।

@anawishnoff हाँ बिल्कुल।
मेरे पास एक्सेल सेल में कुछ डेटा है और मैं उन्हें रनिंग ऐप में कॉपी करना चाहता हूं।

गैर-डेटा-बाउंड परिदृश्यों के लिए, हमें यह देखना चाहिए कि कैसे WinForms DataGridView नियंत्रण, जिसे मैंने कई साल पहले लिखा था, एक वर्चुअल मोड का समर्थन करता है: https://docs.microsoft.com/en-us/dotnet/api/system। windows.forms.datagridview.virtualmode

वर्तमान में डेटाग्रिड ऐप्स के लिए DataGrid.ItemsSource सेट करना अनिवार्य बनाता है, लेकिन एक सूची ऑब्जेक्ट बनाना अव्यावहारिक है जिसमें एक मिलियन आइटम शामिल हैं। इस प्रकार मैं चाहता हूं कि डेटाग्रिड डेटा-पुनर्प्राप्ति विभाग में स्मार्ट होना बंद कर दे और इसके बजाय मुझे डेटाग्रिडबाउंड कॉलम। बाइंडिंग और डेटाग्रिड.आइटम्ससोर्स का उपयोग किए बिना डेटा पुनर्प्राप्ति को पूरी तरह से करने दें।

मैं मानता हूं कि यह भी अच्छा होगा। मैं लिस्टबॉक्स की तरह कुछ सोच रहा हूं जहां आप या तो आइटम मैन्युअल रूप से जोड़ सकते हैं या आइटम्ससोर्स सेट कर सकते हैं। उस ने कहा, अतीत में मैं पेजिंग को लागू करने के लिए पूर्ण डेटाबेस के आंशिक दृश्य का प्रतिनिधित्व करने वाला एक नया डेटाटेबल उत्पन्न करता हूं (जो इसके लिए एक अच्छा उपयोग मामला है)। उस डेटाटेबल का एक दृश्य तब आइटम स्रोत पर सेट किया जा सकता है। तो जबकि मुझे निश्चित रूप से लगता है कि यह अच्छा है कि यह उच्च प्रदर्शन के लिए अनिवार्य नहीं लगता है।

एक्सेल (आर) के कमोबेश एक सबसेट में नियंत्रण को बदलने वाली सभी टिप्पणियों के संबंध में, मुझे लगता है कि बॉक्स के बाहर डेटाग्रिड को सेल चयन और प्रति-सेल संपादन का समर्थन करना चाहिए। हालांकि, बाहरी अनुप्रयोगों के बीच कॉपी/पेस्ट जैसी चीजों को डेवलपर द्वारा नियंत्रित किया जाना चाहिए।

@alexyak SelectedItems को एक वास्तविक, बाइंडेबल डिपेंडेंसीप्रॉपर्टी बनाने के आपके अनुरोध के संबंध में, यह राज्य को भी पुनर्स्थापित करने के लिए बहुत अच्छा होगा (अब तक मेरे अधिकांश फीचर अनुरोध दृश्य स्थिति को पुनर्स्थापित करने के लिए हैं)। मुझे लगता है कि यह एक ढांचा-व्यापी मुद्दा है, हालांकि यह किसी भी WinUI/UWP नियंत्रण में समर्थित नहीं है, जिसके बारे में मुझे पता है। यह शायद एक सामान्य सुविधा अनुरोध होना चाहिए। यहां देखें चर्चा

@anawishnoff ने लिखा:

आपका योगदान इतना विस्तृत और विचारशील है, उस सब के लिए आपका बहुत-बहुत धन्यवाद!

धन्यवाद, मुझे यह जानकर खुशी हुई कि मेरे योगदान डेटाग्रिड को और भी बेहतर बनाने में उपयोगी हैं :)

आप किस प्रकार की डेटा स्थिति/परिदृश्य की तलाश कर रहे हैं, विशेष रूप से? क्या आप डेटाग्रिड को सीधे SQL क्वेरी परिणाम, या डेटाबेस, या उन पंक्तियों के साथ कुछ कनेक्ट करना चाहते हैं?

यह अभी भी बहुत स्मार्ट है। यह स्मार्ट व्यवहार अलग-अलग ऐप्स को अलग-अलग तरीकों से डेटा पुनर्प्राप्ति करने से रोकता है। अलग-अलग ऐप्स में काफी अलग-अलग परिस्थितियां होती हैं, इस प्रकार "सर्वश्रेष्ठ" डेटा पुनर्प्राप्ति प्रणाली अलग-अलग ऐप्स के लिए अलग होती है - कोई भी "सर्वश्रेष्ठ" मौजूद नहीं होता है। उदाहरण के लिए, कुछ ऐप्स कभी भी दो सौ पंक्तियों से अधिक प्रदर्शित नहीं करते हैं, जबकि कुछ अन्य ऐप्स एक लाख पंक्तियों के साथ काम कर सकते हैं जैसे @dotMorten उल्लेख किया गया है, इसलिए एक जूते का आकार सभी में फिट नहीं होता है।

मैं वास्तव में इसे इस स्तर तक कम करने का सुझाव देता हूं:

1. डेटाग्रिड निर्णय लेता है कि उसे बाह्य डेटा संग्रहण प्रणाली में पंक्ति 9001 के कॉलम 5 में मौजूद मान को प्रदर्शित (या अन्यथा उपयोग) करने की आवश्यकता है।
2. डेटाग्रिड ऐप को सूचित करता है कि उसे पंक्ति 9001 के कॉलम 5 के लिए मान की आवश्यकता है।
3. ऐप पंक्ति 9001 के कॉलम 5 के मान को पुनः प्राप्त करता है। इसमें एक async SQL क्वेरी, या एक async C# कार्य, या कोई अन्य डेटा सिस्टम शामिल हो सकता है। आदर्श रूप से डेटाग्रिड को इस चरण को एसिंक्स होने देना चाहिए।
4. ऐप डेटाग्रिड को सूचित करता है कि उसने पंक्ति 9001 के कॉलम 5 के लिए मान प्राप्त करना समाप्त कर दिया है। ऐप डेटाग्रिड को यह मान देता है।
5. डेटाग्रिड किसी भी तरह से मूल्य का उपयोग करता है, जैसे कि चरण 1 में उल्लिखित मूल्य प्रदर्शित करना।

@RBid ने लिखा:

गैर-डेटा-बाध्य परिदृश्यों के लिए, हमें यह देखना चाहिए कि 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> ), या किसी भी प्रकार की देरी का समर्थन करने के लिए अद्यतन किया जाना चाहिए। डेटाग्रिड के बीच सेल वैल्यू का अनुरोध करना और ऐप डेटाग्रिड को सेल वैल्यू डिलीवर करना। इस प्रकार async का समर्थन करने के लिए इसे अद्यतन करने के लिए, यह करें:

1. ईवेंट को CellValueNeeded रखें।
2. संपत्ति निकालें DataGridViewCellValueEventArgs.Value ।
3. डेटाग्रिड में एक विधि बनाएं जिसका नाम 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. डेटाग्रिड निर्णय लेता है कि उसे बाह्य डेटा संग्रहण प्रणाली में पंक्ति 9001 के कॉलम 5 में मौजूद मान को प्रदर्शित (या अन्यथा उपयोग) करने की आवश्यकता है।
2. डेटाग्रिड सेलवैल्यू नेडेड ईवेंट को ट्रिगर करता है और DataGridViewCellValueEventArgs.RowIndex से 9001 और DataGridViewCellValueEventArgs.ColumnIndex से 5 तक सेट करता है।
3. ईवेंट हैंडलर (ऐप) एक एसिंक्स कार्य चलाना शुरू करता है जो पंक्ति 9001 के कॉलम 5 के लिए मान प्राप्त करेगा।
4. जब async कार्य चलना समाप्त हो जाता है, जिसका अर्थ है कि जब ऐप ने मान प्राप्त कर लिया है, तो ऐप DataGrid.SupplyCellValue विधि का आह्वान करता है।

यह डंब-डाउन तकनीक DataGridBoundColumn.Binding और DataGrid.ItemsSource की स्मार्ट स्वचालित तकनीक की तुलना में अधिक शक्तिशाली और लचीली है।

@alexyak , क्या आप थोड़ा और विस्तार कर सकते हैं? SelectedItems प्रॉपर्टी वर्तमान में आपको डेटाग्रिड में सभी चयनित आइटम प्राप्त करने की अनुमति देती है (विस्तारित चयन मोड के माध्यम से, सटीक रूप से एकाधिक चयन मोड नहीं)। मैं यहां कुछ अन्य टिप्पणियों से देखता हूं कि डेटाग्रिड के भीतर चयन को निश्चित रूप से काम करने की ज़रूरत है, लेकिन मैं आपके अनुरोध को बेहतर ढंग से समझना चाहता हूं।

हमें कई चयनों को प्रबंधित करने के लिए व्यूमॉडल के लिए उचित दो-तरफ़ा डेटाबेस की आवश्यकता है

@verelpode , हमने पुराने Win32 ComCtl32 नियंत्रणों के बाद भी WinForms DataGridView मॉडल का मॉडल तैयार किया था। विशेष रूप से, मैं इस बारे में सोच रहा हूं कि कैसे सूची-दृश्य नियंत्रण ने वर्चुअल मोड में LVN_GETDISPINFO संदेश का उपयोग किया (देखें https://docs.microsoft.com/en-us/windows/win32/controls/list-view-controls-overview #हैंडलिंग-वर्चुअल-लिस्ट-व्यू-कंट्रोल-नोटिफिकेशन-कोड और https://docs.microsoft.com/en-us/windows/win32/controls/lvn-getdispinfo)। 90 का पुराना सामान।

वैसे भी, मेरा मानना ​​​​है कि जिस तरह से एसिंक्रोनस डेटा पुनर्प्राप्ति पहलू को संभाला जाना चाहिए वह 'आस्थगित घटनाओं' के माध्यम से होता है।
WinUI नियंत्रण पहले से ही दो बार स्थगित घटनाओं का उपयोग करता है:

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

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

यह वह पैटर्न है जिसे नया डेटाग्रिड का CellValueNeeded ईवेंट अपनाना चाहेगा। यह ईवेंट हैंडलर को अतुल्यकालिक रूप से डेटा की आपूर्ति करने की अनुमति देता है और ऐसा करने पर नियंत्रण को बताता है। देखें https://docs.microsoft.com/en-us/uwp/api/windows.foundation.deferral।

@आरबीआरआईडी
GetDeferral() नया मानक पैटर्न होने के बारे में अच्छी बात है। CellValueNeeded इस विशेष मामले में, अन्य मामलों/घटनाओं की तुलना में Deferral का उपयोग करना अधिक कठिन लगता है। अगर मैं गलत हूं तो मुझे सुधारें, लेकिन मुझे लगता है कि इस विशेष मामले में GetDeferral() का उपयोग करने में समस्या यह है कि GetDeferral() हर बार इसे लागू करने पर एक नई वस्तु बनाता है, और इससे अत्यधिक संभावित रूप से बड़ी संख्या में पंक्तियों की प्रत्येक पंक्ति के प्रत्येक सेल के लिए वस्तु निर्माण और सफाई की भारी मात्रा में दोहराया जा रहा है। मैंने विभिन्न GetDeferral() कार्यान्वयनों का स्रोत कोड नहीं देखा है इसलिए मुझसे इस बारे में गलती हो सकती है।

दूसरे शब्दों में, जब तक Deferral रीसाइक्लिंग का समर्थन नहीं करता है या अन्यथा GetDeferral() और अधिक कुशल बनाने का कोई तरीका नहीं है, तब भी यह बहुत स्मार्ट है। SupplyCellValue पद्धति के साथ मेरा संक्षिप्त प्रस्ताव प्रत्येक लागू पंक्ति के प्रत्येक सेल के लिए एक नया Deferral इंस्टेंस बनाने, पूरा करने और निपटाने के ऊपरी हिस्से को SupplyCellValue करने से बचाता है।

1. GetDeferral()
2. deferral.पूर्ण
3. deferral.निपटान
4. उपरोक्त चरणों को बड़ी संख्या में दोहराएं।

सेल मान प्राप्त करने का कार्य केवल डेटा प्रबंधन कार्य नहीं है जिसे ऐप को आउटसोर्स किया जा सकता है। छँटाई भी आउटसोर्स की जा सकती है। इसलिए किसी एकल घटना CellValueNeeded बजाय एक इंटरफ़ेस के बारे में सोचने पर विचार करना सार्थक हो सकता है। एक ऐप डेटाग्रिड को एक ऑब्जेक्ट के रूप में डेटा प्रबंधन मॉड्यूल देगा जो एक निश्चित इंटरफ़ेस लागू करता है। डेटाग्रिड सेल मानों को पुनः प्राप्त करने के लिए इस इंटरफ़ेस को लागू करेगा, लेकिन संभावित रूप से अन्य कार्यों जैसे सॉर्टिंग भी।

@dotMorten ने उनका समर्थन करने के लिए, CellValueNeeded अकेले अन्य समस्या का समाधान नहीं करेगा जो तब होती है जब उपयोगकर्ता कॉलम हेडर पर क्लिक करता है और डेटाग्रिड एक मिलियन पंक्तियों को सॉर्ट करने का प्रयास करता है। इस प्रकार सेल पुनर्प्राप्ति और सॉर्टिंग को उपरोक्त मॉड्यूल/इंटरफ़ेस के माध्यम से ऐप को आउटसोर्स किया जा सकता है।

यदि ऐप डेटाग्रिड को किसी डेटा प्रबंधन मॉड्यूल/ऑब्जेक्ट की आपूर्ति नहीं करता है, तो आदर्श रूप से डेटाग्रिड एक डिफ़ॉल्ट डेटा प्रबंधन मॉड्यूल का उपयोग करेगा। इस प्रकार डेटाग्रिड में मौजूद सभी डेटा-बाइंडिंग कोड को डेटाग्रिड से बाहर ले जाया जाएगा और एक अलग नए वर्ग में ले जाया जाएगा - वह वर्ग जो DataGridBoundColumn.Binding आदि के साथ काम करके डिफ़ॉल्ट डेटा प्रबंधन मॉड्यूल को लागू करता है।

यानी जब छँटाई को ऐप या उसके डेटा प्रबंधन मॉड्यूल को भी आउटसोर्स किया जाता है, तो यह विभिन्न समाधानों के लिए द्वार खोलता है जो एक लाख पंक्तियों का समर्थन करते हैं, जैसे डेटा प्रबंधन मॉड्यूल लिखना जो SQL सर्वर को कोशिश करने के बजाय सॉर्टिंग करने का निर्देश देता है- और डेटाग्रिड के अंदर दस लाख पंक्तियों की छँटाई करने में विफल होने के बाद उपयोगकर्ता द्वारा छँटाई शुरू करने के लिए कॉलम हेडर पर क्लिक करने के बाद 10 या 20 घंटे से भी कम समय में।

@verelpode , हाँ यह एक वैध चिंता है। मैं उम्मीद करता हूं कि डेटाग्रिड रीसाइक्टेबल विंडोज़ के पूल का मालिक होगा। फाउंडेशन। डिफरल ऑब्जेक्ट्स। हमें निश्चित रूप से व्यवहार्यता और पूर्ण की पुष्टि करने की आवश्यकता होगी।

विंडोज कम्युनिटी टूलकिट डेटाग्रिड पर निर्भरता लेने के बाद, जिसमें एक फीचर के रूप में पंक्ति विवरण है (यद्यपि एक गंभीर प्रदर्शन बग के साथ लेकिन वर्कअराउंड के साथ), हम वास्तव में इस नए डेटाग्रिड को एक फीचर के रूप में भी पसंद करेंगे - उसी विकल्प के साथ एक साथ कई पंक्ति विवरण रखने के लिए। सर्वर से क्लाइंट स्ट्रीमिंग डेटा परिदृश्य के लिए इसका उपयोग करना।

पेजिंग जीयूआई बनाम दस लाख पंक्तियां, @robloo ने लिखा:

मैं सहमत हूं कि [एक लाख पंक्तियों का समर्थन करना] भी अच्छा होगा। .... उस ने कहा, अतीत में मैं पेजिंग को लागू करने के लिए पूर्ण डेटाबेस के आंशिक दृश्य का प्रतिनिधित्व करने वाला एक नया डेटाटेबल उत्पन्न करता हूं (जो इसके लिए एक अच्छा उपयोग मामला है)। उस डेटाटेबल का एक दृश्य तब आइटम स्रोत पर सेट किया जा सकता है। तो जबकि मुझे निश्चित रूप से लगता है कि यह अच्छा है कि यह उच्च प्रदर्शन के लिए अनिवार्य नहीं लगता है।

पेजिंग एक उपयोगी तकनीक है और उल्लेख करने योग्य है, लेकिन इसके काफी नुकसान हैं: यह डेटाग्रिड की सॉर्टिंग सुविधा को व्यावहारिक रूप से बेकार बना देता है। इसी तरह डेटाग्रिड के अगले संस्करण में फ़िल्टरिंग सुविधा के लिए। पेजिंग छँटाई और फ़िल्टरिंग को बेकार या कम से कम बहुत कम उपयोगी बनाता है।

उदाहरण के लिए, कल्पना करें कि 2 या 3 कॉलम दिनांक कॉलम हैं, और उपयोगकर्ता उन पंक्तियों को देखना चाहता है जिनकी दूसरी तिथि कॉलम में सबसे हाल की (या सबसे पुरानी) तिथि है। इस प्रकार उपयोगकर्ता उस कॉलम द्वारा डेटाग्रिड को सॉर्ट करने के लिए दूसरे दिनांक कॉलम हेडर पर क्लिक करता है, और सॉर्ट-दिशा को अवरोही से आरोही या इसके विपरीत बदलने के लिए भी क्लिक करता है। यह बहुत अच्छा काम करता है यदि कोई पेजिंग उपयोग में नहीं है, या यदि पंक्तियों की कुल मात्रा एक पृष्ठ से अधिक नहीं होने के लिए पर्याप्त छोटी है, लेकिन यदि एकाधिक पृष्ठ मौजूद हैं तो यह टूट जाता है।

उपयोगकर्ता को सभी पंक्तियों में सबसे हालिया (या सबसे पुरानी) तारीख खोजने की जरूरत है, लेकिन एक पृष्ठांकित डेटाग्रिड जीयूआई केवल वर्तमान पृष्ठ में सबसे हालिया (या सबसे पुरानी) तिथि दिखाता है, सभी पंक्तियों में नहीं, इस प्रकार पेजिंग व्यावहारिक रूप से सॉर्टिंग (और फ़िल्टरिंग) करता है बेकार।

यह सवाल उठाता है कि कौन सी पंक्तियाँ किस पृष्ठ पर आती हैं। जवाब यह है कि प्रत्येक पृष्ठ आम तौर पर, पंक्तियों का एक व्यावहारिक रूप से यादृच्छिक सबसेट होता है जब पृष्ठों / पंक्तियों एक SQL के माध्यम से प्राप्त कर रहे हैं SELECT क्वेरी जो उपयोग नहीं करता है ORDER BY । (मेरा मतलब उपयोगकर्ता के दृष्टिकोण से यादृच्छिक है, वास्तव में यादृच्छिक नहीं है।)

छद्म यादृच्छिक अंतिम उपयोगकर्ताओं के लिए अनुपयोगी है। इस समस्याग्रस्त यादृच्छिकता को खत्म करने के लिए, हम SQL ORDER BY ( ASC या DESC कीवर्ड के साथ सॉर्ट-दिशा को नियंत्रित करने के लिए) का उपयोग करने के बारे में सोच सकते हैं, और फिर हाँ पृष्ठ नहीं हैं लंबे समय तक यादृच्छिक, लेकिन यह अभी भी टूटा हुआ है क्योंकि ORDER BY का यह उपयोग हमेशा एक ही कॉलम और एक ही सॉर्ट-दिशा द्वारा क्रमबद्ध होता है, जिसका अर्थ है कि सॉर्ट ऑर्डर अक्सर अंतिम-उपयोगकर्ता द्वारा कॉलम पर क्लिक करने वाले सॉर्ट ऑर्डर से अलग होता है डेटाग्रिड में हेडर।

इसे ठीक करने के लिए, जब भी उपयोगकर्ता किसी भिन्न कॉलम हेडर पर क्लिक करता है, तो आपको एक अलग SQL क्वेरी का उपयोग करना होगा। SQL ORDER BY ... ASC/DESC को डेटाग्रिड के अंतिम-उपयोगकर्ता द्वारा चुने गए किसी भी प्रकार के क्रम के समान रखने की आवश्यकता होगी। डेटाग्रिड वर्तमान में इसका समर्थन नहीं करता है।

एक सुझाया गया समाधान मेरे पिछले संदेश में है : मैंने सुझाव दिया है कि डेटाग्रिड को सॉर्टिंग को ऐप (या "डेटा प्रबंधन मॉड्यूल") को आउटसोर्स करने की अनुमति देनी चाहिए। यह विचार ऐप (या "डेटा प्रबंधन मॉड्यूल") के लिए एसक्यूएल ORDER BY ... ASC/DESC को बदलना संभव बना देगा जब भी अंतिम उपयोगकर्ता कॉलम हेडर इत्यादि पर क्लिक करके डेटाग्रिड के सॉर्ट-ऑर्डर को बदलता है।

यह पहले से मौजूद ईवेंट DataGrid.Sorting को ईवेंट args में एक सेटटेबल प्रॉपर्टी देने के लिए भी उपयुक्त हो सकता है जो ऐप्स (ईवेंट हैंडलर) को सॉर्टिंग को रद्द करने और लेने की अनुमति देता है। आदर्श रूप से ईवेंट args यह भी निर्दिष्ट करेगा कि सॉर्ट ऑर्डर परिवर्तन का अनुरोध प्रोग्रामेटिक रूप से किया गया था बनाम कॉलम हेडर आदि पर क्लिक करने वाले एंड-यूज़र द्वारा अनुरोध किया गया था। इस मामले में, यह ईवेंट DataGrid.Sorting का नाम बदलकर कुछ कम अस्पष्ट करने में भी मदद कर सकता है। क्योंकि वर्तमान में Sorting घटना का इरादा और उद्देश्य स्पष्ट नहीं है। मेरे अन्य संदेश में प्रस्तावित

Windows समुदाय टूलकिट डेटाग्रिड पर निर्भरता लेने के बाद, जिसमें Row . है
एक सुविधा के रूप में विवरण (यद्यपि एक गंभीर प्रदर्शन बग के साथ लेकिन एक समाधान के साथ), हम करेंगे
वास्तव में इस नए डेटाग्रिड को एक सुविधा के रूप में भी पसंद है - एक ही विकल्प के साथ
एक साथ कई पंक्ति विवरण। सर्वर से क्लाइंट स्ट्रीमिंग डेटा परिदृश्य के लिए इसका उपयोग करना।

पंक्ति विवरण प्रदर्शन समस्या का लिंक: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2842
रेप्रो: https://github.com/observito/DataGridRowDetailsPerfTest

एक अच्छा प्रारंभिक बिंदु आपके पार्टनर टेलीरिक को उनके रेडडाटाग्रिड (यूडब्ल्यूपी ओपन सोर्स) के साथ देख रहा है। अपने ग्राहकों में से एक के साथ, मैंने इसका इस्तेमाल किया और यह वास्तव में अच्छी तरह से काम करता है। यह हाइपर फास्ट और बहुमुखी है। केवल एक चीज जो कठिन है वह है उनका कोड, आर्किटेक्चर की अच्छी समझ के बिना उनके इंजन से कुछ भी संशोधित करने का कोई तरीका नहीं है।

मैं उम्मीद करता हूं कि नया डेटाग्रिड टेलीरिक के रूप में प्रदर्शनकारी होगा।

सिंकफ़्यूज़न ग्रिड सुविधाएँ बहुत अच्छी हैं लेकिन वे mvvm के अनुकूल नहीं हैं। तो आप बेहतर कर सकते थे।

अरे फिर सब! आइए इस बातचीत को जारी रखें। वर्तमान में मौजूद डेटाग्रिड दस्तावेज़ों पर आपके क्या विचार हैं?

यहाँ एक है लिंक मुख्य दस्तावेज़ीकरण पृष्ठ पर है कि अन्य प्रासंगिक पृष्ठों के सभी के लिए लिंक।

यदि हम एक नया डेटाग्रिड बनाते हैं, तो हम यह सुनिश्चित करना चाहते हैं कि इसके साथ आने वाले दस्तावेज़ शीर्ष पर हों, समझने में आसान हों, और उन सभी मुद्दों और परिदृश्यों को संबोधित करते हैं जो हमारे डेवलपर्स के लिए महत्वपूर्ण हैं।

_ऐसे कुछ विषय क्या हैं जो आप चाहते हैं कि हमारे पास होते? ऐसे कौन से विषय हैं जिन्हें स्पष्ट किया जा सकता है?_

अरे फिर सब! आइए इस बातचीत को जारी रखें। वर्तमान में मौजूद डेटाग्रिड दस्तावेज़ों पर आपके क्या विचार हैं?

यहाँ एक है लिंक मुख्य दस्तावेज़ीकरण पृष्ठ पर है कि अन्य प्रासंगिक पृष्ठों के सभी के लिए लिंक।

यदि हम एक नया डेटाग्रिड बनाते हैं, तो हम यह सुनिश्चित करना चाहते हैं कि इसके साथ आने वाले दस्तावेज़ शीर्ष पर हों, समझने में आसान हों, और उन सभी मुद्दों और परिदृश्यों को संबोधित करते हैं जो हमारे डेवलपर्स के लिए महत्वपूर्ण हैं।

_ऐसे कुछ विषय क्या हैं जो आप चाहते हैं कि हमारे पास होते? ऐसे कौन से विषय हैं जिन्हें स्पष्ट किया जा सकता है?_

xaml और उन्हें बनाने के लिए कोड के साथ विशिष्ट डेटाग्रिड सेटअप दिखाने वाली छवियां उपयोगी होंगी।

xaml और उन्हें बनाने के लिए कोड के साथ विशिष्ट डेटाग्रिड सेटअप दिखाने वाली छवियां उपयोगी होंगी।

@mdtauk क्या कोई विशिष्ट डेटाग्रिड को उपयोग करने के लिए सबसे अच्छा विकल्प पाते हैं?

xaml और उन्हें बनाने के लिए कोड के साथ विशिष्ट डेटाग्रिड सेटअप दिखाने वाली छवियां उपयोगी होंगी।

@mdtauk क्या कोई विशिष्ट डेटाग्रिड को उपयोग करने के लिए सबसे अच्छा विकल्प पाते हैं?

मुझे लगता है कि WinUI 3.0 टाइमफ्रेम के लिए, सामान्य wpf, Win32 डेटा ग्रिड/आइकन दृश्य परिदृश्य दिखा रहा है। साथ ही माइक्रोसॉफ्ट फ्लुएंट/मॉडर्न डेटाग्रिड यूआई डिज़ाइन को क्या मानता है।

यानी अगर नियंत्रण के पीछे का विचार पुराने UI से WinUI 3 में जाने को प्रोत्साहित करना है

@anawishnoff मुझे लगता है कि टूलकिट से हमारे कुछ प्रश्न उन चीजों के संदर्भ में थे जहां लोग दस्तावेज़ीकरण की तलाश में थे जहां इनमें से अधिक परिदृश्य भी थे:

• थीमिंग/री-टेम्पलेटिंग/संरेखण
• डेटा बाइंडिंग (सामान्य रूप से और XAML में)
• घटना/चयन हैंडलिंग/आवरण
• संपादन व्यवहार (विशेषकर क्लिक पर संपादित करें)
• मल्टी-पेजिंग (जिसे #60 और #268 के साथ अच्छी तरह से जोड़ा जाना चाहिए)
  
  
  
  • डेटा लोड होने पर एनिमेशन समन्वय लोड हो रहा है
  
  
• कॉपी/पेस्ट/स्वरूपण
• विभिन्न कॉलम डेटा प्रकार (और कस्टम वाले) (जैसे एनम)
• प्रसंग मेनू
• सरल उपयोग

मैंने देखा है कि मौजूदा टूलकिट डेटाग्रिड को अपनी आइटम्ससोर्स संपत्ति के लिए एक आईनेमरेबल की आवश्यकता है। हालांकि यह एक तार्किक निर्णय की तरह लगता है, यह Windows.Storage.BulkAccess.FileInformationFactory.GetVirtualizedItemsVector() द्वारा लौटाए गए ऑब्जेक्ट को इस गुण के रूप में असंभव बना देता है। (जब तक ऑब्जेक्ट को वापस करने का कोई तरीका नहीं है) इसके अलावा, ListView और GridView जैसे अन्य नियंत्रण उनकी ItemsSource प्रॉपर्टी को ऑब्जेक्ट प्रकार के मान पर सेट करने का समर्थन करते हैं। मैं निश्चित नहीं हूं, लेकिन इसका समर्थन करने से स्टोरेज ऑपरेशंस के दौरान अधिक प्रतिक्रियाशील यूजर इंटरफेस की अनुमति मिल जाएगी।

@mdtauk क्या कोई विशिष्ट डेटाग्रिड को उपयोग करने के लिए सबसे अच्छा विकल्प पाते हैं?

मुझे लगता है कि WinUI 3.0 टाइमफ्रेम के लिए, सामान्य wpf, Win32 डेटा ग्रिड/आइकन दृश्य परिदृश्य दिखा रहा है। साथ ही माइक्रोसॉफ्ट फ्लुएंट/मॉडर्न डेटाग्रिड यूआई डिज़ाइन को क्या मानता है।

यानी अगर नियंत्रण के पीछे का विचार पुराने UI से WinUI 3 में जाने को प्रोत्साहित करना है

Win32 उदाहरण (फ़ाइल एक्सप्लोरर)

डब्ल्यूपीएफ उदाहरण

फैब्रिक वेब उदाहरण

यूडब्ल्यूपी उदाहरण

@mdtauk उन स्क्रीनशॉट के लिए धन्यवाद! मुझे निश्चित रूप से लगता है कि नियंत्रण और दस्तावेज़ के पिछले संस्करणों में काम करने वाले प्रमुख तत्वों को हाइलाइट करना महत्वपूर्ण है कि उन्हें नए नियंत्रण के साथ कैसे प्राप्त किया जा सकता है।

@ माइकल-हॉकर बहुत बढ़िया। मैं वहां पहले से ही कुछ विषयों को देख रहा हूं जिन्हें इस धागे पर कई बार लाया गया है, इसलिए वे निश्चित रूप से शुरू करने के लिए एक अच्छी जगह हैं।

@ duke7553 मैं इसके समाधान के बारे में 100% निश्चित नहीं हूं, या यदि किसी ऑब्जेक्ट प्रकार का समर्थन करना बुद्धिमान होगा। हो सकता है कि @RBrid झंकार कर

@anawishnoff और @ duke7553 , मैं नए WinUI ItemsRepeater नियंत्रण के शीर्ष पर नया डेटाग्रिड नियंत्रण तैयार करूंगा। और वह नियंत्रण अपने आइटम्ससोर्स को ऑब्जेक्ट के रूप में उजागर करता है:
Object ItemsSource { get; set; };

आशा है कि यह Telerik की तरह CellDecorationStyleSelector को सपोर्ट करेगा।

@anawishnoff

हम इसे मूल WinUI नियंत्रण में बदलने में रुचि रखते हैं

हम्मम्म जब आप "स्नातक" कहते हैं, तो क्या इसमें इसे सी ++ में डाउनग्रेड करना शामिल होगा? वर्तमान में WinUI का डेटाग्रिड C# में लिखा गया है। मुझे आशा है कि "स्नातक" का अर्थ "डाउनग्रेड" नहीं होगा। महत्वपूर्ण बात यह है कि विनयूआई को उस बिंदु तक पहुंचने की जरूरत है जहां विनयूआई टीम कह सके कि विनयूआई डब्ल्यूपीएफ से हर तरह से बेहतर है, लेकिन यह लक्ष्य बहुत ही अतिदेय है। यह लक्ष्य और भी अतिदेय हो जाएगा यदि डेटाग्रिड जैसे कोड के अनावश्यक डाउनग्रेड में समय/संसाधन बर्बाद हो जाते हैं सी # से सी ++ तक।

हालाँकि मूल रूप से C++ में WinRT/UWP/WinUI लिखने का एक कारण मौजूद था, दुर्भाग्य से वह कारण सफल नहीं हुआ, और Google/Android ने अधिकांश स्मार्टफोन मार्केटशेयर ले लिए, इसलिए C++ का उपयोग करने का मूल कारण अब लागू नहीं है (आसानी से) पीछे से कहा, लेकिन पहले कहना इतना आसान नहीं है)। यदि WinUI को शुरू से ही C# में लिखा गया होता, तो बेहतर-से-WPF लक्ष्य 3 साल पहले हासिल कर लिया जाता, लेकिन अब 8 साल हो गए हैं और अभी भी हासिल नहीं हुआ है, और कोई भी सटीक रूप से यह नहीं कह सकता कि लक्ष्य कब पूरा होगा। उम्मीद है कि बेहतर-से-WPF लक्ष्य और WinUI डेटाग्रिड "स्नातक" लक्ष्यों को एक पुरानी और कम उत्पादक प्रोग्रामिंग भाषा में अनावश्यक रूपांतरण द्वारा विलंबित नहीं किया जाएगा।

मैं सी ++ के पक्ष में पक्षपाती हूं क्योंकि मैंने सी ++ में प्रोग्रामिंग शुरू कर दी थी, इससे पहले कि सी # भी अस्तित्व में था, और लोग मूल रूप से जो कुछ सीखते थे, उसके साथ रहना पसंद करते हैं, और याद करते हैं _ "अच्छे पुराने दिन"_। सी ++ के पक्ष में मेरे पूर्वाग्रह के बावजूद, मैंने सी ++ लिखना बंद कर दिया, और मुझे लगता है कि डेटाग्रिड को सी ++ में डाउनग्रेड नहीं किया जाना चाहिए और देरी हो सकती है। इसे C# के रूप में छोड़ दें और अधिक महत्वपूर्ण चीजों पर ध्यान केंद्रित करें जैसे कि इस मुद्दे में लोगों द्वारा सुझाए गए विभिन्न सुधार करना, और 1 दशक से पहले बेहतर-WPF लक्ष्य प्राप्त करना।

मुझे विनयूआई के कई पहलू पसंद हैं, और मैं इसमें कई चतुर सुधारों की सराहना करता हूं, और मैं विनयूआई के लिए ऐप कोड लिखता हूं, लेकिन क्या आप ईमानदार सच्चाई जानना चाहते हैं? सच्चाई यह है कि, दुख की बात है कि मैंने अभी तक उपयोगकर्ताओं के लिए कोई भी WinUI ऐप जारी नहीं किया है। उपयोगकर्ताओं के लिए जारी किया गया सॉफ़्टवेयर wpf के साथ लिखा गया है, और उपयोगकर्ताओं को परवाह नहीं है क्योंकि सॉफ़्टवेयर अच्छी तरह से काम करता है और इसमें GUI आधुनिकीकरण शामिल है। हालाँकि मैंने WinUI के लिए ऐप कोड का एक पूरा गुच्छा लिखा है, यह सभी तैयारी, योजना, परीक्षण, प्रतीक्षा है, वास्तव में उपयोगकर्ताओं द्वारा उपयोग में नहीं है। उम्मीद है कि अगले साल पहला विनयूआई घटक उपयोगकर्ताओं के लिए जारी किया जाएगा, लेकिन मैं इस स्विच-ओवर की उनकी अपेक्षा से कहीं अधिक सराहना करूंगा। यदि सब कुछ योजना के अनुसार चला जाता है, तो उपयोगकर्ता शायद ही स्विच-ओवर को नोटिस करेंगे।

Microsoft के दृष्टिकोण से, WinRT/UWP रिलीज़-गुणवत्ता वाला सॉफ़्टवेयर है, जो वर्ष 2012 से उपयोगकर्ताओं के लिए प्रकाशित किया गया है, लेकिन मेरे दृष्टिकोण से, UWP अभी भी एक बड़ा प्रयोग है। मेरे लिए, यूडब्ल्यूपी (विनयूआई समेत) एक बड़ा बीटा-टेस्ट संस्करण है जिसे मैं वर्षों से खेल रहा हूं।

यूडब्ल्यूपी के पहले कुछ वर्षों के दौरान, हर साल मैंने सोचा: _"गलती... मैं अगले साल तक इंतजार करूंगा। डब्ल्यूपीएफ में अभी भी बहुत सी चीजें हैं जो यूडब्ल्यूपी में गायब हैं। निश्चित रूप से अगला साल बेहतर होगा।"
फिर अगला साल आया और मैंने वही विचार दोहराया। फिर अगला साल आया और मैंने वही विचार दोहराया। उम्मीद है कि यह कहने का यह साल आखिरी साल है, या कम से कम यही मेरा इरादा है।

WinUI अधिक विलंब बर्दाश्त नहीं कर सकता। WinUI के डेटाग्रिड को C# कोड के रूप में छोड़ दें। उत्पादकता बढ़ाने के लिए C# में अधिक WinUI कोड लिखना प्रारंभ करें। अब 8 साल हो गए हैं और एंड्रॉइड ने बड़े पैमाने पर बाजार हिस्सेदारी हासिल कर ली है। यह एक गंभीर स्थिति है।

वैसे, मैं वास्तव में अच्छा/उदार था जब मैंने कहा कि यूडब्ल्यूपी अभी भी एक बीटा संस्करण है, क्योंकि तकनीकी रूप से यूडब्ल्यूपी अल्फा संस्करण की परिभाषा से मेल खाता है, बीटा नहीं। एक सच्चा बीटा संस्करण होने के लिए, इसे फीचर-पूर्ण होना चाहिए, लेकिन यूडब्ल्यूपी अभी तक फीचर-पूर्ण स्थिति तक नहीं पहुंचा है, इसलिए यूडब्ल्यूपी अभी भी अल्फा है। उदाहरण के लिए, विकिपीडिया का "सॉफ़्टवेयर रिलीज़ जीवन चक्र" लेख कहता है:

"बीटा चरण आम तौर पर तब शुरू होता है जब सॉफ़्टवेयर सुविधा पूर्ण हो जाता है लेकिन इसमें कई ज्ञात या अज्ञात बग होने की संभावना होती है।"
"अल्फा सॉफ़्टवेयर में वे सभी सुविधाएँ नहीं हो सकती हैं जो अंतिम संस्करण के लिए नियोजित हैं।"

विकिपीडिया "सुविधा पूर्ण" को इस प्रकार

"सॉफ्टवेयर के एक टुकड़े के एक फीचर पूर्ण संस्करण में इसकी सभी नियोजित या प्राथमिक विशेषताएं लागू की गई हैं लेकिन बग, प्रदर्शन या स्थिरता के मुद्दों के कारण अभी तक अंतिम नहीं है। यह विकास के अल्फा परीक्षण के अंत में होता है।"

यूडब्ल्यूपी को फीचर-पूर्ण के रूप में वर्णित करना अनुचित होगा क्योंकि अगर यह वास्तव में फीचर-पूर्ण है, तो यूडब्ल्यूपी में विंडोज '95 की सभी क्षमताएं और अधिक होनी चाहिए, लेकिन ऐसा नहीं है - यूडब्ल्यूपी अभी तक सभी क्षेत्रों में विंडोज 95 से अधिक नहीं है . विंडोज 95 25 साल पहले जारी किया गया था। जब 7-8 साल पहले UWP/WinRT जारी किया गया था, तो Microsoft को $900 मिलियन का नुकसान हुआ था और विंडोज स्टोर में ऐप्स की कमी का सामना करना पड़ा था। यह एक अल्फा संस्करण था जिसे रिलीज़ संस्करण के रूप में लेबल किया गया था, इस प्रकार ऐप डेवलपर्स ने इंतजार किया और देखा। आज, लगभग 8 साल बाद, यह अभी भी एक अल्फा संस्करण है और बहुत अतिदेय है, और मैं अभी भी प्रतीक्षा कर रहा हूं और देख रहा हूं और प्रतीक्षा कर रहा हूं।

यह माइक्रोसॉफ्ट और डेवलपर्स के लिए बहुत फायदेमंद होगा यदि माइक्रोसॉफ्ट यूडब्ल्यूपी के एक सच्चे बीटा संस्करण के उत्पादन को प्राथमिकता देने के लिए एक गंभीर निर्णय/प्रतिबद्धता करेगा, जिसके बाद एक सच्चे रिलीज उम्मीदवार संस्करण का तुरंत पालन किया जाएगा। यह अत्यधिक अनुशंसित और कार्रवाई का एक बहुत ही समझदार तरीका होगा। यह सभी के लिए बेहतरीन होगा।

यूडब्ल्यूपी अभी भी कई कारणों से अल्फा/अपूर्ण है, उदाहरण के लिए: 25 साल पहले, फ़ाइल या फ़ोल्डर को स्थानांतरित करने के लिए विंडोज 95 में "मूवफाइल" फ़ंक्शन का उपयोग करना आसान था (हालांकि फ़ंक्शन को "मूवफाइल" नाम दिया गया था, यह दोनों फाइलों का समर्थन करता था और फ़ोल्डर्स)। क्या UWP फ़ोल्डर्स को स्थानांतरित कर सकता है? नहीं अभी तक नहीं। स्पष्ट रूप से फ़ोल्डरों को स्थानांतरित करने की क्षमता मूलभूत बुनियादी आवश्यक विशेषताओं में से एक है, लेकिन यूडब्ल्यूपी में अभी भी यह आवश्यक सुविधा और अन्य गायब है, इसलिए यूडब्ल्यूपी को फीचर-पूर्ण के रूप में वर्णित करना अनुचित होगा, इसलिए यूडब्ल्यूपी अभी तक बीटा स्थिति तक नहीं पहुंचा है, इसके बावजूद 7-8 साल पहले रिलीज हो रही है। Microsoft को UWP के एक सच्चे बीटा संस्करण को प्राथमिकता देने की आवश्यकता है।

यूडब्ल्यूपी मुद्दों (यूआई मुद्दों के अलावा) को ट्रैक करने के लिए एक सार्वजनिक गिटहब रेपो अभी तक मौजूद नहीं है, जहां तक ​​​​मुझे पता है (या यदि कोई यूडब्ल्यूपी रेपो मौजूद है, तो मुझे यह नहीं मिला)। फिर से यह एक अल्फा संस्करण की परिभाषा से मेल खाता है क्योंकि एक सार्वजनिक मुद्दा-ट्रैकिंग रेपो अक्सर अल्फा चरण के दौरान अवांछित होता है। यदि यह एक सच्चा बीटा या रिलीज़ संस्करण होता, तो एक सार्वजनिक इश्यू-ट्रैकिंग रेपो पहले ही खोला जा चुका होता, और UWP में Windows 95, और Windows 7, और अधिक की सभी सुविधाएँ शामिल होतीं।

यह स्थिति डेटाग्रिड को कैसे प्रभावित करती है? यह देखते हुए कि यूडब्ल्यूपी का एक फीचर-पूर्ण बीटा संस्करण बहुत अतिदेय है, और इस स्थिति की गंभीरता और माइक्रोसॉफ्ट को इसके परिणामस्वरूप होने वाले बहु-अरब डॉलर के नुकसान को देखते हुए, और भी अधिक समय बर्बाद करना उचित और उचित नहीं होगा। WinUI डेटाग्रिड को अप्रबंधित कोड और एक पुरानी प्रोग्रामिंग भाषा में परिवर्तित करके। माइक्रोसॉफ्ट ने बार-बार कहा कि सी # और "प्रबंधित कोड" का एक बड़ा फायदा उत्पादकता में वृद्धि है, और मैं कह सकता हूं कि "प्रबंधित कोड" के बारे में माइक्रोसॉफ्ट के दावे सी ++ और सी # दोनों के साथ मेरे अनुभवों में निश्चित रूप से सच थे। यूडब्ल्यूपी कई साल पहले वास्तविक बीटा स्थिति में पहुंच गया होता अगर इसे मुख्य रूप से संस्करण 1.0 से शुरू होने वाले प्रबंधित कोड का उपयोग करके लिखा गया था। इसलिए मुझे आशा है कि प्रबंधित कोड से अप्रबंधित कोड में इन अनावश्यक डाउनग्रेडों को और भी अधिक करने से स्थिति और भी खराब नहीं होगी।

तुलना के लिए, अधिकांश डब्ल्यूपीएफ 2006 से 2010 तक 4 वर्षों में सफलतापूर्वक पूरा किया गया था। डब्ल्यूपीएफ मुख्य रूप से यूडब्ल्यूपी के विपरीत, प्रबंधित कोड है। UWP अप्रबंधित कोड है और 8 वर्षों के विकास के बाद, Windows 95 अभी भी कुछ क्षेत्रों में UWP को मात देता है, इसलिए Microsoft स्पष्ट रूप से सही था जब Microsoft ने दावा किया कि प्रबंधित कोड उत्पादकता बढ़ाता है। इस समस्या को जल्द से जल्द हल करने की जरूरत है। WinUI को wpf की तुलना में बनाना बहुत आसान/तेज होना चाहिए था क्योंकि दोनों प्रोजेक्ट्स का एक ही मालिक (Microsoft) है, इस प्रकार WinUI को wpf से कोड कॉपी करने की स्वतंत्र रूप से अनुमति है। इस प्रकार विनयूआई को डब्ल्यूपीएफ के लगभग आधे विकास समय की आवश्यकता होनी चाहिए। वास्तव में विनयूआई को कभी भी शुरू नहीं किया जाना चाहिए था, बल्कि माइक्रोसॉफ्ट को डब्ल्यूपीएफ के नए संस्करणों में विनयूआई की विशेषताओं को विकसित करना चाहिए था - विनयूआई को डब्ल्यूपीएफ 5.0 होना चाहिए था। इसलिए, स्थिति एक बड़ी गड़बड़ी थी और Microsoft के लिए इस गंदगी की शेष सफाई को प्राथमिकता देना बहुत फायदेमंद होगा, और उन चीजों को करना बंद कर दें जो बहु-अरब डॉलर की गलती को पहले से भी बदतर बना देती हैं (और तब भी जब आप देखते हैं आज की स्मार्टफोन मार्केटशेयर स्थिति में)।

इसका अर्थ है, और भी अधिक हानियों को रोकने के लिए, Microsoft को यह याद रखने से लाभ होगा कि Microsoft ने पहले क्या कहा/जानता था:

• Microsoft के अपने दावों के अनुसार प्रबंधित कोड उत्पादकता बढ़ाता है। जब आप डब्ल्यूपीएफ के 4 वर्षों की तुलना में यूडब्ल्यूपी के 8 वर्षों को देखते हैं, तो निष्कर्ष यह होना चाहिए कि माइक्रोसॉफ्ट प्रबंधित कोड के लाभों के लिए सही था।
• स्क्रिप्टिंग भाषाएँ स्क्रिप्टिंग के लिए हैं, और प्रोग्रामिंग भाषाएँ प्रोग्रामिंग के लिए हैं। जावास्क्रिप्ट और पावरशेल अपने इच्छित उद्देश्यों (स्क्रिप्टिंग) के लिए अच्छे हैं, लेकिन वे स्पष्ट रूप से ऐप्स की प्रोग्रामिंग के लिए अनुपयुक्त विकल्प हैं।
• सफल होने के लिए, माइक्रोसॉफ्ट को रिलीज करने के लिए अल्फा से बीटा में प्रगति करनी चाहिए, और यह केवल तभी सफल होता है जब यह एक वास्तविक रिलीज संस्करण है, न कि "रिलीज" के रूप में लेबल किया गया अधूरा अल्फा। इस प्रकार माइक्रोसॉफ्ट स्टोर ज्यादातर लंबे समय तक खाली रहा।
• सॉफ्टवेयर इंजीनियर और अन्य कर्मचारी तब सबसे अच्छा काम करते हैं जब वे उचित पारिश्रमिक और काम के घंटों की उचित संख्या और स्वस्थ कामकाजी माहौल के बदले में काम करते हैं। जाहिर है, Microsoft के बहु-अरब डॉलर के नुकसान को अवैतनिक कट्टरपंथियों / उत्साही लोगों और उनके तथाकथित "दिन की नौकरियों" और "रात की नौकरियों" और उनकी अस्थिर / अस्वस्थ कार्य स्थितियों के उपयोग से कभी भी उलट नहीं किया जाएगा।
• एंड्रॉइड की विशाल मार्केटशेयर जीत अवैतनिक कट्टरपंथियों के लिए धन्यवाद नहीं थी। यदि अवैतनिक कट्टरपंथियों की जीत का कारण होता, तो लिनक्स विफल नहीं होता। स्पष्टीकरण कहीं अधिक सरल है: एंड्रॉइड टैबलेट और स्मार्टफोन की कीमत विंडोज टैबलेट और स्मार्टफोन की तुलना में बहुत कम है। जाहिर है कि अंतिम उपयोगकर्ता "ओपन सोर्स" धर्मों/विचारधाराओं की परवाह नहीं करते हैं (उपयोगकर्ताओं को यह भी नहीं पता कि वह क्या है), बल्कि वे केवल एंड्रॉइड डिवाइसों की सस्ती कीमतों से प्यार करते हैं।
• Win16 अत्यंत अप्रचलित है। यह प्रोग्रामिंग के शुरुआती "वाइल्ड वेस्ट" दिनों से 20-30 साल पहले की तकनीक है। इसलिए, Win16 पर आधारित नया कोड लिखना बंद करें। इसे "Win32" कहना वास्तव में इस तथ्य को नहीं बदलता है कि यह अभी भी मूल रूप से Win16 है। Win32 Win16 के समान ही है, सिवाय इसके कि पॉइंटर्स का आकार 16 बिट्स से 32 बिट्स तक विस्तारित हो। Microsoft के बहुत से समूह Win16/32 पर आधारित नया कोड लिखना जारी रखते हैं। यह बहुत ही अक्षम और संसाधनों की एक बड़ी बर्बादी है।

@anawishnoff

हम इसे मूल WinUI नियंत्रण में बदलने में रुचि रखते हैं

विकिपीडिया का लेख "सनक कॉस्ट" भी देखें:

डूब लागत प्रभाव (या कॉनकॉर्ड प्रभाव) यह तथ्य है कि व्यवहार अक्सर डूब लागत भ्रम का अनुसरण करता है; लोग "पैसे, प्रयास, या समय में निवेश करने के बाद एक बार प्रयास जारी रखने की अधिक प्रवृत्ति" प्रदर्शित करते हैं। इस व्यवहार को "बुरे के बाद अच्छा पैसा फेंकने" के रूप में वर्णित किया जा सकता है और इसके आगे झुकने से इनकार करने को "किसी के नुकसान को काटने" के रूप में वर्णित किया जा सकता है।

और इसी तरह "योजना निरंतरता पूर्वाग्रह" :

योजना जारी रखने का पूर्वाग्रह, गेट-वहाँ-इटिस या प्रेस-ऑन-इटिस एक ऐसी योजना के साथ बने रहने की एक नासमझी प्रवृत्ति है जो विफल हो रही है। यह जहाज के कप्तानों या विमान के पायलटों के लिए एक खतरनाक खतरा है, जो एक नियोजित पाठ्यक्रम पर टिके रह सकते हैं, भले ही यह घातक आपदा की ओर ले जा रहा हो और उन्हें इसके बजाय गर्भपात करना चाहिए। ..... परियोजनाओं में अक्सर लागत में वृद्धि और देरी का सामना करना पड़ता है क्योंकि योजना की गड़बड़ी और संबंधित कारकों में अत्यधिक आशावाद, विफलता को स्वीकार करने की अनिच्छा, समूह विचार और डूब लागत के नुकसान के प्रति घृणा शामिल है।

WinRT/UWP के कारण Microsoft को पहले या दूसरे वर्ष में $900 मिलियन का नुकसान हुआ, और एक खाली ऐप स्टोर बहुत लंबे समय तक चला। WinRT/UWP एक विनाशकारी विफलता थी, इस प्रकार इसे दूसरे वर्ष में निरस्त कर दिया जाना चाहिए था, लेकिन "योजना निरंतरता पूर्वाग्रह" और डूब लागत के नुकसान के प्रति घृणा के कारण इसे जारी रखा गया था। यह सामान प्रबंधन पाठ्यक्रमों में पढ़ाया जाता है। क्या योजना की निरंतरता ने अंततः WinRT/UWP की विनाशकारी विफलता को मिटा दिया या उलट दिया? नहीं, अगर आप स्मार्टफोन मार्केटशेयर के संदर्भ में देखें तो यह आज भी एक भयावह विफलता है। विकिपीडिया में वे विवरण UWP की स्थिति का सटीक वर्णन करते हैं।

अब आज हम सभी को इस बात से सहमत होना होगा कि वर्तमान समय में, WinRT/UWP के जारी होने के 7-8 साल बाद, अब UWP को रद्द करने में बहुत देर हो चुकी है, लेकिन इसका मतलब है कि हम फिर से "योजना निरंतरता पूर्वाग्रह" के शिकार हो रहे हैं। "और डूबी हुई लागतों के नुकसान का विरोध।

तो स्थिति को बचाने के लिए उचित रूप से क्या किया जा सकता है? हम यूडब्ल्यूपी को रद्द करके स्थिति को नहीं बचा सकते, भले ही इसे निश्चित रूप से वर्षों पहले रद्द कर दिया जाना चाहिए था। हम यह क्या कर सकते हैं: WinRT द्वारा की गई विशाल क्षति को स्वीकार करें, लेकिन कोई और नुकसान न करें, और परियोजना की प्रक्रियाओं/नीतियों में परिवर्तन करें। इसका मतलब है, WinRT की वही भयावह गलतियों को दोहराना / जारी रखना बंद करें। उदाहरण के लिए, प्रबंधित कोड की इतनी बड़ी मात्रा को अनुत्पादक पुराने अप्रबंधित "मूल" कोड में डाउनग्रेड करना बंद करें। वास्तविक बीटा स्थिति तक पहुँचने में देरी पहले से ही बहुत बड़ी है - देरी को और भी बदतर क्यों बनाते हैं?

यदि डेटाग्रिड को अप्रबंधित "मूल" कोड में डाउनग्रेड किया जाता है, तो "योजना निरंतरता पूर्वाग्रह" / डूबने की लागत की गलती जारी रहती है। जब WinRT/UWP जैसी विपत्तिपूर्ण गलती की जाती है, तो यह तब और भी बदतर हो जाती है जब वही गलती बार-बार दोहराई जाती है। क्षति को सीमित करने के लिए, उसी गलती को दोहराना बंद करना आवश्यक है। यह WinRT की भयावह विफलता से सीखने और चल रहे रक्त की हानि को रोकने के लिए पट्टियाँ लगाने का सही समय है।

डेटाग्रिड को अप्रबंधित कोड में बदलना एक पुस्तकालय में जाने और सबसे अधिक ज्ञान/अनुभव वाले सर्वश्रेष्ठ लेखकों से सभी बेहतरीन परियोजना प्रबंधन पुस्तकों को उधार लेने और फिर इन सभी उत्कृष्ट प्रबंधन पुस्तकों को अलाव में फेंकने और उन्हें जलते हुए देखने के समान है।

@verelpode मैं उत्सुक हूं कि यहां आपकी दो बहुत बड़ी पोस्ट

@dotMorten - उन संदेशों में अतिरिक्त विवरण लिखने का कारण यह है कि यदि मैं समस्या को पर्याप्त रूप से नहीं समझाता, तो लोग इसे नहीं समझेंगे। लेकिन दुख की बात है कि अब मैं देख रहा हूं कि अतिरिक्त विवरण विफल हो गया और यह अभी भी समझ में नहीं आया। यह बहुत निराशाजनक है। यही कारण है कि बहुत से लोग किसी भी प्रतिक्रिया को लिखने से भी गुरेज नहीं करते हैं, क्योंकि उनका मानना ​​है कि इस प्रकार के मुद्दों को लोगों को समझाने की कोशिश करना व्यर्थ है, और भले ही संदेश को सफलतापूर्वक समझा जा सके, फिर भी शूट करना मानव स्वभाव है। वह व्यक्ति जो बुरी खबर देता है, तो बेहतर होगा कि कुछ भी न कहें, या इसके विपरीत सोचते हुए केवल "विनम्रतापूर्वक" मुस्कुराएं।

क्योंकि यह v3 के साथ पूरी तरह से अनबाउंड हो रहा है।

यह v3 अनबाइंडिंग समान गलतियों की पुनरावृत्ति को नहीं रोकता है। "योजना निरंतरता पूर्वाग्रह" अभी भी मौजूद है।

माइक्रोसॉफ्ट के होम पेज पर जाएं:
https://www.microsoft.com/en-us/
अब होम पेज को तब तक नीचे स्क्रॉल करें जब तक आपको विंडोज फोन दिखाई न दे। ओह! उस ओर देखो! हम होम पेज के अंत में पहुंच गए हैं और माइक्रोसॉफ्ट के होम पेज पर विंडोज फोन का कहीं भी उल्लेख नहीं है! इसका क्या मतलब है? यानी जागो। इसका मतलब है कि यूडब्ल्यूपी एक विनाशकारी विफलता थी जैसा कि मैंने कहा। इसका मतलब है, उन्हीं गलतियों को दोहराना बंद करना महत्वपूर्ण है जिनके कारण UWP की विफलता हुई। इसका मतलब है, आपदा से बचाव और उबरने के लिए योजना में बदलाव करना।
यह एक प्रबंधन गलती होगी यदि WinUI और DataGrid UWP की विफलता के समान ही गलतियों को दोहराना जारी रखते हैं।

"मई 2016 में, माइक्रोसॉफ्ट ने अपने मोबाइल व्यवसाय को नष्ट कर दिया, .... 2017 में, माइक्रोसॉफ्ट के कार्यकारी जो बेल्फ़ोर ने खुलासा किया कि माइक्रोसॉफ्ट ने विंडोज 10 मोबाइल के लिए नए विंडोज फोन और नई सुविधाओं के विकास को बंद कर दिया था, बाजार हिस्सेदारी में कमी और कमी का हवाला देते हुए ऐप डेवलपमेंट।"
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

एना डेटाग्रिड पर प्रतिक्रिया प्रदान करने के लिए 5 बिंदुओं को सूचीबद्ध करती है। आप इनमें से किस बिंदु पर टिप्पणी कर रहे हैं? मुझे लगता है कि आप जो लिख रहे हैं उससे मुझे कुछ समझ नहीं आ रहा है। UWP सभी की आवश्यकता को पूरा नहीं करता है, लेकिन WinUI3 UWP ऐप मॉडल का उपयोग करके निर्देशित नहीं करता है, और आप ज्यादातर UWP के खिलाफ लगते हैं? तो आपको वहां ठीक होना चाहिए।

आपने उल्लेख किया है कि डेटाग्रिड को वही गलतियाँ नहीं करनी चाहिए जो उसने कीं। तो वे कौन सी गलतियाँ हैं जो विशेष रूप से मौजूदा डेटाग्रिड को प्रभावित करती हैं, और आप कैसे सुझाव देते हैं कि उन्हें ठीक किया जाना चाहिए? (इसके अलावा आप इसे किसी कारण से सी ++ में लागू नहीं करना चाहते हैं)

@dotMorten

एना डेटाग्रिड पर प्रतिक्रिया प्रदान करने के लिए 5 बिंदुओं को सूचीबद्ध करती है। आप इनमें से किस बिंदु पर टिप्पणी कर रहे हैं?

वह हिस्सा जहां मैंने अपने संदेश की शुरुआत में एना को उद्धृत किया था। मैं एना के संदेश के उस हिस्से पर टिप्पणी कर रहा हूं जिसे मैंने अपने संदेश की शुरुआत में उद्धृत किया था।

WinUI3 UWP ऐप मॉडल का उपयोग करके निर्देशित नहीं करता है

यह मेरे संदेश से संबंधित नहीं है। WinUI 3 का अनबाउंड और nuget पैकेज के माध्यम से उपलब्ध होना इस सवाल के लिए अप्रासंगिक है कि क्या WinUI 3 वही प्रबंधन गलतियाँ जारी रखता है जिसके कारण UWP और Windows Phone और Microsoft के बहु-अरब डॉलर का नुकसान हुआ।

आप कैसे सुझाव देते हैं कि उन्हें ठीक किया जाना चाहिए?

मेरे पिछले संदेश के अंत में 6 गोली इंगित करती है। दूसरा बुलेट पॉइंट (स्क्रिप्टिंग) सामान्य रूप से WinUI और UWP से संबंधित है, लेकिन डेटाग्रिड से संबंधित नहीं है। यदि आप विशेष रूप से डेटाग्रिड के बारे में पूछ रहे हैं तो पहला बुलेट बिंदु सबसे महत्वपूर्ण है।
मैंने यह भी लिखा: प्रबंधित कोड की इतनी बड़ी मात्रा को अनुत्पादक पुराने अप्रबंधित "मूल" कोड में डाउनग्रेड करना बंद करें। वास्तविक बीटा स्थिति तक पहुँचने में देरी पहले से ही बहुत बड़ी है - देरी को और भी बदतर क्यों बनाते हैं?

@anawishnoff ने लिखा:

हम इसे मूल WinUI नियंत्रण में बदलने में रुचि रखते हैं

"इसे एक मूल WinUI नियंत्रण में स्नातक करना" व्यावहारिक रूप से कुछ ऐसी ही गलतियों की निरंतरता/पुनरावृत्ति का गठन करता है जिसके कारण विकिपीडिया में उल्लिखित "बाजार हिस्सेदारी में कमी और ऐप विकास की कमी" हुई:

"मई 2016 में, माइक्रोसॉफ्ट ने अपने मोबाइल व्यवसाय को नष्ट कर दिया, .... 2017 में, माइक्रोसॉफ्ट के कार्यकारी जो बेल्फ़ोर ने खुलासा किया कि माइक्रोसॉफ्ट ने विंडोज 10 मोबाइल के लिए नए विंडोज फोन और नई सुविधाओं के विकास को बंद कर दिया था, बाजार हिस्सेदारी में कमी और कमी का हवाला देते हुए ऐप डेवलपमेंट।"
-- https://en.wikipedia.org/wiki/Microsoft_Mobile

डेटाग्रिड को उसी रास्ते पर क्यों चलना चाहिए जिसने माइक्रोसॉफ्ट के मोबाइल व्यवसाय को नष्ट कर दिया?

@verelpode

विनयूआई 3 प्रबंधन की वही गलतियां जारी रखता है जिसके कारण यूडब्ल्यूपी और विंडोज फोन विफल हो गया और माइक्रोसॉफ्ट को अरबों डॉलर का नुकसान हुआ।

मैं माइक्रोसॉफ्ट के लिए काम नहीं करता लेकिन मैं उत्सुक हूं कि आप क्यों कहते हैं कि विनयूआई प्रबंधन की गलतियां कर रहा है।
जो मैं देखता हूं उससे यह तथ्य कि WinUI को खुला स्रोत बनाया जा रहा है और सभी को बातचीत और निर्णयों में योगदान करने के लिए मिलता है, वास्तव में यह परिभाषित करने में मदद कर रहा है कि WinUI क्या है और गलतियों को होने से रोकना चाहिए।
आप उल्लेख करते हैं कि डेटाग्रिड मोबाइल के समान पथ पर चल रहा है फिर भी पिच में कहीं भी मैंने इसे मोबाइल का उल्लेख नहीं देखा। शायद आप इस मुद्दे पर चर्चा करने के लिए सीधे फीडबैक रख सकते हैं।
यदि आपको लगता है कि विनयूआई के साथ कुप्रबंधन कदम हैं तो शायद आप अपनी चिंताओं के साथ एक अलग मुद्दा बना सकते हैं लेकिन मुझे नहीं लगता कि आपकी टिप्पणियों का डेटाग्रिड नियंत्रण से कोई लेना-देना है।

@verelpode कृपया अपनी प्रतिक्रिया यहाँ विषय पर रखें। यदि आप बड़े पैमाने पर WinUI या UWP के बारे में चिंतित हैं, तो कृपया एक नया चर्चा विषय शुरू करें या सीधे मुझसे संपर्क करें (ट्विटर पर मुझे या डीएम को ईमेल करें)। या आप किसी मौजूदा विषय जैसे #717 या #1531 पर चर्चा करने पर विचार कर सकते हैं।

आपने डेटाग्रिड को सी++ में फिर से लिखे जाने के बारे में चिंताएं साझा कीं, लेकिन असल में मूल प्रस्ताव में इसके बारे में कुछ भी उल्लेख नहीं किया गया था। @anawishnoff डेटाग्रिड सुविधा सेट के बारे में प्रतिक्रिया एकत्र करने का प्रयास कर रहा है। कार्यान्वयन-वार, यदि इसे सी # में रखने के लिए सबसे अधिक समझ में आता है, तो हम ऐसा करेंगे (और यह अभी भी सी ++ से कॉल करने योग्य हो सकता है यदि हमने इसे WinRT घटक के रूप में किया है)।

@jevansaks - मेरी प्रतिक्रिया विषय पर थी, लेकिन बुरी खबर देने वाले दूत को गोली मारना मानव स्वभाव है। आपकी प्रतिक्रिया मुझे दुखी और निराश करती है। ठीक है, मैं मदद करने की कोशिश करना बंद कर दूंगा, क्योंकि मेरी सहायता अवांछित है क्योंकि यह बहुत ईमानदार और प्रत्यक्ष है और दर्दनाक मुद्दों को छूती है जो स्वीकार करने और हल करने के लिए बहुत दर्दनाक हैं (WinRT की भयावह विफलता बहुत अधिक भावनाओं को जन्म देती है और इसलिए इसे मिटाना आसान है इसे स्मृति से और उसी पुरानी मूल WinRT योजना को जारी रखें जैसे कि आपदा कभी हुई ही नहीं)। मैं इस चर्चा से बाहर निकलूंगा और डेटाग्रिड के विकास में आगे भाग नहीं लूंगा क्योंकि वास्तविक समस्याओं के बारे में ईमानदारी से और सीधे बोलना जारी रखने से लोग केवल परेशान होंगे।

@verelpode यहां किसी ने "बुरी खबर देने वाले दूत को गोली नहीं मारी"। @jevansaks ने आपको इस रिपॉजिटरी में UWP/WinUI/WinRT के बारे में अपनी व्यापक चिंताओं को साझा करने के लिए एक नया अंक खोलने के लिए आमंत्रित किया। यह मुद्दा वास्तव में केवल डेटाग्रिड के बारे में है और वास्तव में आपकी चिंताओं में से एक डेटाग्रिड के बारे में था, जबकि विशाल बहुमत सामान्य रूप से यूडब्ल्यूपी/विनयूआई/विनआरटी के बारे में था। मुझे यकीन है कि यदि आप इस चर्चा को फिर से देखेंगे, तो आप देखेंगे कि WinUI टीम आपको केवल इस मुद्दे को केवल डेटाग्रिड प्रस्ताव पर केंद्रित रखने के लिए कह रही है और आपकी व्यापक चिंताओं के लिए एक नया खोलने/मौजूदा मुद्दे का उपयोग करने के लिए कह रही है। मंच।

जिन चिंताओं का आपने उल्लेख किया है, वे WinUI टीम और समुदाय दोनों को शामिल करते हुए एक दिलचस्प चर्चा का आधार हो सकती हैं, लेकिन यह विशेष मुद्दा ऐसी चर्चा के लिए उपयुक्त नहीं है।

@anawishnoff
मुझे पूरा यकीन है कि माइक्रोसॉफ्ट पिवट व्यूअर कंट्रोल एचटीएमएल नहीं था। कृपया इसे वापस देखें। कुछ इस तरह का उपयोग करके डेटा के बड़े सेट की कल्पना करने की क्षमता कुछ ऐसी थी जिसे हम कभी-कभी करना चाहते थे। मुझे लगता है कि यह सिल्वरलाइट में उपलब्ध था। https://www.microsoft.com/silverlight/pivotviewer/default# इसने अपनी कार्यक्षमता के लिए डीप जूम का इस्तेमाल किया। WinUI 3.0 में डीप जूम क्षमता जोड़ना शानदार होगा! वास्तव में डेटाग्रिड नहीं, बल्कि डेटा प्रदर्शन नियंत्रण। डब्ल्यूपीएफ के शुरुआती दिनों से डीप जूम जैसे बहुत सारे "छोड़े गए" विचार हैं जिन्होंने इसे कभी भी उत्पादन डब्ल्यूपीएफ नियंत्रण में नहीं बनाया जो समय के साथ विनयूआई 3.0 में जीवन में वापस लाने के लिए अद्भुत होगा। हेक जाओ डॉ. डब्ल्यूपीएफ को तहखाने से बाहर निकालो और उसे फिर से पोस्टिंग करवाओ !!! हमें उसे वापस चाहिए। हमें एक आंदोलन शुरू करने की जरूरत है। डॉ डब्ल्यूपीएफ वापस लाओ !!!!! कहा चली गयी थी? डॉ विनयूआई !!!

@PaulMontgomerySP ऐसा लगता है कि आपको पिवट नियंत्रण पर चर्चा करने के लिए एक नया मुद्दा खोलना चाहिए। पिछली चर्चा का संदर्भ देने के लिए स्वतंत्र महसूस करें जो इसके बारे में विंडोज कम्युनिटी टूलकिट से यहां थी: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/770

मेरे द्वारा कीबोर्ड से जाने वाली प्रत्येक पंक्ति के लिए चयन परिवर्तित ईवेंट फ़ायर करता है।
केवल चयन परिवर्तित ईवेंट के बजाय, केवल माउस क्लिक या सेल टैप के लिए एक ईवेंट होना अच्छा होगा।

चयन परिवर्तित घटना क्लिक और कीबोर्ड दोनों के लिए सक्रिय हो जाती है। किसी ईवेंट को केवल क्लिक करने के लिए होने से बहुत लाभ होगा।

@ गोइंग-गॉन मैं उत्सुक हूं कि इसके लिए उपयोग का मामला क्या है? आपको अंतर जानने की आवश्यकता क्यों है? क्या आप टैप किए गए ईवेंट का भी उपयोग नहीं कर सकते?

यूडब्ल्यूपी टूलकिट के डेटाग्रिड के साथ एक सीमा जो मैंने अभी-अभी मारा है वह है DataGridTemplateColumn में एक सेल टेम्पलेट है, लेकिन इसमें CellTemplateSelector (और यह CellEditingTemplate लिए गायब है)। यह चयनकर्ता दृष्टिकोण का उपयोग करके प्रत्येक सेल में यूआई को डेटा के अनुकूल बनाना आसान बना देगा, बजाय इसके कि इसे संभालने के लिए इसके नीचे एक अतिरिक्त स्तर के यूआई नियंत्रण के साथ ऐसा करना पड़े।

कृपया न केवल लगातार क्रम में पंक्तियों का चयन करना संभव बनाएं, जैसा कि मैंने यहां विस्तार से बताया है:
https://github.com/duke7553/files-uwp/issues/276#issue -520060100

ग्राहकों द्वारा अक्सर अनुरोध की जाने वाली चीजों के किसी विशेष क्रम में ग्रिड को समर्थन नहीं करना चाहिए

1. फिल्टर को बचाने, लोड करने और बनाने की क्षमता। उदाहरण के लिए linq एक्सप्रेशन को फ़िल्टर करें, SQL क्वेरी को फ़िल्टर करें, एक्सप्रेशन ट्री को फ़िल्टर करें और रिवर्स। उदाहरण - https://querybuilder.js.org/demo.html

1. उच्च गति वास्तविक समय डेटा क्षमताएं, प्रदर्शन मायने रखता है। ट्रेडिंग एप्लिकेशन बनाम > 1 मिलियन पंक्तियों के लिए सब 1ms रीफ्रेश दरों में अलग-अलग प्रदर्शन विचार हैं।
2. सॉर्ट ऑर्डर निर्दिष्ट करने की क्षमता, उदाहरण के लिए i. उच्च/निम्न क्रमबद्ध करें, ii. निम्न/उच्च क्रमबद्ध करें और iii. कोई प्रकार या मैं नहीं। निम्न/उच्च क्रमबद्ध करें, ii. उच्च/निम्न क्रमबद्ध करें और iii. कोई छँटाई नहीं
3. एक्सेल की तरह फ़िल्टरिंग
4. कोशिकाओं में सीएसएस स्वरूपण लागू करने की क्षमता, सशर्त स्वरूपण
5. ग्रिड सेटिंग्स को आसानी से सहेजने/लोड करने की क्षमता, जैसे फ़िल्टर, कॉलम चौड़ाई, सॉर्टिंग इत्यादि
6. स्क्रॉल करना जो काम करता है, उदाहरण के लिए डेटा अपडेट के बाद रीसेट नहीं होता, सुचारू।
7. डेटा संग्रह इवेंट में अलग-अलग ऑब्जेक्ट के बजाय लोड करने की रेंज के बाद इवेंट को सक्रिय करने के विकल्प होने चाहिए। उदाहरण के लिए, मेरा मानना ​​​​है कि ऑब्जर्जेबल कोलेक्शन को प्रत्येक व्यक्तिगत वस्तु के लिए INotifyPropertyChange फायरिंग को रोकने के लिए उपवर्ग की आवश्यकता होती है।
8. जब डेटा लोड/लोड हो रहा हो, डेटा लोड शुरू हो गया हो, डेटा लोड हो रहा हो, डेटा लोड हो रहा हो, विशेष रूप से एसिंक लोडिंग का उपयोग करते समय बेहतर घटनाएं।
9. ग्रिड अक्सर अन्य नियंत्रणों से जुड़े होते हैं जैसे डेटा फ़िल्टर, श्रेणी चयन, क्रॉसफ़िल्टर (जैसे https://github.com/dc-js/dc.js), चार्ट, पिवट टेबल आदि
10. स्मार्ट छँटाई जो अल्फ़ान्यूमेरिक डेटा को संभालती है, उदाहरण के लिए ABC11, ABC111, ABC12 के बजाय क्रमबद्ध क्रम ABC11, ABC12, ABC111
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

मैं सीधे हैडर से कॉलमविड्थ से आबद्ध नहीं हो पाऊंगा। डब्ल्यूपीएफ में मुझे उस मामले में बाध्यकारी प्रॉक्सी ऑब्जेक्ट का उपयोग करना होगा।

आसान संपादन के लिए सक्रिय पंक्ति का सुविधाजनक गतिशील आकार बदलना।
संपादन मोड में संदर्भ मेनू का पूर्ण नियंत्रण।

आशा है कि यह Telerik की तरह CellDecorationStyleSelector को सपोर्ट करेगा।

अभिगम्यता!
इसका उल्लेख करते हुए इसे प्रलेखित किया गया है, लेकिन इस नियंत्रण को पूरी तरह से सुलभ होने की आवश्यकता है।
इस क्षेत्र में वर्तमान टूलकिट संस्करण की कुछ सीमाएँ हैं: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3400 & https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/3079
इसके अलावा, जबकि Telerik RadDataGrid में कुछ बेहतरीन विशेषताएं हैं, ऐसा लगता है कि यह पहुंच का समर्थन नहीं करता है ।

डी एंड आई के लिए माइक्रोसॉफ्ट के बड़े धक्का के साथ, मुझे आश्चर्य है कि सभी नियंत्रणों के लिए पूरी तरह से सुलभ होने की आवश्यकता हर जगह एक आवश्यकता के रूप में निर्दिष्ट नहीं है।

शायद यह पहले से ही संभव है, और मुझे नहीं पता कि इसे अभी तक कैसे पूरा किया जाए ... लेकिन कैसे: कस्टम पंक्ति या सेल स्टाइल?

एक विशिष्ट पंक्ति को लक्षित करने की क्षमता, पृष्ठभूमि और पाठ का रंग बदलना बहुत अच्छा होगा।

WCT UWP डेटाग्रिड की तुलना में:
1) प्रदर्शन
2) कॉलम प्रकारों में अधिक निर्मित (मुझे लगता है कि इनका टेम्पलेट कॉलम से बेहतर प्रदर्शन है)
3) प्रति सेल माउस ईवेंट को हुक करने की क्षमता, यानी टैप, राइट टैप, और होवर, (या पॉइंटर डाउन या जो भी हो)
4) प्रति सेल कीबोर्ड इवेंट
5) यदि (3) काम करने योग्य नहीं है, तो हम अनुकरण कर सकते हैं यदि हमारे पास हिट परीक्षण कार्यक्षमता होती
6) प्रदर्शन

कितने लोग आपत्ति करेंगे यदि WinUI डेटाग्रिड ने उस सुविधा को छोड़ दिया जहां एंड-यूज़र डेटाग्रिड के अंदर/सीधे सेल मानों को संपादित करने में सक्षम हैं?

क्या किसी को वीबी 6 याद है? VB6 डेटाग्रिड ने बॉक्स से बाहर संपादित करें, हटाएं और नया जोड़ें का समर्थन किया। जोड़ें एक खाली पंक्ति के रूप में उपलब्ध था जो स्वचालित रूप से सूची के अंत में जुड़ जाती है। पंक्ति को पूरा करें और दूसरी रिक्त पंक्ति प्रकट होती है।

एक डेटाग्रिड के पास डेटा प्रविष्टि का समर्थन करने का विकल्प होना चाहिए, भले ही अधिकांश देव इस सुविधा को डिफ़ॉल्ट रूप से बंद करना पसंद करते हों।

VB6 ऐप को UWP में पोर्ट करने में हमें ऐड/एडिट/डिलीट को सपोर्ट करने के लिए अपना डेटा ग्रिड लिखना पड़ा।

ऐसा लगता है कि यहां योगदान करने वाले अधिकांश लोग wpf/Xaml लोग हैं, यह किसी ऐसे व्यक्ति से दो सेंट लायक है जो xaml लड़का नहीं है।

मैं अपने सॉफ़्टवेयर में डेटाग्रिड नियंत्रणों का बहुत उपयोग करता हूं। संपादन स्थान महत्वपूर्ण है! मेरी कुछ इच्छाएं/दर्द बिंदु हैं:

1. संपादन मोड में होने पर संदर्भ मेनू को अनुकूलित करने की क्षमता।
2. कॉलम को ऑटोसाइज़ करते समय बेहतर प्रदर्शन और अधिक नियंत्रण। मैं चाहता हूं कि यदि आवश्यक हो तो उपयोगकर्ता आकार को नियंत्रित करने में सक्षम हो, लेकिन अधिकतर इसकी आवश्यकता नहीं है। मैं नहीं चाहता कि कॉलम आकार लगातार बदलते रहें, लेकिन मैं चाहता हूं कि वे किसी भी तरह डेटा पर आधारित हों, बिना दस लाख पंक्तियों के डेटा को मापने के बिना।
3. संपादन करते समय, मैं एक अलग नियंत्रण/बटन पर क्लिक करने में सक्षम होना चाहता हूं जो संपादन को समाप्त किए बिना संपादित किए जा रहे डेटा के लिए कुछ (या साथ) करता है। (यह कम आवश्यक होगा यदि # 1 लागू किया गया - हालांकि अभी भी उपयोगी है।)
4. DataError ईवेंट का उपयोग करके वर्तमान तरीके से अपवादों को संभाला जाता है। (क्षमा करें, मुझे इस पर विशिष्ट होने में परेशानी हो रही है, लेकिन मुझे पता है कि इससे मुझे अतीत में कई बार दर्द हुआ है।)
5. अंतर्निहित ऑटो-स्क्रॉलिंग क्षमता अच्छी होगी: http://stackoverflow.com/questions/2567809/how-to-autoscroll-a-datagridview-during-drag-and-drop
6. "वॉटरमार्क" प्रदर्शित करने की क्षमता यह दर्शाती है कि डेटा कब "गंदा" है ( डेटाग्रिड व्यू में कुछ अतिरिक्त उपयोगी संवर्द्धन के लिए
7. आवश्यक "कुंजी" सेल खाली छोड़े जाने पर एक पंक्ति (सत्यापन त्रुटि के बिना) को छोड़ने की क्षमता।
8. उपयोगकर्ता द्वारा जोड़ी गई पंक्ति के लिए कोई छवि (लाल X के बजाय) प्रदर्शित करने की अंतर्निहित क्षमता। देखें: https://stackoverflow.com/questions/937919/datagridviewimagecolumn-red-x
9. चेक-बॉक्स कॉलम बदलने पर तुरंत प्रतिबद्ध होने दें: https://stackoverflow.com/questions/11843488/how-to-detect-datagridview-checkbox-event-change

अल्फा कब जारी होने की उम्मीद है? क्या यह योगदान के लिए खुला होगा? एक पुराने डेटा ग्रिड को खोदने की कोशिश करना और वास्तव में इसके लिए तत्पर रहना, विशेष रूप से वर्चुअलाइजेशन सुविधा।

इस धागे में बहुत देर से इनपुट डालने के लिए खेद है, लेकिन मेरे लिए यह "नया" है;)
_नियंत्रण के व्यवहार के बारे में कुछ और जानने के बाद संपादित किया गया_

क्लाउड ड्राइव के लिए एक एक्सप्लोरर जैसा इंटरफ़ेस बनाने की दिशा में डेटाग्रिड के साथ काम करने में, मैंने पाया कि टैप की गई पंक्ति और सेल को निर्धारित करना "चाहिए" (आईएमएचओ) की तुलना में थोड़ा अधिक जटिल हो सकता है।

मेरे ऐप के डिज़ाइन में, पंक्तियाँ फ़ाइलों या फ़ोल्डरों (DriveItems) का प्रतिनिधित्व करती हैं। विवरण दृश्य आइटम के बारे में अधिक विवरण दिखाता है।

मैं एक फ़ोल्डर आइटम पर क्लिक करने की क्षमता बनाना चाहता था, और इंटरफ़ेस को कूदना था और उन वस्तुओं की एक सूची बनाना था, जो पूरे ड्राइव में नेविगेशन की अनुमति देता था।

उदाहरण के लिए, यदि मैंने आइटम की "पैरेंट" कॉलम प्रविष्टि पर टैप किया है, तो /drive/root:/Documents/Vital%20Documents यहां, इंटरफ़ेस उस फ़ोल्डर में रीसेट हो जाएगा और वहां फाइलों को सूचीबद्ध करेगा।

हालांकि किसी को सेल के लिए एक क्लिक की गई घटना मिल सकती है, उस घटना में हैंडलर के लिए उस सेल को निर्धारित करने के लिए संदर्भ नहीं है जिसे टैप किया गया था (पंक्ति, हाँ, लेकिन कॉलम नहीं), और मुझे यकीन नहीं है कि वर्तमान में नियंत्रण मुझे सेल टैप किए गए व्यवहार और स्वचालित रूप से खुले विवरण व्यवहार दोनों की अनुमति देगा (अभी भी जांच कर रहा है कि मैं "हैक्स" कह सकता हूं जो इसकी अनुमति देगा, लेकिन हमें खुद को याद दिलाना होगा कि जब डिजाइनर नियंत्रण के सामान्य कामकाज को ओवरराइड करना शुरू करते हैं, खासकर व्यवहार नहीं जो प्रलेखित हैं, वे नियंत्रण के व्यवहार में परिवर्तन से डिजाइन के टूटने का जोखिम उठाते हैं।

यह सब कहा गया है, डेटाग्रिड मेरे परिदृश्य का समर्थन करता है जो वर्तमान में DriveItem को CurrentItem के रूप में लौटाता है, इसमें CurrentColumn भी शामिल होना चाहिए जो कि संपूर्ण DataGridColumn ऑब्जेक्ट होगा जिसे क्लिक किया गया था, के माध्यम से जिससे कॉलम का नाम निकालना संभव होगा। मुझे अब एहसास हुआ है कि हमारे पास CurrentColumn ऑब्जेक्ट है जिसे हम ईवेंट से जांच सकते हैं, इसलिए, हालांकि मैं इसे बेहतर तरीके से चाहता हूं क्योंकि ईवेंट तर्क देता है, यह काम करना चाहिए।

इसके अलावा, विवरण व्यवहार का अधिक कठोर नियंत्रण यह हो सकता है कि विवरण केवल एक विशेष कॉलम पर क्लिक करने के आधार पर स्वतः-विस्तारित हो जाएगा, बजाय इसके कि जब भी कोई पंक्ति में कहीं भी क्लिक करे, तो विस्तार किया जाए।

हो सकता है कि DataGridColumn ऑब्जेक्ट के बेस क्लास में ExpandDetails प्रॉपर्टी हो, जिसे प्रत्येक कॉलम के लिए डिफ़ॉल्ट रूप से सत्य पर सेट किया जा सकता है, जिसका अर्थ यह होगा कि विशेष कॉलम पर क्लिक करने से पंक्ति का विस्तार होता है। अन्य जहां संपत्ति झूठी है वह नहीं होगा।

मेरे डिजाइन में, उदाहरण के लिए, पहला कॉलम आइटम प्रकार है, जैसा कि फ़ाइल या फ़ोल्डर, या छवि या फोटो, ऑडियो, आदि में है। मैं उस कॉलम को सेट करने की कल्पना कर सकता हूं जो ऑटो-विस्तार व्यवहार का कारण बन सकता है, और फिर पथ कॉलम पर एक क्लिक ऊपर वर्णित "उस पथ की एक सूची प्राप्त करें" व्यवहार का कारण बन सकता है।

छँटाई के लिए, डिजाइनरों को बहु-स्तरीय छँटाई प्राप्त करने की अनुमति देने के लिए पर्याप्त नियंत्रण लागू करना तार्किक रूप से महत्वपूर्ण प्रतीत होगा। मैंने यह निर्धारित करने के लिए जांच नहीं की है कि हुकिंग/ओवरराइडिंग ईवेंट और कॉलबैक के माध्यम से वर्तमान नियंत्रण इसका समर्थन कैसे कर सकता है, लेकिन यह सीधा नहीं दिखता है।

अंत में, मुझे पता है कि आप इसके बारे में अच्छी तरह से जानते हैं, लेकिन (यहां तक ​​​​कि मैं और अधिक कार्यक्षमता के लिए पूछ रहा हूं), आइए कृपया जटिल व्यवहारों का एक समूह जोड़ने की कोशिश करने से बचें जो उपयोगकर्ता डेटाग्रिड के शीर्ष पर स्वयं को कार्यान्वित कर सकते हैं। इनमें से जिन्हें मैं डेटाग्रिड में लागू नहीं करूंगा, वे हैं जिनका बाहरी रूप से भंडारण फिल्टर या प्रकार आदि से कोई लेना-देना है। मैं इस नियंत्रण को एक्सेल क्लोन में बनाने से भी बचूंगा।

-धन्यवाद, बढ़िया काम!
-इ

स्टिकी समूह: बड़े समूहों के साथ डेटासेट ब्राउज़ करते समय इस बारे में संदर्भ होना चाहिए कि कौन सा समूह (या समूह, यानी ब्रेडक्रंब) देखा जा रहा है। यह सभी पदानुक्रमित सूची-आधारित दृश्यों के लिए एक आवश्यक उपयोगिता सुविधा की तरह लगता है: समूहीकृत सूची दृश्य, डेटाग्रिड और ट्री दृश्य।

मैं नए WinUI ItemsRepeater नियंत्रण के शीर्ष पर नया डेटाग्रिड नियंत्रण तैयार करूंगा। और वह नियंत्रण अपने आइटम्ससोर्स को ऑब्जेक्ट के रूप में उजागर करता है:
Object ItemsSource { get; set; };

@RBrid इस पर वापस आ रहा है ~ 1 साल बाद। मुझे एहसास हुआ कि ItemsRepeater, हालांकि इसमें एक वस्तु ItemsSource है, वास्तव में वर्चुअलाइज्ड डेटा स्रोतों के साथ काम करने के लिए आवश्यक निम्नलिखित इंटरफेस के लिए अंतर्निहित समर्थन नहीं है:

• आईसपोर्टइन्क्रीमेंटललोडिंग
• IItemsRangeInfo
• IS SelectionInfo

- वहां अब एमवीपी प्राप्त करने के बारे में क्या है ताकि हम सी ++ से डाटाग्रिड का उपयोग कर सकें।