WPF परियोजनाओं के लिए मुश्किल ग्रिड चयन

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

प्रतियोगी

मुझे लगता है कि तुलना में प्रतिभागियों की सूची किसी को आश्चर्यचकित नहीं करेगी:

• DevExpress
• इन्फ़्रागेटिक्स नेटएडवेंचर
• Xceed
• ComponentOne
• Telerik

कौन परवाह करता है कि यह कैसे हुआ, कृपया, बिल्ली के नीचे।

यह कहने योग्य है कि हमारी टीम के पास पहले से ही Telerik और DevExpress से WPF घटकों के सेट के साथ काम करने का अनुभव है। ComponentOne से 10 साल के एक्सपोज़र WinForms ग्रिड के साथ अनुभव भी है। मैं खुद 2009 से व्यावसायिक परियोजनाओं के लिए WPF का उपयोग कर रहा हूं और निश्चित रूप से, अपनी ग्रिड बाइक और MVVM रूपरेखा लिखने में कामयाब रहा।

तुलना कैसे करें

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

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

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

DevExpress

ग्रिड इंप्रेशन बहुत नकारात्मक हैं। ऐसा लगता है कि यह WinForms से पूरी तरह से नामस्थान में बदलाव के साथ कॉपी किया गया है। घटक WinForms की शैली के समान हैं, जो एक तरफ उन लोगों के लिए अच्छा है जो केवल WinForms के साथ WPF पर स्विच करते हैं, और दूसरी तरफ, वास्तव में एक नई तकनीक के लिए कोई संक्रमण नहीं है। WPF में विकास के 4 साल बाद इस ग्रिड पर स्विच करना मुश्किल है। हमें प्रत्येक संपत्ति और विधि का विवरण देखना होगा (हालांकि उनके पास अच्छे दस्तावेज हैं)। उदाहरण के लिए, ग्रिड में चयनित पंक्ति चयनित इटेम नहीं है, जैसा कि कई डब्ल्यूपीएफ डेवलपर्स सोचेंगे, लेकिन, ध्यान केंद्रित करें । जाहिर है, मैं बहस नहीं करता, लेकिन यह बहुत असामान्य है।

स्तंभ बंधन, स्पीकर अनुकूलन

स्पीकर बाइंडिंग अच्छा काम करता है। मूल WPF के रूप में। ग्रिड में संपादन कष्टप्रद नहीं है और सब कुछ बस काम करता है। अनुकूलन भी उच्च स्तर पर किया जाता है: कोशिकाओं के लिए शैली, टेम्पलेट और टेम्पलेट चयनकर्ता होते हैं।

एक के माध्यम से रंग लाइनें

लेकिन फिर यह शुरू हुआ। सबसे सरल संचालन, जो मूल WPF ग्रिड में एक संपत्ति निर्धारित करके किया जाता है, DevExpress ग्रिड में, कोड के किलोमीटर-लंबी कैनवस में प्रवेश करती है। उदाहरण के लिए, ग्रिड लाइनों को एक के माध्यम से रंगने से आसान क्या हो सकता है: विषम - सफेद, यहां तक ​​कि ग्रे। जो लोग WPF से परिचित नहीं हैं, उनके लिए मैं कहता हूँ कि मूल ग्रिड आउट ऑफ़ द बॉक्स में .NET फ्रेमवर्क ऐसा करता है:

<DataGrid AlternatingRowBackground="LightGray"/> 

लेकिन DevExpress डेवलपर्स का जीवन पर एक अलग दृष्टिकोण है और उनके पास ऐसी कोई संपत्ति नहीं है। डेवलपर्स से एक आधिकारिक उदाहरण कहता है कि आपको ऐसा करने की आवश्यकता है :

 <!--    --> <SolidColorBrush x:Key="EvenRowBrush" Color="LightGray" /> <!--    --> <SolidColorBrush x:Key="OddRowBrush" Color=" Transparent" /> <!--      --> <Style BasedOn="{StaticResource {dxgt:GridRowThemeKey ThemeName=Seven, ResourceKey=RowStyle}}" TargetType="{x:Type dxg:GridRowContent}"> <Style.Triggers> <MultiDataTrigger> <MultiDataTrigger.Conditions> <Condition Binding="{Binding Path=EvenRow}" Value="False"/> <Condition Binding="{Binding Path=SelectionState}" Value="None"/> </MultiDataTrigger.Conditions> <Setter Property="Background" Value="{StaticResource EvenRowBrush}" /> </MultiDataTrigger> <MultiDataTrigger> <MultiDataTrigger.Conditions> <Condition Binding="{Binding Path=EvenRow}" Value="True"/> <Condition Binding="{Binding Path=SelectionState}" Value="None"/> </MultiDataTrigger.Conditions> <Setter Property="Background" Value="{StaticResource OddRowBrush}" /> </MultiDataTrigger> </Style.Triggers> </Style> 

अजीब, स्पष्ट नहीं है, और कष्टप्रद है कि आपको ऐसी सरल चीजों को Google करना होगा और ऐसे गैर-तुच्छ समाधान प्राप्त करने होंगे।

मास्टर भाग

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

ऐसी कार्यक्षमता के कार्यान्वयन के कई उदाहरण पाए गए, जिनमें से प्रत्येक के अपने नुकसान और फायदे थे। उदाहरण के लिए, यह उदाहरण भागों की ऊंचाई को 300 पिक्सेल तक सीमित करता है। और अगर मेरे पास अधिक लाइनें हैं? फिर एक दूसरा स्क्रॉल दिखाई देगा, मुख्य एक के बगल में? बदसूरत और असहज।

DataControlDetailDescriptor का उपयोग करके मास्टर भाग के लिए एक और कार्यान्वयन विकल्प है। कोड इस तरह दिखता है:

 <dxg:GridControl.DetailDescriptor> <dxg:DataControlDetailDescriptor ItemsSourcePath="Children"> <dxg:DataControlDetailDescriptor.DataControl> <dxg:GridControl> <dxg:GridControl.View > <dxg:TableView> </dxg:TableView> </dxg:GridControl.View> <dxg:GridControl.Columns> </dxg:GridControl.Columns> </dxg:GridControl> </dxg:DataControlDetailDescriptor.DataControl> </dxg:DataControlDetailDescriptor> </dxg:GridControl.DetailDescriptor> 

टैग के ऐसे जंगली घोंसले कहां से आते हैं? मैं समझता हूं कि xml एक मनहूस है, कभी भी कॉम्पैक्ट नहीं, प्रारूप, लेकिन उसी हद तक नहीं! आगे देखते हुए, मैं कहता हूँ कि इस संबंध में प्रतियोगी अधिक संक्षिप्त हैं।

इसके अलावा, दूसरा विकल्प इस तथ्य की ओर जाता है कि विवरण के साथ नेस्टेड ग्रिड व्यावहारिक रूप से मास्टर पंक्ति से अलग नहीं होता है, या बल्कि, ग्रिड भाग की अंतिम पंक्ति मास्टर ग्रिड की अगली पंक्ति से अलग नहीं होती है। यह उपयोगकर्ता को भ्रमित कर सकता है। इसी समय, ग्रिड विस्तार के लिए स्पष्ट रूप से सीमाएं निर्धारित करने से कोई परिणाम नहीं मिला।

इसके अलावा, इस दृष्टिकोण के साथ, ग्रिड भाग के लिए बाइंडिंग फोकस्डरो संपत्ति काम नहीं करती है! यह निर्धारित करना भी असंभव है कि टूलबार पर कमांड की उपलब्धता को बदलने के लिए कौन सी ग्रिड फोकस में है। मुझे बहुत सारी संबंधित घटनाओं के साथ खेलना था, दो ग्रिडों के फोकस को बदलना और इस क्रम से कटौती करना कि कौन सा ग्रिड वास्तव में फोकस में है और कौन सी टीमें उपलब्ध होनी चाहिए।

प्रसंग मेनू कमांड बाइंडिंग

संदर्भ मेनू में बाइंडिंग कमांड केवल घृणित है। ग्रिड में संदर्भ मेनू के गठन के दौरान DataContext संपत्ति की विरासत टूट गई है। कुछ उपयोगिता वर्ग का एक उदाहरण संदर्भ मेनू आइटम के DataContext में निहित है और ViewModel से एक कमांड को बांधने के लिए आपको यह पंक्ति लिखने की आवश्यकता है:

 Command="{Binding Path=View.DataContext.CancelCommand}" 

इसके अलावा, गुणों के ऐसे सही अनुक्रम की खोज में बहुत सारे अलग-अलग विकल्प थे। खोज के एक घंटे के बाद उपरोक्त संस्करण नहीं मिला।

फैसला

उपरोक्त नुकसानों के लिए, आप दृश्य स्टूडियो संपादक के हैंग और क्रैश जोड़ सकते हैं जब DevExpress घटक इसमें खुले हैं।

यह वह जगह है जहाँ DevExpress के साथ हमारे प्रयोग समाप्त हो गए। लेकिन मुझे कहना होगा कि DevExpress ग्रिड के साथ उपरोक्त सभी समस्याएं लगभग पूरी तरह से व्यक्तिपरक मूल्यांकन हैं, और एक व्यक्ति के लिए जो DevExpress के WinForms घटकों का उपयोग करके विकसित हुआ है, सब कुछ अधिक रसीला और परिचित होगा।

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

इन्फ़्रागेटिक्स नेटएडवेंचर

अगला परीक्षण विषय इन्फ़्रागॉस्टिक ग्रिड था। अपने आश्चर्य के लिए, मैंने एक ही बार में दो ग्रिड की खोज की: XamGrid और XamDataGrid । प्रत्येक ग्रिड की कार्यात्मक संतृप्ति अजीब है और यहां वर्णित है ।

और यदि लागू किए गए कार्य में दोनों ग्रिड की कार्यक्षमता की आवश्यकता है? अजीब है, लेकिन ठीक है, हम कोशिश करेंगे। उदाहरण के लिए, XamDataGrid को लें , जो कार्यक्षमता और अनुकूलन क्षमताओं में समृद्ध है।

स्तंभों में बांधना

पहली बात जो भ्रमित थी कि ग्रिड में कॉलम की संपत्ति नहीं थी। कुछ FieldLayouts प्रॉपर्टी है जो इस तरह घोषित की जाती है :

 <igDP:XamDataGrid AutoFit="True" DataSource="{Binding Constituents}"> <igDP:XamDataGrid.FieldLayouts> <igDP:FieldLayout> <igDP:FieldLayout.Fields> <igDP:Field Label="Name" Name="Name" /> <igDP:Field Label="Photo" Name="ImageUri">…</igDP:Field> <igDP:Field Label="Age" Name="Age" /> </igDP:FieldLayout.Fields> </igDP:FieldLayout> </igDP:XamDataGrid.FieldLayouts> </igDP:XamDataGrid> 

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

 <igDP:UnboundField Name="StreetDesc" Label="Security Description"> <igDP:Field.Settings> <igDP:FieldSettings> <igDP:FieldSettings.CellValuePresenterStyle> <Style TargetType="igDP:CellValuePresenter"> <Setter Property="Template"> <Setter.Value> <ControlTemplate> <TextBlock DataContext="{Binding DataItem.Security}" Text="{Binding StreetDesc}"/> </ControlTemplate> </Setter.Value> </Setter> </Style> </igDP:FieldSettings.CellValuePresenterStyle> </igDP:FieldSettings> </igDP:Field.Settings> </igDP:UnboundField> 

फैसला

नहीं, यह WPF नहीं है! हमने इस राक्षस पर शोध करने और इसे स्थगित करने के लिए अधिक समय नहीं बिताने का फैसला किया।

Xceed

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

WCF DataServices के लिए रिकॉर्ड और समर्थन का आलसी पोस्ट लोडिंग

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

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

स्तंभों में बांधना

यहां निराशा हाथ लगी। यह पता चला है कि आप ग्रिड कॉलम के लिए बाध्यकारी अभिव्यक्ति निर्दिष्ट नहीं कर सकते। आप फ़ील्डनाम गुण का मान निर्दिष्ट कर सकते हैं। इसके अतिरिक्त, DisplayMemberBindingInfo गुण है, जिसमें आप सामान्य बाइंडिंग गुण सेट कर सकते हैं (लेकिन सभी नहीं), लेकिन यह मार्कअप एक्सटेंशन से reducible नहीं है (आप सिर्फ DisplayMemberBindingInfo = "{Binding ...}" नहीं लिख सकते हैं)। इस मामले में, डेटा ऑब्जेक्ट का एक उदाहरण नहीं है, लेकिन डेटा ऑब्जेक्ट की संबद्ध संपत्ति का एक उदाहरण सेल के डेटाकोटेक्स्ट में मिलेगा। यह तर्कसंगत लगता है, लेकिन फिर एक सेल शैली / टेम्पलेट में पड़ोसी कॉलम या डेटा ऑब्जेक्ट के अन्य गुणों तक पहुंचने के लिए कैसे? यह पता चलता है कि आप इस तरह के एक नर्तकी के साथ नृत्य कर सकते हैं:

 <xcdg:Column FieldName="Product.Name" Title="" CellContentTemplateSelector="{StaticResource ProductTemplateSelector}"> <xcdg:Column.DisplayMemberBindingInfo> <xcdg:DataGridBindingInfo ReadOnly="True" Path="."/> </xcdg:Column.DisplayMemberBindingInfo> </xcdg:Column> 

यहां यह महत्वपूर्ण है कि मूल्य निर्धारित करते समय पथ = "।" ReadOnly = "True" निर्दिष्ट करना सुनिश्चित करें। यह आपको सेल के DataContext में डेटा ऑब्जेक्ट ( ऑर्डर ) की एक आवृत्ति डालने की अनुमति देगा, न कि इसके गुण ( Product.Name )।

मुझे समझ में नहीं आता कि ऐसा करना क्यों जरूरी था। ओह ठीक है। कोई भी इसके साथ रह सकता था, लेकिन फिर मैं अद्भुत व्यवहार में आ गया। एक जिज्ञासु पाठक शायद पहले से ही निरंकुश है और "कॉलम के उदाहरण में, फील्डनैम =" Product.Name "संपत्ति को निर्दिष्ट करने की शैली में एक टिप्पणी लिखता है, यह बहुत ही अच्छा है, इसका कोई मतलब नहीं है"। मैं सहमत हूँ, चलो हटो। परिणामस्वरूप, हम संकलक से निम्नलिखित त्रुटि को लूट लेंगे:

मान शून्य नहीं हो सकता। पैरामीटर नाम: कुंजी

मूल्य क्या है, प्रमुख पैरामीटर क्या है? यह स्पष्ट नहीं है। उसी समय, फ़ील्डनाम गुण के समान मान वाले दो स्तंभ बनाने का प्रयास यह त्रुटि उत्पन्न करता है:

समान फ़ील्ड नाम वाला एक कॉलम पहले से ही संग्रह में मौजूद है।

हाँ, यह पहले से ही गर्म है। फिर मुझे जिज्ञासा से घेर लिया गया, और मैं एक रिफ्लेक्टर के साथ स्रोत कोड में पहुंच गया। यह पता चलता है कि कॉलम स्वयं संग्रह करता है, हालांकि यह ऑब्जर्वेबल कॉलेक्शन का एक वंशज है, लेकिन अंदर (स्पष्ट रूप से पहुंच का अनुकूलन करने के लिए) में एक निजी क्षेत्र शामिल है:

 Dictionary<string, ColumnBase> m_fieldNameToColumns; 

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

स्थानीयकरण

ईमानदारी से, मुझे उम्मीद नहीं थी कि 2013 में मैं घटक में एक विशिष्ट रेखा को स्थानीय बनाने के लिए निम्नलिखित सिफारिशें पढ़ूंगा:

समूह हेडर के लिए, आप एक अनुकूलित समूह निहित डेटाटैम्पलेट बना सकते हैं जो सूचना को प्रदर्शित करता है कि आप इसे कैसे चाहते हैं:

 <DataTemplate DataType="{x:Type xcdg:Group}"> <TextBlock Text="Voici mon DataTemplate français!" /> </DataTemplate> 

आप WPF इंस्टॉलेशन फ़ोल्डर (रिसोर्सबर्ड के शीर्ष से 3 संसाधन) के लिए डेटाग्रिड के "थीम्स \ आम \ _ कॉमन सोर्स" xaml में एक availlable से शुरू कर सकते हैं।

मुफ्त अनुवाद:

ग्रिड में एक समूहीकरण प्रस्ताव के पाठ के लिए, निम्नलिखित कोड टुकड़े का उपयोग करें:
अचूक कोड टुकड़ा
फिर आप यहां पुनर्परिभाषित के लिए टेम्प्लेट देखना शुरू कर सकते हैं: WPF के लिए डेटाग्रिड (ऊपर से तीसरा संसाधन) के इंस्टॉलेशन पथ पर "थीम \ Common \ Common.Resource.xaml"

क्या मुझे सभी टेक्स्ट मैसेजिंग घटकों के लिए सभी टेम्प्लेट को ओवरराइड करना चाहिए? 21 वीं सदी में वाह स्थानीयकरण।

लेकिन इस फोरम थ्रेड ने Xceed को आगे के विचार से बाहर रखा:

दुर्भाग्य से, वर्तमान में ShowPrintPreviewWindow या ShowPrintPreviewPopup की भाषा को बदलना संभव नहीं है।

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

संक्षिप्त अनुवाद:

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

ब्रावो, Xceed के डेवलपर्स! पूरी गैर-अंग्रेजी दुनिया आपको सराहती है।

फैसला

सुंदर, तेज, बहुत सुविधाजनक, लेकिन पुराने मजाक के रूप में "... एक छोटी सी बारीकियों है।"

ComponentOne

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

एक के बजाय दो ग्रिड। फिर से चुनें?

दो ग्रिड तुरंत आपूर्ति की जाती हैं: C1DataGrid और C1FlexGrid। इस तथ्य को देखने के बाद, मैं तुरंत इन घटकों के बारे में भूलना चाहता था, लेकिन मैंने अपने आप पर काबू पा लिया और इस तथ्य को स्पष्ट रूप से स्पष्ट करते हुए एक लेख पढ़ा और इन्फ्रास्ट्रक्चर के विपरीत स्पष्ट रूप से बताया। यहां कार्यक्षमता को स्पष्ट रूप से दो ग्रिडों में विघटित किया गया है: पहला कस्टमाइज़, फ़िल्टर, समूह, मास्टर भाग, आदि की समृद्ध क्षमता के साथ। और दूसरा हल्का है, बड़े फ्लैट टेबल के साथ जल्दी से काम करना आसान है। तो इस मामले में, इस अलगाव को एक फायदा भी कहा जा सकता है।

स्तंभ बंधन, स्पीकर अनुकूलन

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

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

 <Style x:Key="SateCellStyle" TargetType="TextBlock"> <Setter Property="Background" Value="Transparent"/> <Style.Triggers> <DataTrigger Binding="{Binding RelativeSource={RelativeSource Mode=FindAncestor,AncestorType=c1:DataGridRowPresenter}, Path=Row.DataItem.State.Code}" Value="new"> <Setter Property="Background" Value="Wheat"/> </DataTrigger> <DataTrigger Binding="{Binding RelativeSource={RelativeSource Mode=FindAncestor,AncestorType=c1:DataGridRowPresenter}, Path=Row.DataItem.State.Code}" Value="confirmed"> <Setter Property="Background" Value="LightGreen"/> </DataTrigger> </Style.Triggers> </Style> 

ठीक है, ठीक है, यह अप्रिय है, लेकिन इतना महत्वपूर्ण नहीं है।

परेशान है कि आप CellTemplateSelector सेट नहीं कर सकते। बेशक, एक वास्तविक एप्लिकेशन में, आप हमेशा चयनकर्ता के बिना कार्य करने के लिए rephrase कर सकते हैं, लेकिन यह खतरनाक है।

मास्टर भाग

यहां सब कुछ ठीक है। डिफ़ॉल्ट शैली पूरी तरह से तैयार है, विवरण अच्छी तरह से बंधे हैं, मार्कअप न्यूनतम रूप से ग्रस्त है, DevExpress जैसे अतिरिक्त मध्यवर्ती टैग की आवश्यकता के बिना:

 <c1:C1DataGrid.RowDetailsTemplate> <DataTemplate> <c1:C1DataGrid x:Name="gridOrderItems" IsReadOnly="False" AutoGenerateColumns="False" ItemsSource="{Binding Path=SalesOrderItems}"> <c1:C1DataGrid.Columns> <c1:DataGridTextColumn Binding="{Binding Path=SalesOrderItemId, Mode=TwoWay}" Header="Item Id" /> <c1:DataGridTextColumn Binding="{Binding Path=Product.Name, Mode=TwoWay}" Header="Product name" /> </c1:C1DataGrid.Columns> </c1:C1DataGrid> </DataTemplate> </c1:C1DataGrid.RowDetailsTemplate> 

एक नेस्टेड ग्रिड में, सब कुछ अभी भी पूरी तरह से संपादित है, जिसमें संबंधित वस्तुओं के क्षेत्र भी शामिल हैं। मान्यता डिफ़ॉल्ट रूप से घुसपैठ नहीं है और संपादन करते समय कष्टप्रद नहीं है।

ट्री ग्रिड

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

"बॉक्स से बाहर" ऐसी कोई कार्यक्षमता नहीं है, लेकिन उदाहरणों में एक समान है:

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

कॉलम हेडर का संयोजन।

व्यवसाय कार्य एक बहु-स्तरीय तालिका शीर्ष लेख को संघ के साथ बनाने के लिए है:

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

C1FlexGrid घटक में AllowMerging गुण है; इसे पंक्तियों और / या स्तंभों के लिए अलग से भी सेट किया जा सकता है। यह गुण आसन्न कोशिकाओं के स्वचालित संघ को सक्षम करता है यदि उनके समान मूल्य हैं। यह शांत काम करता है, लेकिन एक संदेह है कि यह बड़े संस्करणों पर धीमा हो जाएगा (हम एक ही निर्माता के प्राचीन WinForms ग्रिड में इसके साथ समस्याएं थीं)।

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

  public ComponentOneComparision() { InitializeComponent(); _headerColumnRows = new[] { TopColumnHeaderRow, BottomColumnHeaderRow }; } private DataGridRow[] _headerColumnRows; private void dataGrid_MergingCells(object sender, C1.WPF.DataGrid.DataGridMergingCellsEventArgs e) { //      var nonHeadersViewportCols = dataGrid.Viewport.Columns.ToArray(); var nonHeadersViewportRows = dataGrid.Viewport.Rows.Where(r => !_headerColumnRows.Contains(r)).ToArray(); //    foreach (var range in MergingHelper.Merge(Orientation.Vertical, _headerColumnRows, nonHeadersViewportCols, true)) { e.Merge(range); } } 

इसी समय, xaml में स्तंभ शीर्ष इस तरह दिखे:

 <c1:DataGridTemplateColumn Header="[, ]" /> <c1:DataGridTemplateColumn Header="[, ]"/> <c1:DataGridTextColumn Header="[, ]"/> 

दो कस्टम लाइनों को भी जोड़ना था?

 <c1:C1DataGrid.TopRows> <c1:DataGridColumnHeaderRow x:Name="TopColumnHeaderRow"/> <c1:DataGridColumnHeaderRow x:Name="BottomColumnHeaderRow"/> </c1:C1DataGrid.TopRows> 

और आपको ग्रिड संपत्ति सेट करके मानक कॉलम हेडर को अक्षम करना होगा:

 <c1:C1DataGrid HeadersVisibility="Row" 

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

WCF DataServices के लिए रिकॉर्ड और समर्थन का आलसी पोस्ट लोडिंग

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

फोरम के पास WCF DataServices समर्थन को लागू करने के लिए एक खुला टिकट है, लेकिन अभी तक यह शांत है। यह उम्मीद की जा सकती है कि यह कार्यक्षमता, यदि कार्यान्वित की जाती है, तो यह बहुत ही ठोस होगी।

क्लिपबोर्ड पर कॉपी करें और एक्सेल को निर्यात करें

यह काम करता है। यह सिर्फ एक नखरे के साथ नृत्य के बिना काम करता है। लेकिन केवल फ्लैट टेबल के लिए। मर्ज किए गए कॉलम हेडर निर्यात नहीं करेंगे। ग्रिड के मास्टर भाग के लिए, जो लाइनें फ़ोकस (मास्टर या भाग) में होती हैं, उन्हें बफर में कॉपी किया जाता है, केवल मास्टर ग्रिड की पंक्तियों को एक्सेल में निर्यात किया जाता है। टेम्पलेट कॉलम के लिए, रिक्त लाइनों को बफर में कॉपी किया जाता है, पंक्ति डेटा ऑब्जेक्ट के टॉसस्ट्रिंग () विधि का परिणाम एक्सेल को निर्यात किया जाता है।

मुद्रण सामग्री

ग्रिड में एक प्रिंट (स्ट्रिंग डॉकनेम) विधि होती है , जो संपूर्ण ग्रिड को प्रिंट करने के लिए एक प्रिंटर का चयन करने के लिए एक संवाद खोलता है। एक विधि भी है:

 List<FrameworkElement> GetPageImages(…) 

जो एक पृष्ठांकित ग्रिड लौटाता है। फिर परिणामी संग्रह को PrintDocument में पैक किया जा सकता है और इसे एक पूर्वावलोकन में दिखाते हुए, xps दस्तावेज़ के रूप में मुद्रित किया जा सकता है।

स्थानीयकरण

यहां भी सब ठीक है। बॉक्स में से 21 भाषाओं में स्थानीयकरण है, जिसमें हमारी परियोजना (रूसी और चीनी) आवश्यक हैं।

यूआई स्वचालन समर्थन

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

फैसला

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

Telerik

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

स्तंभ बंधन, स्पीकर अनुकूलन

पिछले विषयों की तुलना में यहां सब कुछ बेहतर है। बाइंडिंग अपेक्षा के अनुरूप काम करती है, कोशिकाओं में डेटा अच्छी तरह से संपादित होता है। एक डिफ़ॉल्ट सत्यापन है, यह परेशान नहीं करता है। बाइंडिंग (और, वाकई, मान्यता) (मूल WPF में के रूप में नुकसान पाठ बॉक्स ध्यान देने का समय सक्रिय होता है पाठ बॉक्स )।

आप एक कॉलम के लिए एक शैली और एक टेम्पलेट निर्दिष्ट कर सकते हैं, एक टेम्पलेट चयनकर्ता, और यहां तक ​​कि एक शैली चयनकर्ता भी। सब कुछ वैसा ही है जैसा होना चाहिए। स्टाइल बाइंडिंग अपेक्षित। यह कैसे पृष्ठभूमि रंग के लिए डेटाट्रेगर के साथ शैली है, यह आदेश की स्थिति पर निर्भर करता है (कॉम्पोनेन्टऑन ग्रिड के लिए शैली के साथ तुलना करें):

 <Style x:Key="SatetCellStyle" TargetType="telerik:GridViewCell"> <Setter Property="Background" Value="Transparent"/> <Style.Triggers> <DataTrigger Binding="{Binding Path=State.Code}" Value="new"> <Setter Property="Background" Value="Wheat"/> </DataTrigger> <DataTrigger Binding="{Binding Path=State.Code}" Value="confirmed"> <Setter Property="Background" Value="LightGreen"/> </DataTrigger> </Style.Triggers> </Style> 

मास्टर भाग

सब कुछ अभी भी अपेक्षित और अच्छा है, लेकिन आपको एक विशेष टैग जोड़ने की आवश्यकता है। विस्तार ग्रिड घोषणा इस तरह दिखता है:

 <telerik:RadGridView.ChildTableDefinitions> <telerik:GridViewTableDefinition /> </telerik:RadGridView.ChildTableDefinitions> <telerik:RadGridView.HierarchyChildTemplate> <DataTemplate> <telerik:RadGridView ItemsSource="{Binding Path=SalesOrderItems}" AutoGenerateColumns="False"> <telerik:RadGridView.Columns> <telerik:GridViewDataColumn DataMemberBinding="{Binding Path=SalesOrderItemId}" /> <telerik:GridViewDataColumn DataMemberBinding="{Binding Path=Product.Name}" /> </telerik:RadGridView.Columns> </telerik:RadGridView> </DataTemplate> </telerik:RadGridView.HierarchyChildTemplate> 

ComponentOne की तुलना में थोड़ा अधिक है, लेकिन DevExpress जैसी बहुस्तरीय संरचना अभी भी दूर है।

ग्रिड विस्तार में, पंक्तियों को पूरी तरह से संपादित किया जाता है, ग्रिड सुंदर दिखता है।

ट्री ग्रिड

प्रारंभ में, मैंने ग्रिड ग्रिड में ही इसे लागू करने का प्रयास किया, जिससे GridViewTableDefinition को TreeListViewTableDefinition में बदल दिया । इंटरफ़ेस नहीं बदला है। सबसे पहले मैं परेशान था और अपनी तुलना प्लेट में एक बोल्ड माइनस लिखा था, लेकिन मैंने पाया कि ऐसा एक RadTreeListView घटक है , जो RadGridView के साथ मिलकर एक सामान्य पूर्वज, GridViewDataControl है , और यह ठीक वैसा ही काम करता है जैसा कि उपयोगकर्ता अपेक्षा करता है।

यहाँ मार्कअप है:

 <telerik:RadTreeListView ItemsSource="{Binding Path=Departments}" AutoGenerateColumns="False" IsReadOnly="True" SelectionMode="Extended" ClipboardCopyMode="All"> <telerik:RadTreeListView.Columns> <telerik:GridViewDataColumn DataMemberBinding="{Binding Path=DepartmentId}" Header="" /> <telerik:GridViewDataColumn DataMemberBinding="{Binding Path=Name}" Header="" /> <telerik:GridViewDataColumn DataMemberBinding="{Binding Path=Head.Name}" Header=""/> </telerik:RadTreeListView.Columns> <telerik:RadTreeListView.ChildTableDefinitions> <telerik:TreeListViewTableDefinition ItemsSource="{Binding Children}"/> </telerik:RadTreeListView.ChildTableDefinitions> </telerik:RadTreeListView> 

जब आप शुरू करते हैं, तो आपको यह ग्रिड मिलता है:

कॉलम हेडर का संयोजन। स्तरित कॉलम हेडर।

यहां सब कुछ बुरा नहीं है। संयुक्त स्तंभ शीर्षकों को मार्कअप में निम्नानुसार सेट किया गया है:

 <telerik:RadGridView.ColumnGroups> <telerik:GridViewColumnGroup Header="" Name="StateGroup"/> </telerik:RadGridView.ColumnGroups> <telerik:RadGridView.Columns> <telerik:GridViewDataColumn Header="" ColumnGroupName="StateGroup"/> <telerik:GridViewDataColumn Header="" ColumnGroupName="StateGroup"/> <telerik:GridViewDataColumn Header="" ColumnGroupName="StateGroup"/> </telerik:RadGridView.Columns> 

यह इस तरह दिखता है:

इसी समय, ComponentOne के विपरीत, कॉलम हेडर की सभी कार्यक्षमता बनी हुई है:

लेकिन टेलरिक डेटा कोशिकाओं, पंक्ति हेडर को संयोजित नहीं कर सकता है और वास्तव में बहु-स्तरीय कॉलम हेडर (2 से अधिक स्तर) बना सकता है। दु: खी लेकिन सहनशील।

WCF DataServices के लिए रिकॉर्ड और समर्थन का आलसी पोस्ट लोडिंग

ग्रिड में स्क्रॉल करते समय टेलरिक लाइब्रेरीज़ रिकॉर्ड के आलसी लोडिंग का समर्थन करते हैं। अगर हम ग्रिड डेटा स्रोत में VirtualQueryableCollectionView डालते हैं और आइटम्स को लोड करने वाले इवेंट हैंडलर को कार्यान्वित करते हैं , तो जब ग्रिड स्क्रॉल करेंगे तो डेटा के अगले टुकड़े को लोड करने का अनुरोध करेंगे। लाइब्रेरी में भी System.Linq.IQueryable के लिए विस्तार विधियां हैं , जो आपको ऐसी क्वेरी बनाने की अनुमति देती हैं:

 VirtualQueryableCollectionView EntityList; … var query = (DataServiceQuery) _dataContext.SalesOrders .IncludeTotalCount() .Sort(EntityList.SortDescriptors) .Where(EntityList.FilterDescriptors) .Skip(start) .Take(count); 

नतीजतन, कई आंदोलनों में हमें सर्वर फ़िल्टरिंग और सॉर्टिंग के साथ एक आलसी ग्रिड मिलता है।

क्लिपबोर्ड पर कॉपी करें और एक्सेल को निर्यात करें

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

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

मुद्रण सामग्री

WPF के लिए एक ग्रिड में यह कार्यक्षमता नहीं है और अपेक्षित नहीं है। आधिकारिक मंच ने इसके लिए टेलरिक रिपोर्टिंग का उपयोग करने का सुझाव दिया है।

स्थानीयकरण

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

यूआई स्वचालन समर्थन

यह ComponentOne से बेहतर है - ग्रिड कोशिकाओं को अभी भी ग्रिड कोशिकाओं के रूप में मान्यता प्राप्त है, लेकिन उनके RowIndex और ColumnIndex मान शून्य हैं। सामान्य तौर पर, इस पहलू में, Xceed ग्रिड सबसे अच्छा निकला।

फैसला

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

निष्कर्ष

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

4.5 साल हो गए। हम कह सकते हैं कि इन्फ्रास्ट्रक्चर को छोड़कर हर कोई बहुत आगे निकल चुका है और अभी भी चुनाव करना मुश्किल है।

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

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

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