2012-04-12 31 views
5

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

जो मैं जानना चाहता हूं, ज्यादातर जिज्ञासा से बाहर है क्योंकि यह पहले से ही काम कर रहा है, क्या इन दो तरीकों को कॉल करना अधिक उपयुक्त है?

क्या मुझे उन्हें CurrentIndex संपत्ति के भीतर कॉल करना चाहिए? क्या मुझे उन्हें OnCurrentIndexChanged(...) के भीतर कॉल करना चाहिए? क्या मुझे कक्षा के भीतर घटना को संभालना चाहिए और वहां ऐसा करना चाहिए?

उत्तर

6

मुझे लगता है कि आपने मानक ईवेंट जनरेटिंग पैटर्न लागू किया है और ऑनकुरेंट इंडेक्स चेंज protected virtual बनाया है ताकि एक व्युत्पन्न वर्ग विधि को ओवरराइड कर सके और ईवेंट पीढ़ी और/या हैंडलिंग को बदल सके।

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

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

और यदि आपके लिए यह बहुत डरावना है तो वर्चुअल विधि का उपयोग न करने में संकोच न करें। अपने नियंत्रण के साथ सैकड़ों हजार प्रोग्रामर को समायोजित करना आम बात नहीं है :)

+0

लागू नहीं कर रहा हूं इस तथ्य को ध्यान में रखते हुए कि विरासत वर्ग वास्तव में मेरी बेस क्लास को ओवरराइड कर सकता है, दृष्टिकोण में कुछ परिप्रेक्ष्य रखता है। धन्यवाद। – PedroC88

2

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

+0

यह मूल रूप से मेरे पास है, यह धारणा है कि आप ऑब्जेक्ट को सेट नहीं करते हैं लेकिन ऑब्जेक्ट की अनुक्रमणिका, और इंडेक्स के सेटटर में मैं ईवेंट बढ़ाता हूं। मुझे क्या पता नहीं है कि मुझे उसी सेटटर के भीतर अन्य विधियों को कॉल करना चाहिए? या उस विधि के भीतर जो घटना को उठाता है? या एक ही कक्षा के भीतर एक प्रतिनिधि के भीतर? या किसी भी अन्य जगह के साथ आप लोग आते हैं। – PedroC88

+1

@ पेड्रोसी 88 मैं प्रत्येक विधि को संपत्ति के सेटटर से कॉल करूंगा। मैंने देखा है कि बहुत उपयोग किया जाता है और नियंत्रण अधिक जटिल हो जाने के बाद विधियों को जोड़ना आसान हो जाता है। यह INotifyPropertyChanged इंटरफ़ेस और अमूर्तता का क्रूक्स काफी सुंदर है। – Josh

+0

इस तरह मेरे पास अभी वास्तव में है, मैं संपत्ति के सेटटर में दोनों विधियों को बुलाता हूं, मैं सिर्फ यह देखना चाहता था कि कोई बेहतर दृष्टिकोण (और क्यों) था। ऐसा लगता है कि हम वहां सहमत हैं। अनुलेख मैं 'INotifyPropertyChanged' – PedroC88

1

क्योंकि आपका UserControl ListControl के रूप में कार्य करता है, तो आपको दो ईवेंट और दो गुणों को लागू करने की आवश्यकता होती है।

public event System.EventHandler SelectedIndexChanged; 
public event System.EventHandler SelectionChangeCommitted; 

public int SelectedIndex { 
    get; 
    set; 
} 

public T SelectedItem { // Where T is whatever your type is 
    get; 
    set; 
} 

SelectedIndexChanged हमेशा कार्रवाई है कि हमेशा जब आपके चयनित सूचकांक बदल गया है शुरू किया जा करने की आवश्यकता है के लिए इस्तेमाल किया जाना चाहिए। SelectionChangeCommittedकेवल ट्रिगर हो सकता है जब उपयोगकर्ता शारीरिक रूप से चयन को बदलता है। दोनों के बीच अलगाव एक महत्वपूर्ण भेद है, और .NET में अधिकांश नियंत्रण इस पैटर्न का पालन करते हैं (उदाहरण के लिए कॉम्बोबॉक्स), लेकिन घटनाओं के लिए समान नाम का उपयोग नहीं कर सकते हैं।

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

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

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

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

उम्मीद है कि इससे मदद मिलती है।