पाठ इनपुट को सीमित करने के लिए संलग्न गुण

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

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

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

नोट
यदि आप मेरे तर्क में बहुत रुचि नहीं रखते हैं, लेकिन आपको तत्काल कोड नमूनों की आवश्यकता है, तो आप या तो GitHub से संपूर्ण WpfEx प्रोजेक्ट डाउनलोड कर सकते हैं , या मुख्य कार्यान्वयन डाउनलोड कर सकते हैं, जो TextBoxBehavior.cs और TextBoxDoubleValidator.cs में निहित है ।

अच्छा, चलिए शुरू करते हैं?

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

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

समस्या हल करना

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

public class TextBoxBehavior { // Attached   ,     //     public static readonly DependencyProperty IsDoubleProperty = DependencyProperty.RegisterAttached( "IsDouble", typeof (bool), typeof (TextBoxBehavior), new FrameworkPropertyMetadata(false, OnIsDoubleChanged)); //      IsDouble     // UI ,  TextBox    [AttachedPropertyBrowsableForType(typeof (TextBox))] public static bool GetIsDouble(DependencyObject element) {} public static void SetIsDouble(DependencyObject element, bool value) {} // ,   TextBoxBehavior.IsDouble="True"  XAML- private static void OnIsDoubleChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { //   } } 

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

 // ,   TextBoxBehavior.IsDouble="True"  XAML- private static void OnIsDoubleChanged(DependencyObject d, DependencyPropertyChangedEventArgs e) { //     attached    // TextBox   ,    -  var textBox = (TextBox) d; //       : // 1.     // 2.      textBox.PreviewTextInput += PreviewTextInputForDouble; DataObject.AddPastingHandler(textBox, OnPasteForDouble); } 

क्लास टेक्स्टबॉक्स डबलडॉलेगेटर

दूसरा महत्वपूर्ण बिंदु नए दर्ज किए गए पाठ के सत्यापन तर्क का कार्यान्वयन है, जिसके लिए जिम्मेदारी एक अलग TextBoxDoubleValidator वर्ग के IsValid विधि को सौंपी गई है ।

यह समझने का सबसे आसान तरीका है कि इस वर्ग की ईवीएल विधि को कैसे व्यवहार करना चाहिए, इसके लिए एक इकाई परीक्षण लिखना है जो सभी कोनों के मामलों को कवर करता है (यह उन मामलों में से एक है जब पैरामीटरित इकाई परीक्षण भयानक बल के साथ शासन करते हैं):

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

 private static void PreviewTextInputForDouble(object sender, TextCompositionEventArgs e) { // e.Text    ,     //  TextBox-   var textBox = (TextBox)sender; string fullText; //  TextBox   ,     e.Text if (textBox.SelectionLength > 0) { fullText = textBox.Text.Replace(textBox.SelectedText, e.Text); } else { //          fullText = textBox.Text.Insert(textBox.CaretIndex, e.Text); } //     bool isTextValid = TextBoxDoubleValidator.IsValid(fullText); //    TextChanged    e.Handled = !isTextValid; } 

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

लोकेल की स्पष्ट स्थापना आवश्यक है ताकि परीक्षण अन्य व्यक्तिगत सेटिंग्स के साथ डेवलपर्स के लिए न पड़ें, क्योंकि रूसी लोकेल में, प्रतीक ',' (अल्पविराम) को विभाजक के रूप में उपयोग किया जाता है, और अमेरिकी में - '।' (डॉट)। एक अजीब पाठ जैसे "-"। सही है, क्योंकि उपयोगकर्ता को स्ट्रिंग "-1" में प्रवेश करना है, तो हमें प्रविष्टि पूरी करनी होगी, जो कि डबल के लिए सही मान है। (दिलचस्प बात यह है कि StackOverflow पर, इस समस्या को हल करने के लिए केवल डबल.ट्रीपर्स का उपयोग करने की सलाह दी जाती है, जो स्पष्ट रूप से कुछ मामलों में काम नहीं करेगा)।

नोट
मैं इस विधि के कार्यान्वयन विवरण के साथ लेख को अव्यवस्थित नहीं करना चाहता, मैं केवल थ्रेडलोकल <टी> की इस पद्धति के शरीर में उपयोग को नोट करना चाहता हूं, जो आपको प्रत्येक स्ट्रीम के लिए स्थानीय रूप से डबलसेपरेटर प्राप्त करने और कैश करने की अनुमति देता है। TextBoxDoubleValidator.IsValid विधि का पूर्ण कार्यान्वयन यहां पाया जा सकता है, थ्रेडलोकल <T> के बारे में अधिक जानकारी जो अलबहारी के लेख में काम कर रही है। भाग ३

वैकल्पिक समाधान

प्रीव्यूटेक्स्ट इंपुट इवेंट्स को कैप्चर करने और क्लिपबोर्ड से टेक्स्ट चिपकाने के अलावा, अन्य उपाय भी हैं। इसलिए, उदाहरण के लिए, मुझे एक ही समस्या को हल करने का प्रयास किया गया था, जिसमें किवेक को छोड़कर सभी कुंजी को फ़िल्टर करने के साथ PreviewKeyDown इवेंट को इंटरसेप्ट किया गया था। हालाँकि, यह समाधान अधिक जटिल है, क्योंकि आपको अभी भी टेक्स्टबॉक्स के "सारांश" स्थिति से परेशान होना है, और सैद्धांतिक रूप से, पूर्णांक और भिन्नात्मक भागों का विभाजक केवल एक वर्ण नहीं हो सकता है, लेकिन एक संपूर्ण स्ट्रिंग ( NumberFormatfo.NumberDecimalSeparator एक स्ट्रिंग लौटाता है, नहीं)।
KeyDown ईवेंट में TextBox.Text की पिछली स्थिति को बचाने के लिए एक और विकल्प है, और यदि नया मान सूट नहीं करता है, तो पुराने मूल्य को वापस करने के लिए TextChanged ईवेंट में। लेकिन यह समाधान अप्राकृतिक दिखता है, और संलग्न गुणों का उपयोग करके इसे लागू करना इतना आसान नहीं होगा।

निष्कर्ष

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

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