शुरुआती बिंदु के रूप में, टेलीरिक के पास एक https://www.telerik.com/universal-windows-platform-ui/numericbox है। यह ओपन सोर्स में भी उपलब्ध है: https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs।

मुझे उनसे जो पसंद है वह संपत्ति ValueFormat के साथ स्वरूपण के लिए उनका दृष्टिकोण है।

उदाहरण: ValueFormat="{}{0,0:C2}"

कृपया यह भी सुनिश्चित करें कि यह सही ढंग से स्थानीयकृत है। Windows समुदाय टूलकिट कार्यान्वयन में कुछ कमियाँ हैं:

ValidationType="Decimal" के साथ TextBoxRegex एक्सटेंशन सभी UI संस्कृतियों का समर्थन नहीं करता है। इसके बजाय यह InvariantCulture के लिए तय है। अंग्रेजी में दशमलव मान "10.1234" एक अवधि के साथ हैं। स्पेनिश या जर्मन में दशमलव मान "10,1234" लिखे जाते हैं। अंग्रेजी को पार्स करना सही होगा; हालांकि, स्पैनिश या जर्मन उपयोगकर्ता इनपुट केवल "101234" होगा जिसमें आंशिक भाग खो जाएगा।

देखें: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2700

ऊपर और नीचे तीरों को उस मान से मूल्य बढ़ाना या घटाना चाहिए जिसे देव सेट कर सकता है, लेकिन डिफ़ॉल्ट 1 का int होना चाहिए

• रैपराउंड न्यूनतम/अधिकतम मान अच्छा है जैसे कोण का चयन करते समय
• प्रत्यय जोड़ने की क्षमता
• टेक्स्टबॉक्स पर क्लिक करें और मानों को बदलने के लिए ऊपर/नीचे खींचें, Adobe XD में यह संख्या इनपुट में है।

विनआरटी एक्सएएमएल टूलकिट में मेरा कार्यान्वयन मूल्यों को बदलने के लिए ऊपर/नीचे खींचने का भी समर्थन करता है और कुछ परिदृश्यों में बटन क्लिक करने से माउस के साथ उपयोग करते समय यह इसे और अधिक उपयोगी बनाता है।
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

हैलो, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , और @xyzzer! मुझे यह प्रस्ताव सौंपा गया है।

सबसे पहले, @sonnemaf , इसे सबमिट करने के लिए धन्यवाद। मैंने इसे पिछले सप्ताह Microsoft Build 2019 में दिखाया और इसे दर्शकों से चीयर्स मिला! टिप्पणियों में यहां समुदाय की प्रतिक्रिया भी उस उत्साह को दर्शाती है जो हमें नंबरबॉक्स को होते देखने के लिए है।

मैंने सभी की टिप्पणियों को पढ़ लिया है और प्राप्त इनपुट को दर्शाने के लिए स्कोप सेक्शन को अपडेट कर दिया है। मैं इसकी सराहना करूंगा यदि हर कोई इस छोटे से अपडेट को और मुझे बता सकता

हाय @SavoySchuler ,

इस हफ्ते, मैं अपने ऐप पर एक्सेसिबिलिटी फीचर पर काम कर रहा हूं। यह एक प्लस होगा यदि अभिगम्यता को नए नियंत्रण के साथ सही ढंग से नियंत्रित किया जाएगा उदाहरण के लिए, वृद्धि को "प्लस", "माइनस" के बजाय जोर से कहा जा सकता है। बाकी मुझे ठीक लगता है।

यह सुनिश्चित करना कि कथाकार मूल्यों को ठीक से पढ़ने में सक्षम है, इसलिए यह स्पष्ट है कि जो हो रहा है वह महत्वपूर्ण है।

सुनिश्चित नहीं है कि एनालॉग स्टिक्स और डी-पैड सही ढंग से काम करेगा यह सुनिश्चित करने के लिए Xbox नियंत्रक को किसी फोकस टैपिंग की आवश्यकता होगी

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

@SavoySchuler आपको एक अच्छा काम मिला है। मैं आपके दायरे में रह सकता हूं। कैलकुलेटर होना अच्छा है (WinUI 3.0 या 3.1)। मैंने कई डेस्कटॉप वातावरण (वीबी 6, विनफॉर्म, डब्ल्यूपीएफ और यूडब्ल्यूपी) में विकसित किया है और हमेशा नंबरबॉक्स को याद किया है। अंत में हम इसे प्राप्त करेंगे।

हो सकता है कि आप ऊपर/नीचे के लिए माउस स्क्रॉल व्हील भी जोड़ सकते हैं। विजुअल स्टूडियो के लिए ब्लेंड इसका समर्थन करता है।

मुझे ड्रैग-टू-चेंज भी पसंद है, कुछ ऐसा जो मैंने एक्सप्रेशन ब्लेंड में बहुत इस्तेमाल किया।

मुझे यकीन नहीं है कि इनपुट सत्यापन क्या करेगा और क्या नहीं। क्या यह केवल न्यूनतम/अधिकतम होगा या कीबोर्ड (अक्षर az, आदि) को भी सीमित करेगा? क्या यह अमान्य नंबरों को चिपकाने से निपटेगा?

मुझे पूरा चश्मा पढ़ना अच्छा लगेगा।

@ArchieCoder , मैं आपको जोर से और स्पष्ट सुनता हूं। अभिगम्यता एक प्राथमिकता है और इसका सबसे अच्छा अग्रिम रूप से संचालन किया जाता है। मैंने इस प्रस्ताव पर एक एक्सेसिबिलिटी और इनपुट सेक्शन शुरू किया है जहाँ मैंने आपका नोट जोड़ा है।

@mdtauk , हमेशा की तरह बढ़िया सवाल। मैंने इसे देखने के लिए एक नोट के रूप में इसे एक्सेसिबिलिटी और इनपुट सेक्शन में जोड़ा है।

@xyzzer , तुम सही हो। स्कोप सूची को पुनर्गठित करते समय, मैंने संबंधित कार्यक्षमता के रूप में ऊपर/नीचे बटन और ड्रैग-टू-चेंज को समूहीकृत किया। फिर से पढ़ने पर ऐसा प्रतीत हुआ जैसे मैं बटन पर ड्रैग-टू-चेंज एक फीचर होने का सुझाव दे रहा था। मैंने स्पष्टता प्रदान करने के लिए ड्रैग-टू-चेंज को अपने स्वयं के अनुभाग में स्थानांतरित कर दिया है।

@sonnemaf , कमाल। जैसे ही यह खुलता है, मैं कल्पना के लिए एक लिंक पोस्ट करूंगा, जो आज या अगले सप्ताह होने की संभावना है। कृपया इसे लिखने में मेरे साथ जुड़ने के लिए प्रोत्साहित महसूस करें! तब तक, मैंने यहां स्कोप में स्क्रॉल-टू-चेंज जोड़ा है।

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

इनपुट सत्यापन के लिए, मेरे पास एक ही प्रश्न है। क्या न्यूनतम, अधिकतम, कोई अक्षर नहीं, और कोई अमान्य पेस्टिंग इसे कवर नहीं करता है?

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

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

हमारे पास ऐप स्तर पर मार्गदर्शन के लिए टूलटिप या भारी टीचिंगटिप है जिस पर हम डेवलपर्स से भरोसा करने के लिए कह सकते हैं, लेकिन मेरी मजबूत प्राथमिकता इसे नंबरबॉक्स के भीतर ही हल करना होगा।

मुझे यहां आपके विचार सुनने में दिलचस्पी है!

प्लेसहोल्डर वास्तव में एक अच्छा तरीका होगा जब तक कि स्थान की सीमा के कारण अन्य संदर्भ की आवश्यकता न हो। मुझे लगता है कि उदाहरण के लिए एक नंबरबॉक्स चौड़ाई टेक्स्टबॉक्स से छोटी होगी।

जब तक नियंत्रण अशक्त संख्याओं का समर्थन नहीं करता - यह हमेशा एक मान दिखाएगा,
इसलिए इसके अंदर प्लेसहोल्डर स्ट्रिंग के लिए जगह नहीं होगी।

शुक्र, 17 मई 2019 10:14 ArchieCoder पर पर [email protected]
लिखा था:

प्लेसहोल्डर वास्तव में एक अच्छा तरीका होगा जब तक कि अन्य संदर्भ नहीं है
स्थान की सीमा के कारण आवश्यक है। मुझे लगता है कि एक नंबरबॉक्स चौड़ाई होगी
उदाहरण के लिए टेक्स्टबॉक्स से छोटा हो।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63#issue5VVK92KT
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder , @sonnemaf के उदाहरणों के रूप में देख रहे हैं (इनके लिए फिर से धन्यवाद), कोई भी नंबरबॉक्स जो "ए + बी - सी" के लिए प्लेसहोल्डर टेक्स्ट प्रदर्शित करने के लिए पर्याप्त नहीं है, वह भी अनुशंसित उपयोगकर्ता अनुभव बनाने के लिए पर्याप्त नहीं होगा समीकरणों में प्रवेश करना। उस संबंध में, मुझे लगता है कि इस उद्देश्य के लिए यह समाधान विकल्प अभी भी व्यवहार्य है। हालांकि, मुझे लगता है कि आप एक ऐसे क्षेत्र में प्रवेश कर रहे हैं जिसे हमने अभी तक संबोधित नहीं किया है - ऐसे परिदृश्य जहां हम एक कॉम्पैक्ट नंबरबॉक्स/केवल एक साधारण संख्या दर्ज करना चाहते हैं। मुझे लगता है कि कैलक्यूलेटर समर्थन को इसे अक्षम करने के लिए एक एपीआई की आवश्यकता होगी, इस मामले में हमें लंबे प्लेसहोल्डर टेक्स्ट के साथ खुद को चिंता करने की ज़रूरत नहीं है और न ही न्यूनतम स्पेस बाधाओं को तोड़ने के लिए नंबरबॉक्स के समीकरण फॉर्म की आवश्यकता होगी - हालांकि कॉम्पैक्ट मोड के लिए कुछ प्लेसहोल्डर टेक्स्ट विकल्प अभी भी अच्छा हो सकता है , भले ही वह "#" या "जैसे 2" जैसी किसी चीज़ के लिए ही क्यों न हो।

@xyzzer , इसे लाने के लिए धन्यवाद। आइए सुनिश्चित करें कि यह पहले भी सही उपयोगकर्ता अनुभव है और हम वहां से कार्यान्वयन का पता लगा सकते हैं! तकनीकी सीमाओं के कारण _right_ उपयोगकर्ता अनुभव के लिए हमारी खोज को सीमित करने की अभी कोई आवश्यकता नहीं है जिसे हम कम करने में सक्षम हो सकते हैं। आराम से:

मेरे पास सभी के लिए एक उच्च प्राथमिकता वाला प्रश्न है:

क्या आपके पास एक नंबरबॉक्स नियंत्रण होगा जो इन सुविधाओं को एक मानक टेक्स्टबॉक्स से स्वतंत्र रूप से समेकित करता है या क्या आप इन सुविधाओं को टेक्स्टबॉक्स में मूल क्षमताओं के रूप में बेक करेंगे जिन्हें एपीआई या इनपुटस्कोप के माध्यम से सक्रिय किया जा सकता है?

( @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , और @xyzzer)

यह सब टेक्स्टबॉक्स नियंत्रण में रखना एक महत्वपूर्ण बदलाव है।

दर्ज किए गए वर्णों के लिए सत्यापन।

इनपुटस्कोप के साथ सही कीबोर्ड लेआउट का उपयोग करना

अलग माउस व्यवहार।

फैब्रिकवेब संस्करण के रूप में स्पिनर बटन प्रदर्शित करने की क्षमता।

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

और आप अन्य टेक्स्टबॉक्स व्यवहारों को एक आइकन जैसे संयोजन पर भी विचार कर सकते हैं जो खोज या कैलेंडर का प्रतिनिधित्व कर सकता है जो एक बटन की तरह कार्य करता है। आईपी ​​​​पते या यूआरएल जैसी चीजों के लिए मास्क जो प्लेसहोल्डर टेक्स्ट की शैली में "http://" प्रदर्शित करते हैं जैसे आप इसके बगल में टेक्स्ट में दर्ज करते हैं।

फैब्रिकवेब की टेक्स्टफिल्ड्स के साथ एक विस्तृत विविधता है।

https://developer.microsoft.com/en-us/fabric#/controls/web/textfield

https://developer.microsoft.com/en-us/fabric#/controls/web/spinbutton

मैं निश्चित रूप से इन सभी सुविधाओं को टेक्स्टबॉक्स नियंत्रण में पकाने के बजाय स्वयं के नंबरबॉक्स नियंत्रण के साथ जाऊंगा (इसी तरह एक पासवर्डबॉक्स नियंत्रण भी है और इनपुट-मोड "पासवर्ड" वाला टेक्स्टबॉक्स नहीं है)।

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

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

नियंत्रण की उपस्थिति के संबंध में, मुझे लगता है कि इकाई/प्रत्यय को छोटे आकार/असंतृप्त रंग के साथ प्रदर्शित किया जा सकता है ताकि यह मूल्य से अलग हो:

जब माउस नियंत्रण पर होवर करता है, तो यूनिट के स्थान पर ऊपर/नीचे तीर फीके पड़ सकते हैं:

एक विकल्प figma.com से संख्या नियंत्रण है, जब आप इकाई पर होवर करते हैं तो आप मान को बदलने के लिए बाएं/दाएं पर क्लिक कर सकते हैं।

बाएँ/दाएँ दिलचस्प है क्योंकि माउस को ऊपर/नीचे की तुलना में बाएँ/दाएँ ले जाना आसान है (आपको अपनी कलाई उठाने की ज़रूरत नहीं है)।

अन्य बातें:

• अनफोकस्ड टेक्स्ट एरिया पर क्लिक करते समय, उसे सभी सामग्री का चयन करना चाहिए। ताकि क्लिक करें+एक मान टाइप करें+प्रविष्ट करें मान को बदल दें
• शिफ्ट + एक तीर पर क्लिक करें या शिफ्ट + ऊपर / नीचे जब ध्यान केंद्रित किया जाए तो 10 से वृद्धि या कमी हो (वह मान भी अनुकूलन योग्य होना चाहिए जो मुझे लगता है)।
• मुझे नहीं लगता कि ऊपर/नीचे तीर उपयोगकर्ता के लिए बहुत उपयोगी हैं। यदि उपयोगकर्ता एक सटीक मान चाहता है तो वे इसे टाइप करेंगे, यदि वे सुनिश्चित नहीं हैं कि वे कौन सा मूल्य चाहते हैं तो वे क्लिक + ड्रैगिंग द्वारा मूल्य परिवर्तनों के एक स्पेक्ट्रम की कल्पना कर सकते हैं। तो ऊपर/नीचे तीर शायद कम से कम वैकल्पिक होना चाहिए।

@adrientetar नियंत्रण के अंदर इकाई का संकेत देने से बहुत सारे अतिरिक्त मुद्दे पैदा होते हैं:

• स्थानीयकरण
• पहुँच
• चयन
• चिपकाने
• रूपांतरण

इसे शीर्षलेख, विवरण, या एक अलग टेक्स्टब्लॉक में डालकर इन सभी से बचा जा सकता है।

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

अशक्त संख्याओं के लिए समर्थन मुझे अवश्य लगता है (धन्यवाद @xyzzer)। मूल्य संपत्ति एक अशक्त होना चाहिएडाटा प्रकार। मुझे यकीन नहीं है कि यह एक गैर शून्य मूल्य पर बाध्य करते समय बाध्यकारी मुद्दों का कारण बन जाएगा।

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

सोम, 20 मई, 2019 को दोपहर 2:33 बजे फोन्स सोनमैन्स नोटिफिकेशन @github.com
लिखा था:

अशक्त संख्याओं के लिए समर्थन मुझे अवश्य लगता है (धन्यवाद @xyzzer
https://github.com/xyzzer )। मूल्य संपत्ति एक अशक्त होना चाहिए
डाटा प्रकार। मुझे यकीन नहीं है कि इसे बाध्य करते समय बाध्यकारी समस्याएं पैदा होंगी
एक गैर अशक्त मूल्य।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWK107
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

मेरे पास सभी के लिए एक और सवाल है। क्या आपको इनपुट सत्यापन या मास्किंग की आवश्यकता/पसंद है?

( @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , @xyzzer , और @ फ़ेलिक्स-देव )

सत्यापन आवश्यक है, क्योंकि आप एक स्ट्रिंग में कोई संख्या नहीं जोड़ सकते हैं। और गणितीय ऑपरेटरों को मूल्यांकन और संसाधित करने की आवश्यकता है।

क्या इसे एक त्रुटि संदेश प्रदर्शित करने की आवश्यकता है यदि यह गणना नहीं कर सकता है, कि मैं इसके बारे में निश्चित नहीं हूं।

मास्किंग उपयोगी होगी, लेकिन इसे शायद टेक्स्टबॉक्स में ही बनाया जाना चाहिए, ताकि यूआरएल और ईमेल प्रविष्टि को संभाला जा सके। नंबरबॉक्स टेलीफोन नंबर, आईपी, आदि होगा

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

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

NumberBox पर उनमें से कुछ गुण हो सकते हैं:

• स्पिनर बटन दिखाएँ/छुपाएँ
• मूल्यों की वृद्धि और कमी की अनुमति दें
• मूल्यों की गणना की अनुमति दें
• नकाबपोश इनपुट की अनुमति दें
• स्थानीयकृत मास्क जैसे टेलीफोन नंबर, या आईपी पते

टेक्स्टबॉक्स में जोड़े जा सकने वाले गुण हो सकते हैं:

• एक मास्क संपत्ति - एक कस्टम प्रारूप ([email protected]) को परिभाषित करने के लिए एक एक्सएएमएल स्ट्रिंग और साथ ही डाक/ज़िप कोड जैसे स्थानीयकृत मास्क
• उपसर्ग/प्रत्यय पाठ प्रदर्शन (_http://_ उदाहरण के लिए उपसर्ग के रूप में)
• एक्शन बटन शो/छुपाएं - एक आइकन के साथ और ईवेंट प्रॉपर्टी पर क्लिक करें
• आइकन (फैब्रिक यूआई सर्च बॉक्स बाईं ओर इसका आइकन प्रदर्शित करता है और जब बॉक्स फोकस हो जाता है तो यह एनिमेट हो जाता है)

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

फैब्रिक यूआई स्पिनर बटन स्पर्श के लिए बहुत छोटे हैं, इसलिए मैं इसे अलग तरह से प्रारूपित करूंगा ताकि ऊपर और नीचे के बटन एक दूसरे के ऊपर ढेर न हों।

मेरे लिए मान्य करना जरूरी है और मास्किंग एक अच्छा है। मुझे मास्किंग करना कभी पसंद नहीं आया; यह बहुत कठोर है।

@rudyhuyn ने विंडोज कैलकुलेटर रिपॉजिटरी पर एक अच्छी सुविधा का प्रस्ताव दिया। @mdtauk ने इस पर

आप दिनांक/समय/कैलेंडर पिकर के समान नंबरबॉक्स से कैलकुलेटर पॉपअप खोल सकते हैं।

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

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

TextBox के समान मास्किंग की अनुमति देना और इनपुट जोखिमों को स्वरूपित करने के तरीके के रूप में NumberBox और TextBox बीच के अंतर को भ्रमित करना और प्रत्येक का उपयोग कब किया जाना चाहिए।

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

मैं केवल इन गुणों पर आधारित होने के लिए सत्यापन रखूंगा:

• अधिकतम मूल्य
• न्यूनतम मूल्य
• दशमलव स्थानों की अनुमति दें

अलग से, के संकेत होने की जरूरत है

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

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

फैब्रिक वेब टेक्स्ट नियंत्रण इसे अच्छी तरह से संभालने लगते हैं - लेकिन निश्चित रूप से नंबरबॉक्स का दायरा सामान्य फिट और डिफ़ॉल्ट टेक्स्टबॉक्स नियंत्रण में सुधार से अलग है।

स्पिनर बटन (और वैकल्पिक कैलकुलेटर फ्लाईआउट शायद) केवल दृश्य चीजें हैं जो नंबरबॉक्स के लिए विशिष्ट लगती हैं।

जहां तक ​​संपत्तियों का सवाल है, शायद अगर मूल्य बदलने के लिए कुंजीपटल ऊपर और नीचे बटन सक्षम हैं - एक चरण मान शामिल किया जा सकता है ताकि आप चुन सकें कि कुंजी प्रेस पर कितना बढ़ाना या घटाना है।

@mdtauk , मुझे स्टेप वैल्यू पसंद है, लेकिन न केवल की प्रेस पर। स्क्रॉल और अप/डाउन बटन पर भी।

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

तो StepMinimum और StepMaximum शायद?

तो StepMinimum और StepMaximum शायद?

मुझे नहीं पता कि वे मूल्य किससे संबंधित हो सकते हैं या उनसे क्या उम्मीद की जा सकती है।
यदि "चरण" का उद्देश्य वेतन वृद्धि को परिभाषित करना है तो इसे "वृद्धि" कहते हैं।

यह Max:100 Min:0 Increment:10 को केवल 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, और 100 मानों को निर्दिष्ट करने की अनुमति देगा।

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

@mrlacey मैं स्टेप का उपयोग

मूल्य बढ़ाने या घटाने के लिए ऊपर या नीचे क्लिक करने और खींचने का प्रस्ताव है। यदि उपयोगकर्ता अपेक्षा करता है कि मान तेज़ी से बदलेगा, आप जितना ऊपर या नीचे खींचेंगे, तब न्यूनतम न्यूनतम और अधिकतम मान होने से डेवलपर इसे डेल्टा परिवर्तन के रूप में नियंत्रित कर सकेगा। तो एक छोटी ड्रैग दूरी ०.१ या १ से आगे बढ़ सकती है - लेकिन उदाहरण के लिए ५ या १० के चरणों से आगे खींचना बदल सकता है।

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

बहुत बढ़िया प्रतिक्रिया, सब लोग! मैंने विवरणों को टटोलना शुरू करने के लिए एक युक्ति और पीआर खोला है।

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

कृपया कल्पना लिखने में मेरे साथ जुड़ने के लिए प्रोत्साहित महसूस करें।

टीचिंगटिप की कल्पना एक पूरी तरह से चित्रित उदाहरण है कि एक तैयार युक्ति कैसी दिखेगी। मुख्य रूपरेखा होगी:

• विवरण
• प्रत्येक एपीआई/सुविधा के लिए उदाहरण
• दिशा-निर्देश
• एपीआई (आईडीएल)

महान विचार, मुझे यह पसंद है कि यह सब कहाँ जा रहा है। मेरे दो सेंट जोड़ना:

• प्रश्न के बिना मुझे लगता है कि यह टेक्स्टबॉक्स के साथ एकीकृत होने के बजाय एक अलग नंबरबॉक्स होना चाहिए। इसके अलावा, यहां बहुत सारी अच्छी विशेषताओं पर चर्चा की गई है, लेकिन हमें नंबरबॉक्स को हल्का भी रखना चाहिए। इसलिए, मैं एक कैलकुलेटरबॉक्स या नंबरबॉक्स से मिलता-जुलता कुछ प्राप्त करने का प्रस्ताव करता हूं और इसमें उन्नत "2+3" इनपुट या कैलकुलेटर खोलने के लिए एक बटन हो सकता है।
• स्थानीयकरण को समय से पहले कल्पना में अच्छी तरह से सोचा जाना चाहिए। इसके अतिरिक्त ऐसे मामले हैं जहां आप UI लोकल को ओवरराइड करना चाहेंगे। इसलिए NumberformatInfo प्रॉपर्टी या CultureInfo सेट करना बहुत उपयोगी हो सकता है। उदाहरण के लिए, कुछ अनुप्रयोगों में एक विदेशी और स्थानीय मूल्य दोनों को ट्रैक किया जाता है। प्रत्येक संभावित रूप से एक अलग प्रारूप हो सकता है।
• नियंत्रण को दशमलव स्थान को स्थानांतरित करने में सहायता करने की आवश्यकता है। यह बदले गए प्रत्येक पाठ पर एक प्रारूप को मान्य करने की तुलना में अधिक कठिन है। प्रत्येक वर्ण इनपुट को ट्रैक करने की आवश्यकता है और पिछले दशमलव स्थान को आवश्यकतानुसार बदल दिया गया है।
• किसी भी वृद्धि/कमी तीर को केवल एक सादा इनपुट बॉक्स बंद करने के लिए कॉन्फ़िगर करने योग्य होना चाहिए - फिर से हमें अन्य नियंत्रणों के हिस्से के रूप में आवश्यक मामलों के लिए यहां हल्के नियंत्रण की आवश्यकता होती है।
• कुछ और जिस पर चर्चा नहीं की गई है, हमें आदर्श रूप से कई प्रकारों का समर्थन करने की आवश्यकता है - दशमलव, पूर्णांक और संभावित रूप से लंबा, डबल, आदि ... यह मौलिक रूप से बहुत सी चीजों को बदल सकता है और मैंने इसे अभी तक पूरी तरह से नहीं सोचा है .
• मूल्य निश्चित रूप से शून्य होने की जरूरत है। एक अनसेट मान शून्य से भिन्न होता है।
• एक और विचार जो महत्वपूर्ण नहीं है, वह दशमलव, डबल या फ्लोट प्रकारों के लिए दशमलव परिशुद्धता को निर्दिष्ट करने की अनुमति दे रहा है।

मुझे यकीन है कि और भी विचार आएंगे। मैं कल्पना पढ़ने के लिए उत्सुक हूँ!

( @mdtauk , @xyzzer , @mrlacey , @sonnemaf , @robloo , @Felix-Dev, @adrientetar , @ArchieCoder )

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

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

• सत्यापन अनिवार्य के रूप में नोट किया गया है। मैंने इस नियंत्रण को टेक्स्टबॉक्स से प्राप्त करने के लिए मास्किंग और अन्य सहायक गुण मुफ्त में प्राप्त करने के लिए निर्धारित किया है।

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

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

• @sonnemaf मैं आइकन> पॉपअप कैलकुलेटर उदाहरण की नवीनता और सहजता की सराहना करता हूं। मेरे लिए, यह कैलेंडरडेट पिकर की अवधारणा से उदाहरण के द्वारा प्राप्त होता है और वी 2 सुविधा के लिए एक उत्कृष्ट विचार हो सकता है जब तक कि यहां हर किसी से एक मजबूत धक्का न हो कि इसे वी 1 के लिए माना जाना चाहिए?

यदि कैलक्यूलेटर ओपन सोर्स प्रयास के साथ समन्वय है तो पॉपअप कैलकुलेटर समझ में आ सकता है। दोनों कैलकुलेटर फ्लाईआउट के रूप में स्थिरता के लिए, लेकिन इसके पीछे के इंजन में भी।

सुनिश्चित नहीं है कि यह इस छवि को पोस्ट करने का स्थान है, लेकिन यहां विभिन्न राज्यों के लिए डिज़ाइन हैं जो विनिर्देशों के अनुरूप हैं।

छवि 200% पैमाने पर है

@mdtauk आपके मॉकअप का उद्देश्य क्या है?

प्रत्येक छवि किस राज्य को दिखाने का प्रयास करती है? आपके द्वारा इसे स्पष्ट किए बिना हम ऐसी धारणाएँ बना सकते हैं जो आपसे भिन्न हैं।

क्या ये पिक्सेल सही संदर्भ होने का इरादा रखते हैं?

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

@mrlacey मैं एक फुलर ब्रेकडाउन कर सकता था अगर वह मददगार होगा? मैं कल्पना में बताए गए कुछ उदाहरणों को स्पष्ट करने की कोशिश कर रहा था।

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

उदाहरण दिखाते हैं आराम - फोकस - अक्षम राज्य

पॉपअप कैलकुलेटर V2 के लिए एक अच्छी सुविधा होगी।

मुझे नहीं पता कि मैं अपनी टिप्पणी कहां रखूं। क्या मुझे विशिष्ट रूप से पीआर बनाना चाहिए या क्या मैं इस मुद्दे पर अपने विचार लिख सकता हूं?

पूर्णांक

क्या NumberBoxFormatType के लिए एक पूर्णांक मान उपयोगी होगा?

enum NumberBoxFormatType
{
    IPAddress,
    InternationalTelephone,
    Currency,
    Integer,
}

भाषा

क्या आप मुद्रा, दशमलव अंक-समूहीकरण प्रतीकों को निर्दिष्ट करने के लिए भाषा का उपयोग करेंगे?

अगले उदाहरण में भाषा nl-NL पर सेट है। क्या इसका मतलब यह है कि उपसर्ग यूरो चिह्न है, दशमलव प्रतीक एक अल्पविराम है जिसके बाद 2 दशमलव हैं और अंकों का समूह एक बिंदु है? ऋणात्मक मुद्रा के सामने ऋण चिह्न होता है और अमेरिका की तरह कोई कोष्ठक नहीं होता है।

<TextBlock Header="Price" 
    PlaceholderText="0,00" 
    FormatType="Currency"
    Language="nl-NL" />

क्या यह पर्याप्त है क्योंकि विंडोज़ में कई संख्या और मुद्रा प्रारूप विकल्प हैं।

मूल्य संपत्ति या गुण

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

<TextBlock Header="Price" 
    Value="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

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

<TextBlock Header="Price" 
    ValueNullableDecimal="{x:Bind ViewModel.Employee.Salary, Mode=TwoWay}"
    PlaceholderText="0.00" 
    FormatType="Currency"
    Language="nl-NL" />

MinValue और MaxValue के साथ भी यही बात है। वे अब कल्पना में पूर्णांक हैं, लेकिन क्या यह दोहरा नहीं होना चाहिए?.

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

क्या Language संपत्ति आवश्यक है? यह UILocale जैसा क्यों नहीं होगा? अच्छे कारण हो सकते हैं, लेकिन ऐसा लगता है कि यह उपयोगकर्ता विन्यास योग्य होना चाहिए (एक ओएस स्तर पर) और एक विशिष्ट प्रारूप निर्दिष्ट करने की क्षमता देने से डेवलपर्स के लिए और अधिक समस्याएं हो सकती हैं जब प्रारूप कहीं और मेल नहीं खाता है या उपयोगकर्ता क्या है आवेदन चाहता है। मेरे सिर के ऊपर से: क्या होगा यदि कोई किसी भिन्न प्रारूप में मान में चिपकाता है?

@mdtauk आपके मॉकअप का उद्देश्य क्या है?

प्रत्येक छवि किस राज्य को दिखाने का प्रयास करती है? आपके द्वारा इसे स्पष्ट किए बिना हम ऐसी धारणाएँ बना सकते हैं जो आपसे भिन्न हैं।

क्या ये पिक्सेल सही संदर्भ होने का इरादा रखते हैं?

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

@mrlacey क्या आप इस तरह की चीज चाहते थे?

@mdtauk यह थोड़ा बेहतर है क्योंकि यह कुछ बताता है कि आप क्या दिखाने की कोशिश कर रहे हैं।

हालांकि अंतर्निहित प्रश्न अभी भी बना हुआ है: इसे दिखाने में आपका लक्ष्य क्या है? क्या यह सिर्फ एक विचार है? विभिन्न विचारों की खोज के बाद क्या यह आपका पसंदीदा संस्करण है? यदि हां, तो ये सर्वोत्तम/पसंदीदा क्यों हैं?

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

उदाहरण के लिए, आप सीमा पर पारदर्शिता बदलने का उल्लेख करते हैं। क्या यह परिवर्तन सभी नियंत्रणों के लिए है या केवल एक के लिए है? और किन राज्यों में?

स्पष्ट आकार (बटन के लिए) देना डिज़ाइन कंप्स में समस्याग्रस्त हो सकता है क्योंकि वे हमेशा अपने कंटेनर के आकार के आधार पर समान रूप से अनुवाद नहीं करते हैं। क्या उन्हें हमेशा चौकोर होना चाहिए? या उनकी चौड़ाई तयशुदा नियंत्रण ऊंचाई पर आधारित है?

आप उपसर्ग और प्रत्यय के लिए पृष्ठभूमि ब्रश का प्रस्ताव कैसे कर रहे हैं? मैं एक मौजूदा सिस्टम ब्रश मान रहा हूं, लेकिन कौन सा?

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

@mdtauk यह थोड़ा बेहतर है क्योंकि यह कुछ बताता है कि आप क्या दिखाने की कोशिश कर रहे हैं।

हालांकि अंतर्निहित प्रश्न अभी भी बना हुआ है: इसे दिखाने में आपका लक्ष्य क्या है? क्या यह सिर्फ एक विचार है? विभिन्न विचारों की खोज के बाद क्या यह आपका पसंदीदा संस्करण है? यदि हां, तो ये सर्वोत्तम/पसंदीदा क्यों हैं?

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

उदाहरण के लिए, आप सीमा पर पारदर्शिता बदलने का उल्लेख करते हैं। क्या यह परिवर्तन सभी नियंत्रणों के लिए है या केवल एक के लिए है? और किन राज्यों में?

नंबरबॉक्स स्पेक में कोई दृश्य उदाहरण शामिल नहीं था, और मूल प्रस्ताव में छवियां कार्यक्षमता के लिए मोटे उदाहरण हैं। एक और पीआर #524 है जहां 2epx पर कॉर्नररेडियस वैल्यू के साथ कंट्रोल टेम्प्लेट अपडेट हो रहे हैं, जो कि फैब्रिक वेब द्वारा उपयोग की जाने वाली एक ही राउंडिंग है।

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

स्पष्ट आकार (बटन के लिए) देना डिज़ाइन कंप्स में समस्याग्रस्त हो सकता है क्योंकि वे हमेशा अपने कंटेनर के आकार के आधार पर समान रूप से अनुवाद नहीं करते हैं। क्या उन्हें हमेशा चौकोर होना चाहिए? या उनकी चौड़ाई तयशुदा नियंत्रण ऊंचाई पर आधारित है?

वर्तमान टेक्स्टबॉक्स में कुछ एकीकृत बटन हैं, जैसे कि सर्चबॉक्स, पासवर्ड रिवील बटन और क्लियर टेक्स्ट बटन। XAML के लिए टच टारगेट बटन 32 x 32 epx होने का सुझाव देते हैं - मैंने उन्हें केवल वर्गाकार रखा और उस मार्गदर्शन का उपयोग किया।

आप उपसर्ग और प्रत्यय के लिए पृष्ठभूमि ब्रश का प्रस्ताव कैसे कर रहे हैं? मैं एक मौजूदा सिस्टम ब्रश मान रहा हूं, लेकिन कौन सा?

मेरे उदाहरण में मैंने थीम फ़ोरग्राउंड कलर का उपयोग किया लेकिन 15% की अस्पष्टता का उपयोग किया। फैब्रिकवेब वाले 10% के करीब उपयोग करते हैं, और XAML बटन 20% का उपयोग करते हैं।
ListLowBrush जैसे समान ब्रश मान हैं लेकिन इसके लिए एक नए TextBoxAppendixBackground ब्रश की आवश्यकता हो सकती है। टेक्स्ट फ़ोरग्राउंड समान प्लेसहोल्डर टेक्स्ट फ़ोरग्राउंड ब्रश का उपयोग करेगा।

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

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

मैंने IP v4 पते का उपयोग किया क्योंकि यह कल्पना में दिखाया गया उदाहरण है, और मेरा मूल इरादा यह बताना था कि क्या प्रस्तावित किया जा रहा था (हालाँकि उपसर्ग और प्रत्यय उदाहरणों की कमी थी इसलिए मैंने अन्य मूल्यों को चुना)

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

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

बस एक नोट के रूप में मैं अब टेक्स्टबॉक्स के साथ काम कर रहा हूं, इसके साथ https://doc.qt.io के समान उपयोगकर्ता द्वारा बदले गए मान (यानी खोए हुए फोकस और रिटर्न कुंजी का संघ) को सिग्नल करने के लिए कोई एकल घटना नहीं है। NumberBox में रखना बहुत अच्छा होगा क्योंकि यह इस प्रकार के संपादनों के लिए है। वैसे, अगर यह आईपी पते जैसे सभी प्रकार के मूल्यों को संभालने जा रहा है तो शायद "नंबर" बॉक्स नाम से बहुत संकीर्ण है? यह ValueBox या तो हो सकता है

@adrientetar NumberBox एक नाम के रूप में ठीक लगता है, क्योंकि यह सभी इनपुट संख्याओं के रूप में गिना जाता है। आईपी ​​​​एड्रेस में 4 नंबर, टेलीफोन नंबर, करेंसी, मेजरमेंट आदि होते हैं।

डिजिटबॉक्स, न्यूमरलबॉक्स, आदि सभी प्रकार हैं जो माइक्रोसॉफ्ट नामकरण शैली में बिल्कुल फिट नहीं हैं।

मानों का प्रकृति में संख्यात्मक होना भी आवश्यक नहीं है, इसलिए ValueBox थोड़ा भ्रामक भी हो सकता है।

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

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

क्या आप में से कोई मुझे आपके द्वारा विकसित किसी भी ऐप में एम्बेडेड कैलकुलेटर के लिए वास्तविक परिदृश्यों के साथ सक्षम कर सकता है? प्रसंग, स्क्रीनशॉट, उपयोगकर्ता प्रोफ़ाइल सभी मदद करते हैं। (यदि आप विवरण को गोपनीय रखना चाहते हैं तो मेरा ईमेल मेरे गिटहब प्रोफाइल पर भी है।) @xyzzer , @mrlacey , @robloo , @Felix-Dev, @adrientetar , और @ArchieCoder , कृपया अपने उपयोग परिदृश्य को साझा करने के लिए प्रोत्साहित महसूस करें यदि यह सुविधा आपके लिए भी रुचिकर है।

इस कदम से परे, केवल एक चीज जो इस सुविधा को बाधित कर सकती है, वह होगी कैलकुलेटर ऐप के इंजन के साथ WinUI के DLL आकार को बढ़ाने का जोखिम। मैं व्यवहार्यता का दायरा बढ़ाने के लिए इसे समानांतर में देखूंगा।

मैंने पहले केवल संख्यात्मक प्रकारों से अधिक के लिए इस नियंत्रण का इलाज

एक संख्या और एक स्ट्रिंग के बीच एक मूलभूत अंतर होता है जिसमें अंकों का क्रम होता है।

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

मुझे नहीं लगता कि कोई भी वास्तव में कोशिश करेगा और तर्क देगा कि एक आईपीवी 4 पता किसी अन्य परिभाषा द्वारा "संख्या" था, आमतौर पर अंकों के स्वरूपित अनुक्रम के रूप में प्रतिनिधित्व नहीं किया जाता है। वास्तव में यह सिर्फ 4 बाइट मान है।

@SavoySchuler

• शायद व्यय दर्ज करना - उन वस्तुओं को रसीद से दर्ज करना जहां कुछ आइटम व्यक्तिगत हैं, और अन्य काम का हिस्सा हैं।
• बिल को विभाजित करते समय रेस्तरां ऐप, या शायद टिप गणना?
• चयन को स्थानांतरित करने के लिए ऑफ़सेट मान की गणना करने के लिए हेक्स संपादन ऐप?

आईपी ​​​​पते का समर्थन करने वाला नियंत्रण मंच के लिए एक बढ़िया अतिरिक्त होगा लेकिन मुझे नहीं लगता कि नंबरबॉक्स इस परिदृश्य के लिए सही नियंत्रण है।

जैसा कि पहले उल्लेख किया गया है, नंबरबॉक्स नियंत्रण होगा:

• भौतिक कीबोर्ड के बिना डिवाइस पर उपयोग किए जाने पर Number वर्चुअल कीबोर्ड का उपयोग करें
• 2 बटन है -/+
• कैलकुलेटर के साथ एक पॉप-अप प्रदर्शित करें या उपयोगकर्ता को बुनियादी अंकगणितीय संचालन टाइप करने की अनुमति दें

इन सुविधाओं में से कोई भी आईपी पते के साथ समझ में नहीं आता है। यहां तक ​​कि नियंत्रण का डिजाइन भी बहुत अलग है।

इसके अलावा, हमें यह ध्यान रखना चाहिए कि यदि हम IPv4 पतों का समर्थन करते हैं, तो हमें IPv6 पतों का भी समर्थन करना चाहिए, अंकों का नहीं बल्कि हेक्साडेसिमल का।

मुझे लगता है कि इस नियंत्रण में आईपी पता समर्थन शामिल नहीं करना अधिक समझदारी होगी बल्कि इसके बजाय यूडब्ल्यूपी के लिए एक नए MaskedTextBox नियंत्रण पर काम करना (आईपीवी 4, आईपीवी 6, फोन नंबर, डाक कोड, एसएसएन, आदि का समर्थन करना ...) समुदाय टूलकिट (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask) से TextBoxMask को बदलने/सुधारने के लिए एक समृद्ध UI (@mdtauk द्वारा प्रदर्शित) के साथ

आईपी ​​​​पते का समर्थन करने वाला नियंत्रण मंच के लिए एक बढ़िया अतिरिक्त होगा लेकिन मुझे नहीं लगता कि नंबरबॉक्स इस परिदृश्य के लिए सही नियंत्रण है।

जैसा कि पहले उल्लेख किया गया है, नंबरबॉक्स नियंत्रण होगा:

• भौतिक कीबोर्ड के बिना डिवाइस पर उपयोग किए जाने पर Number वर्चुअल कीबोर्ड का उपयोग करें
• 2 बटन है -/+
• कैलकुलेटर के साथ एक पॉप-अप प्रदर्शित करें या उपयोगकर्ता को बुनियादी अंकगणितीय संचालन टाइप करने की अनुमति दें

इन सुविधाओं में से कोई भी आईपी पते के साथ समझ में नहीं आता है। यहां तक ​​कि नियंत्रण का डिजाइन भी बहुत अलग है।

इसके अलावा, हमें यह ध्यान रखना चाहिए कि यदि हम IPv4 पतों का समर्थन करते हैं, तो हमें IPv6 पतों का भी समर्थन करना चाहिए, अंकों का नहीं बल्कि हेक्साडेसिमल का।

लगता है कि इस नियंत्रण में IP पता समर्थन शामिल नहीं करना अधिक समझदारी होगी, बल्कि इसके बजाय UWP के लिए एक नए MaskedTextBox नियंत्रण पर काम करना (IPv4, IPv6, फ़ोन नंबर, पोस्टल कोड, SSN, आदि का समर्थन करना...) एक समृद्ध UI (जैसा कि @mdtauk द्वारा प्रदर्शित किया गया है) और सामुदायिक टूलकिट से TextBoxMask को बदलना/सुधारना (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn मैं ज्यादातर आपके द्वारा यहाँ कही गई बातों से सहमत हूँ, और मेरे चित्र प्रस्तावित युक्ति के लिए थे।

लेकिन जैसा कि दूसरों ने उल्लेख किया है, एक नकाबपोश टेक्स्ट बॉक्स को केवल अंकों तक ही सीमित नहीं होना चाहिए, और इसमें स्ट्रिंग भी शामिल हो सकती है। Microsoft उत्पाद कुंजी बॉक्स एक अच्छा उदाहरण है, जहाँ 0-9 AZ वर्णों के 5 सेट स्वीकृत हैं।

भले ही मास्किंग को अलग कर दिया गया हो, फिर भी मुझे लगता है कि प्रीफिक्सटेक्स्ट और प्रत्यय टेक्स्ट गुणों को नंबरबॉक्स नियंत्रण में शामिल करने के लिए अच्छे उपयोग के मामले हैं। मुद्रा, माप, सभी को किसी न किसी संदर्भ की आवश्यकता होती है।

स्पिन बटन विशुद्ध रूप से मूल्यों को बढ़ाने और घटाने के लिए हैं, इसलिए वे भी नंबरबॉक्स नियंत्रण के दायरे में हैं।

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

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

SW1A 2AA

उदाहरण यूके पोस्टकोड (नंबर 10 डाउनिंग स्ट्रीट के लिए)

ऐसा प्रतीत होता है कि मैं अपना उत्तर भेजने से पहले आज सुबह पृष्ठ को रीफ्रेश करने में सफल नहीं हुआ... इस प्रस्ताव को एक नए स्तर पर ले जाने के लिए आप सभी रॉकस्टारों को धन्यवाद! मुझे पता है कि GitHub पर शब्दों का अत्यधिक उपयोग किया जाता है, लेकिन मेरा मतलब है!

@mdtauk - आपके मॉक अप शानदार हैं। मैंने अभी तक इस नियंत्रण के लिए प्रोटोटाइप डिजाइन तैयार नहीं किए थे। क्या मैं आपके मॉक को तोड़ सकता हूं और उन्हें हमारे डिजाइनरों के लिए अपने पैलेट को शुरू करने के लिए प्रोटोटाइप के रूप में जोड़ सकता हूं? मैं आज एक डिजाइनर तक पहुंचूंगा और अनुरोध करूंगा और देखूंगा कि क्या मैं उन्हें यहां

@sonnemaf , फिर से धन्यवाद! मैं आपको अपनी टिप्पणी की प्रतिलिपि बनाने और इसे पुल अनुरोध के वार्तालाप टैब पर यहां दोबारा पोस्ट करने के लिए प्रोत्साहित करूंगा। यहीं से हमारी इंजीनियरिंग टीम एपीआई और कार्यान्वयन स्तर पर काम करना शुरू करेगी। एक व्यापक उत्तर देने के लिए, यहीं से मैं दिशा-निर्देशों और दस्तावेज़ीकरण का मसौदा तैयार करना शुरू करता हूं। मैं पूर्व के लिए [DEV] और बाद वाले के लिए [PM] के साथ कमिट की प्रस्तावना करूंगा। अन्यथा, यह अभी भी उच्च-स्तरीय आवश्यकताओं की चर्चा (जैसे एम्बेडेड कैलकुलेटर और @mdtauk के नकली अप) के लिए सही मंच है।

@mdtauk : मैं TextBox लिए एक अच्छा अतिरिक्त होगा और संख्याओं तक सीमित नहीं होगा, कुछ उदाहरण:

• किसी कर्मचारी को अपना ईमेल पता दर्ज करने के लिए कहें जब डोमेन हमेशा एक जैसा हो (उदाहरण के लिए @microsoft.com)।
• किसी फॉर्म का नाम दर्ज करें जब वह हमेशा W-

आदि...

आपको एक और टिकट खोलना चाहिए ताकि हम इसके बारे में चर्चा शुरू कर सकें!

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

@SavoySchuler मेरे डिजाइन पूरी तरह से आपके निपटान में हैं, मैंने उन्हें योगदान देने वाले सभी के लिए नियंत्रण की कल्पना करने में मदद करने के लिए पोस्ट किया है।

@rudyhuyn यदि आप एक मास्कड टेक्स्टबॉक्स या स्वरूपित टेक्स्टबॉक्स के लिए एक प्रस्ताव पोस्ट करते हैं, तो इसमें अधिक भार हो सकता है! नंबरबॉक्स की तरह मैं अपने किसी भी डिजाइन को इस तरह के प्रस्ताव में शामिल करने के लिए खुश हूं, और आपकी आवश्यकता के अनुसार और उदाहरण बना सकता हूं।

@mrlacey टेलीफोन नंबर (स्वरूपण वर्णों के अलावा) शुद्ध संख्याएं हैं - लेकिन वे किसी भी प्रकार के गणना उपयोग के मामले में नहीं आते हैं, तो क्या यह एक नकाबपोश टेक्स्टबॉक्स में बेहतर फिट बैठता है, या नंबरबॉक्स में इनके लिए समर्थन प्रदान करने में कोई मूल्य है?

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

@mrlacey : मैं नहीं।

जैसा कि आपने पहले कहा था, हमें वास्तविक संख्याओं को अलग करना चाहिए, न केवल 0-9 वर्णों का उपयोग करके बल्कि अंकगणितीय मान से संबंधित।

एक आईपी पता, फोन नंबर, एसएसएन, ज़िपकोड 0-9 वर्णों का उपयोग करता है लेकिन कोई अंकगणितीय मान नहीं है (आप उनमें से 2 जोड़ सकते हैं, यदि आप अंत में ".00" जोड़ते हैं तो आप मूल्य का अर्थ बदलते हैं, आदि ..) . इन मामलों में, मान एक स्ट्रिंग है, इंट/डबल नहीं, एक मास्कड टेक्स्टबॉक्स अधिक समझ में आता है।

इसके अलावा, एक ज़िपकोड केवल यूएस में अंकों का उपयोग करता है, लेकिन कनाडा में नहीं उदाहरण के लिए, एक आईपीवी 6 पते में एएफ वर्ण हो सकते हैं, एक फोन नंबर में एक + चिह्न हो सकता है (555-123-4567 और +555-123-4567 2 अलग हैं फोन नंबर), आदि ...

मेरी राय को संक्षेप में प्रस्तुत करने के लिए, NumberBox.Value एक डबल होना चाहिए, न कि एक स्ट्रिंग।

@mrlacey टेलीफोन नंबर (स्वरूपण वर्णों के अलावा) शुद्ध संख्याएं हैं - लेकिन वे किसी भी प्रकार के गणना उपयोग के मामले में नहीं आते हैं, तो क्या यह एक नकाबपोश टेक्स्टबॉक्स में बेहतर फिट बैठता है, या नंबरबॉक्स में इनके लिए समर्थन प्रदान करने में कोई मूल्य है?

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

यह नियंत्रण उन मानों तक सीमित होना चाहिए जिन्हें जानकारी खोने के जोखिम के बिना एक int/uint या दशमलव में परिवर्तित किया जा सकता है।

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

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

@SavoySchuler संख्याएं जिन्हें संचालित किया जा सकता है, वृद्धि और कमी, साथ ही उपसर्ग और प्रत्यय जो मूल्य में संदर्भ और अर्थ जोड़ते हैं।

मैंने अभी यहां टीम के साथ समन्वय किया है और हमारे कुछ खुले प्रश्नों पर अपडेट साझा करना चाहता हूं:

• हम आपकी प्रतिक्रिया सुन रहे हैं और हम सहमत हैं कि नंबरबॉक्स संख्यात्मक स्ट्रिंग्स के लिए सही जगह नहीं है। फ़ॉर्मेटकिंड्स और कस्टमफ़ॉर्मेट गुणों को अधिक विशिष्ट एपीआई के साथ बदल दिया गया है ताकि संख्या प्रारूप को अधिक सहज तरीकों से नियंत्रित किया जा सके।
• उपसर्ग और प्रत्यय वास्तव में टेक्स्टबॉक्स से संबंधित हैं (जिसमें से नंबरबॉक्स उन्हें प्राप्त करेगा)। मैं @mdtauk , @mrlacey , या किसी और को कुछ दिनों के लिए सुविधा अनुरोध का प्रस्ताव देना शुरू कर दूंगा अन्यथा मैं इसे शुरू कर दूंगा और इसे यहां लिंक कर दूंगा। कुछ समय के लिए, यह नंबरबॉक्स को स्थानीयकरण/स्वचालन आउटपुट पर अवरुद्ध होने से बचाएगा।
• नंबरबॉक्स में अंतिम फ़ीड (गणना, गोलाई, आदि के बाद) को टेक्स्ट प्रॉपर्टी में एक स्ट्रिंग के रूप में संरक्षित किया जाएगा जो टेक्स्टबॉक्स से बाहर आती है और एक नई वैल्यू प्रॉपर्टी में डबल के रूप में। हम इन फीडबैक को एक दूसरे को देना चाहते हैं ताकि एक में परिवर्तन दूसरे में परिलक्षित हो। इसका उद्देश्य यह है कि जितना संभव हो उतना काम अपने हाथों से हटा लिया जाए और आपकी जरूरत के अनुसार मूल्य को एक्सेस करने के लिए तैयार किया जाए।
• StepSize कल्पना पर एक संपत्ति के रूप में गायब था।
• पूर्णांक प्रकार को डबल में बदल दिया जाएगा।
• हम अभी भी एक एम्बेडेड कैलकुलेटर के विचार के लिए सम्मोहित हैं और इसे परिष्कृत करने में हमारी मदद करने के लिए और अधिक परिदृश्यों की तलाश कर रहे हैं। @mdtauk , प्रतिक्रिया के इस बिंदु पर पहले से ही प्रतिक्रिया देने के लिए धन्यवाद!
• इनपुट सत्यापन के संबंध में, विचार यह है कि पहले एक ValueChanged प्रकार की घटना भेजें जो डेवलपर को इनपुट में हेरफेर करने या आवश्यकतानुसार अपने अंत/ब्लॉक फॉर्म सबमिशन पर इसे संभालने का अवसर देगी। यदि कोई सुधारात्मक कार्रवाई नहीं की जाती है (जैसे इसे न्यूनतम/अधिकतम के भीतर जबरदस्ती करना, अमान्य वर्णों को हटाना, आदि), तो नंबरबॉक्स इसके बजाय उपयोगकर्ता को उनके इनपुट के बारे में एक त्रुटि संकेत प्रदर्शित करेगा। यह दो-तरफा दृष्टिकोण डेवलपर्स को प्रतिक्रिया देने के लिए देता है यदि वे पसंद करते हैं, लेकिन उपयोगकर्ता को सुधार को स्थगित करने की भी अनुमति देता है।

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

"एक एम्बेडेड कैलकुलेटर के साथ नंबरबॉक्स की अवधारणा कला।" विनयूआई समुदाय, मई 2019। (रंगीन)

( @ryandemopoulos की

@SavoySchuler आपने कुछ परिदृश्य उदाहरण मांगे हैं जहां हम जिस प्रकार के नियंत्रण पर चर्चा कर रहे हैं उसका उपयोग किया जा सकता है। मेरे पास मेरे ऐप में दो हैं जो अच्छे उदाहरण हो सकते हैं।

केस 1: 2D ग्राफ़ के लिए एक सेटिंग संपादक है जहाँ आप अक्ष को समायोजित कर सकते हैं।

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

केस 2: मुद्रा मूल्य के लिए एक इनपुट फ़ील्ड है जैसा कि नीचे दिखाया गया है। यह एक कस्टम नियंत्रण "मुद्राबॉक्स" है

• यह एक कैलकुलेटर बटन का उपयोग कर सकता है और समीकरण 2+3 दर्ज करने की क्षमता का यहां कुछ मूल्य होगा (मुझे अभी भी लगता है कि यह एक अलग नियंत्रण होना चाहिए)
• एक दोहरा मान इसके लिए आदर्श नहीं है। मैं इस प्रकार के उपयोग के मामले का समर्थन करने के लिए मान को डबल से दशमलव में बदलने का सुझाव दूंगा । अन्यथा, यह स्ट्रिंग टेक्स्ट को पार्स करने के लिए डेवलपर पर निर्भर है।
• यहां एक विशेष मामला है जहां नकारात्मक चिह्न को अलग से संभाला जाता है। इससे उपयोगकर्ता के लिए साइन पर गलती न करना बहुत आसान हो जाता है। मैं वास्तव में उम्मीद नहीं करता कि नंबरबॉक्स बॉक्स के बाहर इसका समर्थन करेगा।
• टेक्स्ट संरेखण सेट करने के लिए महत्वपूर्ण है और एक उपसर्ग/प्रत्यय मुद्रा प्रतीक दिखाने के लिए बेहद उपयोगी होगा (स्थानीयकरण अभी भी संभावित रूप से एक मुद्दा होगा कि प्रतीक को दाएं या बाएं दिखाना है या नहीं, हालांकि, ऐप में वह तर्क हो सकता है)
• उपयोगकर्ता एक विदेशी या स्थानीय मूल्य दोनों दर्ज कर सकता है। उन दोनों मूल्यों के लिए NumberFormatInfo और CultureInfo UI संस्कृति से भिन्न हो सकते हैं। इसलिए, स्थानीयकरण के लिए नियंत्रण को कस्टम NumberFormatInfo को ओवरराइड करने का समर्थन करना चाहिए।

अभी ऐप में विंडोज कम्युनिटी टूलकिट का उपयोग नीचे दिए गए टेक्स्टबॉक्स में संलग्न गुणों के साथ दोनों मामलों के लिए किया जाता है:
TextBoxRegex.ValidationMode = "डायनामिक"
TextBoxRegex.ValidationType = "दशमलव"

कुछ अंतिम टिप्पणियाँ (क्षमा करें, यह इतना लंबा है!)

• मुझे लगता है कि हम यहां संभावित रूप से 3 अलग-अलग नियंत्रणों पर चर्चा कर रहे हैं। एक बार-बोन नंबरबॉक्स, एक कैलकुलेटरबॉक्स जिसमें समीकरण और उन्नत संख्यात्मक इनपुट (कैलकुलेटर बटन!) हो सकते हैं, और अंत में फोन नंबर और आईपी पते जैसे गैर-संख्यात्मक इनपुट के लिए एक मास्कड टेक्स्टबॉक्स। हमें उन्हें भ्रमित नहीं करना चाहिए और इस बात पर सहमत होना चाहिए कि इन अवधारणाओं को कैसे अलग किया जाए, यह कल्पना के साथ आगे बढ़ने की कुंजी है।
• हम सबसे बुनियादी और तर्कसंगत रूप से सबसे उपयोगी उपयोग-मामले पर ध्यान केंद्रित नहीं कर सकते हैं: एक सामान्य दिखने वाला टेक्स्टबॉक्स इनपुट फ़िल्टरिंग से ज्यादा कुछ नहीं है, इसलिए केवल एक वैध संख्या इनपुट हो सकती है। अन्य सभी विकल्पों को बंद करने में सक्षम होना चाहिए (मैं वेतन वृद्धि +/- बटन के बारे में सोच रहा हूं)
• मैं अभी भी पार्स किए गए मान में दशमलव परिशुद्धता को सटीक रूप से कैप्चर करने के लिए डबल से दशमलव में बदलने का सुझाव देता हूं। इसके अतिरिक्त, हमें संभवतः पूर्ण संख्या इनपुट को परिमेय संख्या इनपुट से भिन्न मानना ​​चाहिए। यह शायद दशमलव डिफ़ॉल्ट से बदलने के लिए एपीआई "IsInteger = true" में एक नई संपत्ति है।

संपादित करें: NumberBox.Value प्रकार के लिए डबल से दशमलव में स्विच करने के लिए हटाए गए विचार। मैं इसे सी ++ विनआरटी दुनिया में मौजूदा मानने में गलत था। यह नहीं है, और इसके बजाय केवल .net core/framework में है।

@robloo , उस अंतिम टिप्पणी के बारे में, WinRT में कोई दशमलव प्रकार नहीं है।

एक्सएएमएल टूलकिट का विजुअल ट्री डिबगर एक ऐसा उपकरण है जो टूलकिट के न्यूमेरिकअपडाउन नियंत्रण पर बहुत अधिक निर्भर करता है जहां माउस ड्रैग, बटन, कीबोर्ड के साथ बढ़ाना/घटाना सभी महत्वपूर्ण हैं। कैलकुलेटर इनपुट भी मदद कर सकता है:

@robloo और @xyzzer , यह ठीक उसी तरह की जानकारी

सत्यापन/मास्किंग

@robloo , मुझे विशेष रूप से केस 1 में दिलचस्पी है: बुलेट 2 - सत्यापन बनाम मास्किंग। आइए अब तक "खराब इनपुट" के परिदृश्य के बारे में बात करते हैं:

• एक नया उपयोगकर्ता आपके नंबरबॉक्स में "दो" टाइप करता है।
• नंबरबॉक्स "ValueChanged" ईवेंट को बढ़ाता है जो आपको गैर-संख्यात्मक इनपुट को "0" पर वापस करने का अवसर देता है - या अन्यथा - यदि आप ऐसा चुनते हैं। कार्रवाई नहीं हुई तो...
• नंबरबॉक्स में सत्यापन लाल हो जाता है और उपयोगकर्ता को एक त्रुटि संदेश देता है जो उन्हें सूचित करता है कि केवल संख्यात्मक इनपुट की अनुमति है (इस हिस्से को वास्तव में अभी तक पूरी तरह से तर्कसंगत नहीं बनाया गया है, इसलिए यह केवल एक काल्पनिक है)।

क्या घटनाओं की यह श्रृंखला आपको वह अनुभव बनाने की क्षमता देती है जिसकी आपको आवश्यकता है?

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

आपके यहाँ क्या विचार हैं? मुझे इन अवधारणाओं को आगे शामिल करने या यदि हम कर सकते हैं तो और भी बेहतर अनुभव बनाने के लिए आपके किसी भी विचार में दिलचस्पी होगी।

मूल्य स्वरूपण

आपके अन्य बिंदुओं के लिए, @robloo , मैंने Spec में DecimalPrecision सटीक गुण जोड़ा है। इसे = "0" सेट करने से पूर्ण संख्याएँ प्राप्त होंगी। इसके अतिरिक्त, MinValue="0" को सेट करने से संख्याओं को गैर-ऋणात्मक रखने में मदद मिल सकती है (या ValueChanged ईवेंट इनपुट को निरपेक्ष मानों के लिए बाध्य करने का एक और अवसर है)।

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

मास्किंग, अंतिम उपयोगकर्ताओं के लिए निराशाजनक और भ्रमित करने वाला हो सकता है, जब उन्हें अपनी कीबोर्ड प्रविष्टि से कोई आउटपुट नहीं मिलता है।

100% सहमत हाँ। करने के लिए बेहतर बात यह है कि यदि टाइप किया गया मान मान्य नहीं होता है, तो LosingFocus/EnterPressed पर मान्य करें और पुराने वैल्यू को पुनर्स्थापित करें, यही कारण है कि एक सिग्नल जो LosingFocus/EnterPressed पर ट्रिगर होता है और इसमें oldValue/newValue शामिल होता है।

@adrientetar , बढ़िया बिंदु! क्या यह एक ऐसा अनुभव है जिसे आपको बनाने की आवश्यकता है? यदि ऐसा है, तो मैं देखूंगा कि ValueChanged ईवेंट पुराने मान और नए मान दोनों को भेजने के लिए हमें क्या करने की आवश्यकता है।

@SavoySchuler यह ऐसा कुछ है जो मैं वास्तव में अपने ऐप में करना चाहता हूं, मैं उस व्यवहार को स्वयं

दूसरी चीज जो मैं चाहता हूं वह है Shift+↑/↓ १० की वृद्धि के लिए और Ctrl+Shift+↑/↓ १०० की वृद्धि के लिए, हालांकि मुझे लगता है कि १०० की वृद्धि हमेशा समझ में नहीं आती है।

बढ़िया बिंदु! हमें यह सुनिश्चित करना चाहिए कि नियंत्रण रेंजबेस से प्राप्त होता है जो
स्मॉलचेंज और लार्जचेंज दोनों को परिभाषित करता है और हम इन दोनों का उपयोग करते हैं
सबसे कम।
क्या इनवोक करने के लिए उपयोग करने के लिए मानक कीबोर्ड संयोजनों का एक उदाहरण है
UWP के RangeBase या WinForms/ComCtl(?) NumericUpDown में बड़ा बदलाव?

सोम, जून ३, २०१९ अपराह्न ३:५० बजे एड्रियन टेटर नोटिफिकेशन @github.com
लिखा था:

@SavoySchuler https://github.com/SavoySchuler यह कुछ ऐसा है जो मैं चाहता हूं
वास्तव में मेरे ऐप में करें, मैं उस व्यवहार को तब तक बनाउंगा जब तक कि नियंत्रण न हो
यह डिफ़ॉल्ट रूप से।

दूसरी चीज जो मैं चाहता हूं वह है Shift+↑/↓ 10 और . की वेतन वृद्धि के लिए
Ctrl+Shift+↑/↓ १०० की वृद्धि के लिए, हालांकि मैं १०० की वेतन वृद्धि की गणना करता हूं
हमेशा होने का कोई मतलब नहीं है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVB2#47BWZLNMVXH
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

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

बिल्ड 2018 तब था जब INotifyDataErrorInfo का उपयोग करके टेक्स्टबॉक्स नियंत्रणों के लिए सत्यापन राज्यों की घोषणा की गई थी।
वर्तमान टेक्स्ट स्ट्रिंग को मान्य या अमान्य करने के लिए मास्किंग के साथ उपयोग करना अच्छा होगा।

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

@mdtauk आप इन मार्क अप में अभूतपूर्व हैं। मैं इन्हें हमारे डिजाइनर द्वारा चलाऊंगा, वे मुझे बहुत अच्छे लगते हैं!

बिल्ड 2018 में दिखाए गए उदाहरण के आधार पर @SavoySchuler आसान एक्सट्रपलेशन

और देखने के लिए बहुत सारे उदाहरण हैं :)

क्षमा करें, यह एक और लंबा है!

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

मास्किंग, अंतिम उपयोगकर्ताओं के लिए निराशाजनक और भ्रमित करने वाला हो सकता है, जब उन्हें अपनी कीबोर्ड प्रविष्टि से कोई आउटपुट नहीं मिलता है।

100% सहमत हाँ। करने के लिए बेहतर बात यह है कि यदि टाइप किया गया मान मान्य नहीं होता है, तो LosingFocus/EnterPressed पर मान्य करें और पुराने वैल्यू को पुनर्स्थापित करें, यही कारण है कि एक सिग्नल जो LosingFocus/EnterPressed पर ट्रिगर होता है और इसमें oldValue/newValue शामिल होता है।

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

| शीर्षक | तस्वीर | टिप्पणी |
|----------|-----|---------------|
| UWP OneNote फ़ॉन्ट आकार प्रविष्टि | | कोई भी मान कीबोर्ड से इनपुट किया जा सकता है, यह स्वचालित रूप से मान्य होता है और खोए हुए फ़ोकस पर अंतिम मान्य मान पर रीसेट हो जाता है |
| डेस्कटॉप वर्ड फ़ॉन्ट आकार प्रविष्टि | | कोई भी मान कीबोर्ड से इनपुट किया जा सकता है, यह खोए हुए फ़ोकस पर स्वचालित रूप से मान्य होता है और अमान्य होने पर एक त्रुटि संदेश दिखाई देता है। [ओके] पर क्लिक करने पर अंतिम वैध मान पर रीसेट हो जाता है। |
| UWP OneNote 2D ग्राफ़ | | कीबोर्ड से कोई भी मान इनपुट किया जा सकता है। अमान्य मानों को केवल अनदेखा कर दिया जाएगा और गणना में उपयोग किया गया अंतिम मान्य इनपुट (खोए गए फ़ोकस पर मान्य नहीं है)। इंक्रीमेंट +/- बटन दबाने से अंतिम मान्य इनपुट का उपयोग करके वृद्धि होगी। |
| डेस्कटॉप शब्द आकार आकार प्रविष्टि | | कोई भी मान कीबोर्ड से इनपुट किया जा सकता है, यह खोए हुए फ़ोकस पर स्वचालित रूप से मान्य हो जाता है और खोए हुए फ़ोकस पर अंतिम मान्य मान पर रीसेट हो जाता है। |

तो मुझे लगता है कि मैंने अभी खुद को गलत साबित किया है जिसका मतलब है कि मुझे आपसे सहमत होना चाहिए!

साइड टिप्पणियाँ:

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

• एक नया उपयोगकर्ता आपके नंबरबॉक्स में "दो" टाइप करता है।
• नंबरबॉक्स "ValueChanged" ईवेंट को बढ़ाता है जो आपको गैर-संख्यात्मक इनपुट को "0" पर वापस करने का अवसर देता है - या अन्यथा - यदि आप ऐसा चुनते हैं। कार्रवाई नहीं हुई तो...
• नंबरबॉक्स में सत्यापन लाल हो जाता है और उपयोगकर्ता को एक त्रुटि संदेश देता है जो उन्हें सूचित करता है कि केवल संख्यात्मक इनपुट की अनुमति है (इस हिस्से को वास्तव में अभी तक पूरी तरह से तर्कसंगत नहीं बनाया गया है, इसलिए यह केवल एक काल्पनिक है)।
  क्या घटनाओं की यह श्रृंखला आपको वह अनुभव बनाने की क्षमता देती है जिसकी आपको आवश्यकता है?
  आपके यहाँ क्या विचार हैं? मुझे इन अवधारणाओं को आगे शामिल करने या यदि हम कर सकते हैं तो और भी बेहतर अनुभव बनाने के लिए आपके किसी भी विचार में दिलचस्पी होगी।

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

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

घटनाओं के संदर्भ में, मैं अभी भी पाठ परिवर्तनों को रद्द करने का अवसर प्राप्त करना चाहूंगा यदि कभी भी वह उपयोग मामला अधिक स्पष्ट हो जाता है। इसलिए, ValueChanged के अलावा, मैं इनपुट की तुलना और रद्द करने की अनुमति देने के लिए ValueChanged और TextChanging ईवेंट की अनुशंसा करता हूं। निश्चित रूप से एक OldValue और NewValue की आवश्यकता है, यह कम से कम हमें जरूरत पड़ने पर इसे वापस OldValue में बदलने की अनुमति देगा (हालांकि जब आप किसी ईवेंट के भीतर TextValue को संशोधित करते हैं तो UWP क्रैश करना पसंद करता है)।

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

@mdtauk इतनी जल्दी इतने अच्छे चित्र बनाना मानवीय रूप से संभव नहीं होना चाहिए :)

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

आईओएस एक "स्टेपर" नियंत्रण का उपयोग करता है, लेकिन पाठ प्रविष्टि अलग है, और कोई इनलाइन गणना नहीं है।

यहाँ कुछ और डिज़ाइन हैं जो मुझे मिले हैं

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

संपादित करें: वैकल्पिक रूपों के कुछ नकली अप जोड़े (लेकिन मुझे लगता है कि पहला विचार सबसे अच्छा है ...)

मैं +/- स्थान पर @mdtauk से सहमत हूं, पहला सबसे अच्छा है।

एक एक्सएएमएल कंट्रोल टेम्पलेट है ताकि उपयोगकर्ता (डेवलपर) हमेशा अन्य दो लेआउट के लिए एक कस्टम टेम्पलेट बना सके।

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

आप सत्यापन पर एक महान बिंदु लाते हैं ...

[१] प्रश्नकाल: क्या कोई एक सत्यापन प्रणाली के खिलाफ होगा जो स्वचालित रूप से अस्वीकार्य इनपुट को पिछले मान पर वापस लौटाता है, जबकि घटनाओं को उजागर करता है जो डेवलपर को इस व्यवहार को रद्द करने की अनुमति देगा और इसके बजाय यह तय करेगा कि त्रुटि संकेतक या संदेशों को क्या करना/उठाना है?

दृश्यमान रूप से, मैं आपके द्वारा पोस्ट किए गए उदाहरण में अपडाउनबटन को अलग करने की योग्यता देखता हूं। मेरा मानना ​​है कि @mdtauk और @sonnemaf डिफ़ॉल्ट के लिए सही रास्ते पर हैं। UpDownButtons की निकटता उनकी वास्तविक सुविधा है, चाहे कोई अलग-अलग (लेकिन दूर नहीं) इनपुट के आगे-पीछे के परिणाम का परीक्षण कर रहा हो या ओवरस्टेप्ड इनपुट को सही कर रहा हो। दूरी, जब तक कि बेहतर डिज़ाइन या कार्यक्षमता से मेल न हो, अनुभव में परिहार्य श्रम जोड़ने के लिए प्रतीत होता है और नियंत्रण के कार्यात्मक भाग के रूप में इसे स्पष्ट रूप से समूहीकृत करने के विरोध में उपसर्ग/प्रत्यय गुण/लेबलिंग के साथ स्पष्टता से समझौता भी कर सकता है, उदाहरण: $ [-] 192 [+]

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

मेरा सवाल तो है...

[२] प्रश्नकाल: क्या हमें अपडाउनबटन के साथ एक नंबरबॉक्स बनाने के लिए Xaml ControlTemplate पर भरोसा करना चाहिए (यानी, यह बॉक्स के बाहर समर्थन का औचित्य साबित करने के लिए पर्याप्त नहीं है) या क्या हमें यह निर्धारित करने के लिए एक संपत्ति शामिल करनी चाहिए कि क्या UpDownButtons सन्निहित दिखाई देते हैं बनाम जुदा?

मैं इस प्रश्न के लिए @chigy को पिंग

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

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

मैंने अपने 3 खुले प्रश्नों के साथ प्रस्ताव को अद्यतन किया है।

अवधारणा डिजाइन के लिए @mdtauk धन्यवाद!

@adrientetar मुझे खुशी है कि आपने इसे एक आवश्यकता के रूप में बताया। ऐसा लग रहा है कि शायद हमें इन तीन विन्यासों के लिए एक एनम की आवश्यकता है?

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

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

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

इसे अलग दिखाने के लिए AccentColor और विभिन्न फ़ॉन्ट वज़न का उपयोग करने के बारे में क्या?

बढ़िया लिंक, @mdtauk। मुझे लगता है कि अगर यह एक सड़क है तो हम नीचे जाते हैं, हम इसे एक एनम के साथ संभाल सकते हैं जिसमें [ऑटो, वर्टिकल, हॉरिजॉन्टल, डिटैच्ड] जैसे मूल्य हैं, जहां ऑटो क्षैतिज को पसंद करेगा जब तक कि कॉम्पैक्टनेस वर्टिकल को अनिवार्य नहीं करता। विचार?

इसके अलावा, मैंने छवि को अपडेट किया है! मुझे लगता है कि आप सही हैं कि ग्रे आउट टेक्स्ट एक संकेत की तरह दिख सकता है, जिसका पालन करने पर, "=" के कारण त्रुटि होगी।

बढ़िया लिंक, @mdtauk। मुझे लगता है कि अगर यह एक सड़क है तो हम नीचे जाते हैं, हम इसे एक एनम के साथ संभाल सकते हैं जिसमें [ऑटो, वर्टिकल, हॉरिजॉन्टल, डिटैच्ड] जैसे मूल्य हैं, जहां ऑटो क्षैतिज को पसंद करेगा जब तक कि कॉम्पैक्टनेस वर्टिकल को अनिवार्य नहीं करता। विचार?

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

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

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

@mdtauk मैं मानता हूं कि ऊपर/नीचे के प्रतीक सबसे अच्छे हैं। मैं सिर्फ इनपुट के विपरीत किनारों पर तीरों के साथ एक उदाहरण दिखाना चाहता था। जैसा कि पहले उल्लेख किया गया है कि यह सुनिश्चित करने में मदद करता है कि उपयोगकर्ता गलत को नहीं दबाता है जो कि टच-आधारित UI में लगभग अनिवार्य है। मैंने OneNote से जो उदाहरण दिया है, उसमें +/- प्रतीक हैं, लेकिन मुझे स्वयं प्रतीकों को अनदेखा करने के लिए जोड़ा जाना चाहिए था।

@SavoySchuler

[२] प्रश्नकाल: क्या हमें अपडाउनबटन के साथ एक नंबरबॉक्स बनाने के लिए Xaml ControlTemplate पर भरोसा करना चाहिए (यानी, यह बॉक्स के बाहर समर्थन का औचित्य साबित करने के लिए पर्याप्त नहीं है) या क्या हमें यह निर्धारित करने के लिए एक संपत्ति शामिल करनी चाहिए कि क्या UpDownButtons सन्निहित दिखाई देते हैं बनाम जुदा?

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

एनम मूल्यों के लिए, हमने कई राज्यों पर चर्चा की है और सामान्यीकरण करते हुए हम कुछ और जोड़ सकते हैं:

• अलग क्षैतिज : बाईं ओर नीचे तीर, दाईं ओर ऊपर तीर
• सेपरेटेड वर्टिकल : नीचे की ओर नीचे की ओर तीर, ऊपर की ओर ऊपर की ओर तीर
• बायां : बाईं ओर एक दूसरे के बगल में नीचे और ऊपर दोनों तीर (क्षैतिज अभिविन्यास में)
• दाएं: नीचे और ऊपर दोनों तीर एक दूसरे के बगल में दाईं ओर (क्षैतिज अभिविन्यास में)
• शीर्ष : शीर्ष पर एक दूसरे के बगल में नीचे और ऊपर दोनों तीर (ऊर्ध्वाधर अभिविन्यास में)
• नीचे : नीचे और ऊपर दोनों तीर नीचे एक दूसरे के बगल में (ऊर्ध्वाधर अभिविन्यास में)

यदि यह सब बहुत जटिल हो जाता है (जैसा कि यह जल्दी है) मुझे एक्सएएमएल में अपने स्वयं के उपयोग के मामलों के लिए नियंत्रण को फिर से टेम्पलेट करने में खुशी हो रही है।

बस एक और विचार को बाहर करने के लिए: अपडाउनबटन के लिए प्रतीक के अभिविन्यास को बदलने से कुछ समझ में आ सकता है [<] 123 [>] । इस अतिरिक्त जटिलता को अनदेखा करने के लिए स्वतंत्र महसूस करें, हालांकि निश्चित रूप से प्रति-ऐप के आधार पर इसे बहाल किया जा सकता है।

साथ ही, कुछ एक्सेसिबिलिटी चिंताओं को पहले से ही OneNote में संबोधित किया जा सकता है, जहां से मैंने उदाहरण निकाला था।

@robloo मुझे लगता है कि आपके द्वारा

नीचे मेरे विचार हैं

मुझे यह भी यकीन नहीं है कि टेक्स्ट फ़ील्ड के ऊपर बटन रखना अर्थपूर्ण रूप से समझ में आता है, जब आप बटन पर अपनी उंगली डाल रहे हों, तो संख्या को बदलते हुए देखना मुश्किल हो सकता है।

नियंत्रण में निर्मित प्रत्येक संयोजन के अराजक उपयोग की ओर ले जाएगा, और यदि आवश्यक हो तो उन सभी चीजों को पुन: टेम्पलेटिंग के साथ किया जा सकता है।

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

NumberBox.SpinButtonOrientation = SpinButtonOrientation.Horizontal  
NumberBox.SpinButtonOrientation = SpinButtonOrientation.Vertical  

बस एक त्वरित प्रश्न संभव सुझाव: सिद्धांत रूप में, एक संख्या बॉक्स में केवल एक संख्या बॉक्स में संख्याओं को दर्ज करने में सक्षम होना चाहिए। इन क्षेत्रों के लिए लिखित संख्याओं को पार्स करना और उन्हें वास्तविक संख्याओं में अनुवाद करना कितना कठिन होगा?

उदाहरण के लिए:
एक + दो = 3
तब्दील हो
1 + 2 = 3

या
एक जमा दो बराबर तीन
में अनुवाद करता है
1 + 2 = 3

यह सिर्फ एक विचार है।

बस एक त्वरित प्रश्न संभव सुझाव: सिद्धांत रूप में, एक संख्या बॉक्स में केवल एक संख्या बॉक्स में संख्याओं को दर्ज करने में सक्षम होना चाहिए। इन क्षेत्रों के लिए लिखित संख्याओं को पार्स करना और उन्हें वास्तविक संख्याओं में अनुवाद करना कितना कठिन होगा?

उदाहरण के लिए:
एक + दो = 3
तब्दील हो
1 + 2 = 3

या
एक जमा दो बराबर तीन
में अनुवाद करता है
1 + 2 = 3

यह सिर्फ एक विचार है।

यह समझ में आता है, अंग्रेजी के लिए। यह एक समस्या बन जाती है जब आपको उन स्ट्रिंग्स को अन्य भाषाओं के लिए अनुवाद और पार्स करने की आवश्यकता होती है। और एक पोलिश उपयोगकर्ता के बारे में क्या, जो अंग्रेजी शब्दों में टाइप कर रहा है?

जैसा कि अभी है, केवल अंकों के रूप 0-9, दशमलव, संख्या विभाजक और गणितीय संचालिका - पर चर्चा की गई है। लेकिन अन्य संख्या प्रणालियों को पूरा करने की आवश्यकता हो सकती है।

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

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

कथावाचक:
"पिक्सेल नंबरबॉक्स एक मूल्य के बिना"

उपयोगकर्ता:
"एक सौ अट्ठाईस पिक्सेल"

[१२८ _________ | पीएक्स]

उपयोगकर्ता:
"चौंसठ पिक्सेल जोड़ें"

[ १९२ _________ | पीएक्स]

कथावाचक:
"एक सौ निन्यानबे पिक्सेल"

[१] प्रश्नकाल: क्या कोई एक सत्यापन प्रणाली के खिलाफ होगा जो स्वचालित रूप से अस्वीकार्य इनपुट को पिछले मान पर वापस लौटाता है, जबकि घटनाओं को उजागर करता है जो डेवलपर को इस व्यवहार को रद्द करने की अनुमति देगा और इसके बजाय यह तय करेगा कि त्रुटि संकेतक या संदेशों को क्या करना/उठाना है?

यदि दर्ज किया गया पाठ अमान्य हो जाता है, तो मान को कुछ पुराने में क्यों बदला जाएगा? मुझे नहीं लगता कि "अंतिम पता अच्छा Value " बनाए रखने की कोशिश करना कुछ ऐसा है जिसके लिए नियंत्रण को जिम्मेदार होना चाहिए। नियंत्रण को एकल वर्तमान मान (या त्रुटि स्थिति) को संभालने दें और ऐप को ValueChanged ईवेंट के माध्यम से आवश्यकतानुसार किसी भी अतिरिक्त ऐतिहासिक प्रसंस्करण का ध्यान रखने दें।

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

@shaheedmalik , और उत्कृष्ट और सहज विचार। क्या आपने विशिष्टता की जांच की है? हमारे पास एक ValueChanged ईवेंट है जो आपको उस इनपुट को इंटरसेप्ट करने और टाइप की गई संख्याओं को अंकीय मानों में मैन्युअल रूप से पार्स करने की अनुमति देगा - ताकि यह एक संभावित अनुभव हो, खासकर यदि आपके मन में एक विशिष्ट भाषा है। नियंत्रण के डिफ़ॉल्ट V1 में वैश्विक भाषा पार्सर पकाने के लिए -

@mrlacey, तो आप समीक्षा @robloo के करने का मौका दिया था कि विंडोज भर में इस्तेमाल NumberBox समान नियंत्रण के के तुलनात्मक विश्लेषण ? इन क्षेत्रों को अंतिम मान्य, अंक-केवल इनपुट पर रीसेट करने के व्यवहार में वास्तव में सिस्टम व्यापक मिसाल है - जिसका अर्थ है कि या तो नियंत्रण या डेवलपर दिशानिर्देश इस पैटर्न को संरेखित करने के लिए दबाए जाएंगे। मेरा झुकाव मानक विंडोज अनुभव के अनुरूप इस नियंत्रण को संरेखित करने और आवश्यक विचलन के लिए एक एवेन्यू बनाने के लिए होगा, जो कि एक ऐसे व्यवहार को मानकीकृत करने के विपरीत है जो बाकी पारिस्थितिकी तंत्र से विचलित हो जाता है और इस प्रणाली को डिफ़ॉल्ट व्यवहार बनाने के लिए दिशानिर्देशों पर जोर देता है जैसा कि बाद वाला बना देगा आम मामले के लिए आसान और दक्षता। मैं असहमति को प्रोत्साहित करता हूं, इसलिए कृपया मुझे बताएं कि क्या आपको लगता है कि यह नियंत्रण में अनावश्यक जटिलता जोड़ता है या, शायद, हमें इस मिसाल का पुनर्मूल्यांकन करना चाहिए?

| शीर्षक | तस्वीर | टिप्पणी |
|----------|-----|---------------|
| UWP OneNote फ़ॉन्ट आकार प्रविष्टि | | कोई भी मान कीबोर्ड से इनपुट किया जा सकता है, यह स्वचालित रूप से मान्य होता है और खोए हुए फ़ोकस पर अंतिम मान्य मान पर रीसेट हो जाता है |
| डेस्कटॉप वर्ड फ़ॉन्ट आकार प्रविष्टि | | कोई भी मान कीबोर्ड से इनपुट किया जा सकता है, यह खोए हुए फ़ोकस पर स्वचालित रूप से मान्य होता है और अमान्य होने पर एक त्रुटि संदेश दिखाई देता है। [ओके] पर क्लिक करने पर अंतिम वैध मान पर रीसेट हो जाता है। |
| UWP OneNote 2D ग्राफ़ | | कीबोर्ड से कोई भी मान इनपुट किया जा सकता है। अमान्य मानों को केवल अनदेखा कर दिया जाएगा और गणना में उपयोग किया गया अंतिम मान्य इनपुट (खोए गए फ़ोकस पर मान्य नहीं है)। इंक्रीमेंट +/- बटन दबाने से अंतिम मान्य इनपुट का उपयोग करके वृद्धि होगी। |
| डेस्कटॉप शब्द आकार आकार प्रविष्टि | | कोई भी मान कीबोर्ड से इनपुट किया जा सकता है, यह खोए हुए फ़ोकस पर स्वचालित रूप से मान्य हो जाता है और खोए हुए फ़ोकस पर अंतिम मान्य मान पर रीसेट हो जाता है। |

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

@mrlacey आप भी सही हैं कि बूलियन एक

@adrientetar , आप लंबवत बटन के लिए हमारे प्राथमिक ग्राहक हैं। क्या आपके पास स्क्रीन के अंश या संदर्भ हैं जो मुझे आपके स्थान की कमी को बेहतर ढंग से समझने में मदद कर सकते हैं? @mdtauk ने मुझे पहले इस उत्तर के साथ सोचने पर

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

@SavoySchuler (अंतिम अच्छे मूल्य पर रीसेट करने के संबंध में) जैसा कि @robloo की समीक्षा में नियंत्रणों की तुलना में त्रुटि प्रबंधन और रिपोर्टिंग के लिए स्पेक नंबरबॉक्स में अधिक क्षमता जोड़ देगा, मैं उन क्षमताओं को और अधिक बनाना चाहता था।

इस पर विचार करो:

1. नंबरबॉक्स AllowsCalculations=True
2. मैन्युअल रूप से 1100 दर्ज करें और अगले नियंत्रण पर टैब करें
3. महसूस करें कि यह वह नहीं है जो दर्ज करना चाहता था
4. नियंत्रण पर वापस जाएं और "99 x 12" दर्ज करें
5. अगले नियंत्रण के लिए टैब और मान "1100" प्रदर्शित करने के लिए वापस आ जाता है ('x' '*' के समान नहीं है, इसलिए यह गणना चरण में विफल हो जाएगा। या किसी अन्य अमान्य गणना पर विचार करें जो विफल हो जाता है यदि 'x' होगा ' t दबाए जाने पर प्रदर्शित किया जाएगा।)
6. यह अब एक मान दिखाता है जो गणना का परिणाम नहीं है, कोई त्रुटि संदेश प्रदर्शित नहीं होता है, और दर्ज की गई राशि खो जाती है, इसलिए जो हुआ उसका कोई रिकॉर्ड नहीं है।

चरण 5 पर अगले नियंत्रण के लिए टैब होने पर मैं क्या करना चाहता हूं

• "99 x 12" Text मान रहता है
• त्रुटि स्थिति दिखाई गई है।
• ValueChanged ईवेंट ट्रिगर और पास हुआ (टेक्स्ट='99 x 12', OldValue=1100, NewValue=Double.NaN)
• उपयोगकर्ता तब देख सकता है कि कुछ गलत था
• उपयोगकर्ता पूरी राशि को फिर से दर्ज किए बिना समस्या को ठीक कर सकता है।
• यदि आवश्यक हो तो कोड/ऐप तर्क कुछ उपयुक्त करने में सक्षम है।

यदि प्रवेश पर स्वचालित रूप से अंतिम ज्ञात अच्छे मूल्य पर वापस जाना है:

• जब इसके अलावा किसी आवश्यक फ़ील्ड पर कोई मान दर्ज नहीं किया जाता है, तो क्या त्रुटि स्थिति का संकेत दिया जाएगा?
• क्या ValueChanged घटना के होने का मूल्य बहुत कम नहीं हुआ है क्योंकि यह कभी भी अमान्य स्थिति पर रिपोर्ट नहीं करेगा?

@SavoySchuler @mrlacey उन उदाहरणों को अन्य Microsoft ऐप्स में देख रहे हैं ...

किसी भी मोडल पॉप-अप से इंकार किया जाना चाहिए। इसके बजाय इसे नियंत्रण पर ही सत्यापन स्थिति द्वारा नियंत्रित किया जाना चाहिए।

छवि

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

इनपुटस्कोप: नंबर या फॉर्मूला नंबर?

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

मैं 'नंबर' के लिए वोट करता हूं

संख्या

सूत्र संख्या

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

बीटीडब्ल्यू टेक्स्टबॉक्स सामग्री लंबवत रूप से केंद्रित नहीं होगी, और यह वर्टिकलकंटेंट एलाइनमेंट = "सेंटर" के साथ है।

यह उस तरह के प्रॉपर्टी साइडबार के समान दिखता है जो पेंट 3D उपयोग करता है (जो पतली लाइटर सीमाओं के साथ अपने स्वयं के नियंत्रण स्टाइल का भी उपयोग करता है, और एक प्रत्यय संपत्ति की तरह दिखता है)

यदि ड्रैगिंग को लागू नहीं किया जाना है, तो आप हमेशा वही कर सकते हैं जो पेंट 3 डी ने किया था, और स्लाइडर को नंबरबॉक्स से बांध दिया था।

यह भी वैसा ही है जैसा Adobe अपने नियंत्रण में ड्रॉप डाउन स्लाइडर के द्वारा करता है।

@adrientetar आप वहां एक नंबरबॉक्स का अपना संस्करण कर रहे हैं। आपके टेक्स्टबॉक्स के टेक्स्ट में बेसलाइन संरेखण होगा, क्योंकि फोंट में अवरोही होगा जिसका हिसाब लगाने की आवश्यकता है।

नंबरबॉक्स के लिए नेत्रहीन केंद्रित वर्ण होने का मामला हो सकता है, लेकिन फिर ये नंबरबॉक्स एक मानक टेक्स्टबॉक्स या टेक्स्टबॉक्स व्युत्पन्न नियंत्रण जैसे कॉम्बोबॉक्स के बगल में रखे जाने पर संरेखित नहीं होंगे।

डिफ़ॉल्ट टेम्पलेट और शैलियाँ बनाते समय, आपको विभिन्न Windows.UI.Xaml.Documents.Typography गुणों पर विचार करना चाहिए...

• टाइपोग्राफी। केस सेंसिटिव फॉर्म
• टाइपोग्राफी। अंक संरेखण + टाइपोग्राफी। अंक शैली (सारणी आनुपातिक के लिए बेहतर हो सकती है)

@mrlacey , आप एक वैध तर्क देते हैं। @adrientetar की प्रतिक्रिया के आधार पर, निम्नलिखित परिदृश्य के बारे में क्या:

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

मैं आज दोपहर टीम के साथ चैट करूंगा ताकि यह सत्यापित किया जा सके कि निरंतर घटना फायरिंग/सत्यापन एक यथार्थवादी विचार है - अन्यथा हम किसी अन्य तरीके से सीमा में निर्माण कर सकते हैं।

@mdtauk , लेकिन मेरा मानना ​​​​है कि आप सत्यापन के दृश्य प्रतिनिधित्व पर अपने दावे के साथ सही हैं। @LucasHaines , क्या आप मुझे दोबारा जांच सकते हैं?

@jevansaks , क्या आप नीचे दिए गए इनपुटस्कोप पर विचार करने में सक्षम हैं?

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

मैं 'नंबर' के लिए वोट करता हूं

संख्या

सूत्र संख्या

@SavoySchuler इसे फिर से करें

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

ValueChanged ईवेंट केवल तभी सक्रिय होना चाहिए जब वास्तविक Value बदलता है, हर बार Text परिवर्तन पर नहीं।

जब तक कि उस व्यवहार को उसकी संबंधित संपत्ति द्वारा अक्षम नहीं किया जाता है

यह नई संपत्ति क्या है?

मुझे नहीं पता कि अंतिम ज्ञात अच्छे मूल्य पर वापस लौटने पर गलत मूल्यों और त्रुटि राज्यों के मुद्दे को और अधिक बार-बार होने वाली घटनाओं को कैसे संबोधित किया जाता है।
मुझे लगता है कि यह वास्तव में कैसा होगा यह समझने के लिए यहां कुछ प्रयोग की आवश्यकता है। (यदि केवल मुझे समय मिल सके ...)

संबंधित नोट पर।

मुझे लगता है कि मौजूदा TextChanged घटना TextBox से विरासत में मिली है, उपभोक्ता के लिए संशोधित नहीं की जाएगी। लेकिन TextChanging घटना के बारे में क्या? क्या यह वह जगह होगी जहां नया नियंत्रण विशिष्ट प्रसंस्करण किया जाता है? क्या कंट्रोल का कंज्यूमर इस इवेंट को भी हैंडल कर पाएगा?

सहमत - खोज के लायक लेकिन सबसे अच्छा परिहार्य। मैंने सत्यापन पर अनुभाग को संशोधित किया है और एक IsInvalidInputOverwrite संपत्ति जोड़ा है जो डिफ़ॉल्ट रूप से अक्षम है। निम्नलिखित के बारे में हर कोई क्या सोचता है:

• इनपुट जो गैर-संख्यात्मक फ़ोरमलिक है या न्यूनतम/अधिकतम मानों से अधिक है, इनपुट सत्यापन चेतावनी को ट्रिगर करेगा।
• डेवलपर ValueChanged या TextChanged ईवेंट को इंटरसेप्ट कर सकता है (जो बदली हुई प्रॉपर्टी और अपडेट किए जाने वाले को उजागर करता है) और इनपुट वैलिडेशन चेतावनी प्रदर्शित होने से पहले मैन्युअल रूप से अमान्य इनपुट में हेरफेर कर सकता है।
• IsInvalidInputOverwrite प्रॉपर्टी को सक्षम करने से अमान्य इनपुट इनपुट सत्यापन चेतावनी प्रदर्शित किए बिना अंतिम मान्य स्थिति में वापस आ जाएगा। उदाहरण के लिए, यदि IsInvalidInputOverwrite सक्षम है, StepSize=0.2, MaxValue=3.0, और मान 2.9 बढ़ा दिया गया है, 3.1 अमान्य के रूप में पंजीकृत होगा और इसे वापस 2.9 पर अधिलेखित कर दिया जाएगा।

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

जब आप अमान्य मान दर्ज करने का प्रयास करते हैं तो FWIW, Adobe Photoshop और Illustrator पिछले मान पर वापस आ जाते हैं। इसमें गणना व्यवहार है, लेकिन माप प्रत्यय की इकाई पाठ का हिस्सा है, जो स्वयं ही सत्यापन समस्याओं का कारण बन सकती है :)

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

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

cc @SavoySchuler

बहुत बढ़िया विचार, @ केविनटीएक्सवाई। अगर यहां हमारे किसी भी डेवलपर को ऐसा कुछ चाहिए, तो हम इसे जोड़ने पर विचार कर सकते हैं!

प्रश्न समय: क्या किसी के पास कोई वास्तविक ऐप परिदृश्य है जो हेक्साडेसिमल या बाइनरी के लिए समर्थन की आवश्यकता को उचित ठहराता है? अधिकतम/न्यूनतम मान लपेटना?

मैं देखना चाहता था कि ValuesWrap प्रॉपर्टी जैसी कोई चीज़ यहाँ समझ में आती है या नहीं।

हाँ, अगर आपको कोण संपत्ति पसंद है तो आप ३५९ → ० पर जाना चाहते हैं, मूल रूप से मॉड ३६०। मजेदार बात यह है कि मुझे अभी भी नियंत्रण को उप-वर्ग करना था (क्यूटी में था) क्योंकि मैक्सवैल्यू केवल समावेशी हो सकता है, इसलिए मैं ३५९ निर्दिष्ट कर सकता हूं या 360, लेकिन मैं वास्तव में 359.99 लिखने में सक्षम होना चाहता था लेकिन 360 नहीं (यानी मैं चाहता था <, ≤ नहीं)।

QSpinBox में उस उद्देश्य के लिए एक रैपिंग प्रॉपर्टी है https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

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

उदाहरण के लिए, यदि IsInvalidInputOverwrite सक्षम है, StepSize=0.2, MaxValue=3.0, और मान 2.9 बढ़ा दिया गया है, 3.1 अमान्य के रूप में पंजीकृत होगा और इसे वापस 2.9 पर अधिलेखित कर दिया जाएगा।

आप शायद उस मामले में MaxValue से जुड़ सकते हैं।

@SavoySchler @xyzzer @mrlacey मैंने ट्विटर पर देखा कि 20H1 में कुछ आ रहा है जो भविष्य कहनेवाला टेक्स्ट इनपुट प्रदान करता है।

यह उस पूर्वावलोकन पूर्णता सुविधा में हस्तक्षेप कर सकता है जिसके बारे में हमने बात की थी, और नंबरबॉक्स नियंत्रण में कुछ दबाने की आवश्यकता हो सकती है। ऐसा लगता है कि Win32 और XAML नियंत्रण में आ रहा है ...

https://twitter.com/thebookisclosed/status/1137012461616488448?s=20

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

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

public bool ShowPreviewResult { get; set; }

आप पूर्वावलोकन परिणाम क्यों दिखाएंगे? 🤔 ऐसा नहीं है कि उपयोगकर्ता परिणाम के आधार पर अपने सूत्र को बदल देगा, यदि वे परिणाम जानते हैं जो वे चाहते हैं तो वे इसे तुरंत टाइप करेंगे

आप पूर्वावलोकन परिणाम क्यों दिखाएंगे? परिणाम के आधार पर उपयोगकर्ता जो टाइप कर रहा है, उसे पसंद नहीं करेगा, यदि वे जानते हैं कि वे क्या चाहते हैं तो वे इसे सीधे टाइप करेंगे

नियंत्रण की विशेषताओं में से एक गणना में प्रवेश करने में सक्षम होना है, जैसे 32 * 4 जो 128 के रूप में हल होगा - पूर्वावलोकन सुविधा दिखाएगा कि जब नियंत्रण फोकस खो देता है या एंटर दबाया जाता है तो वह परिणाम क्या होगा।

@adrientetar अभी पूर्वावलोकन एक

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

@SavoySchuler "क्या किसी के पास कोई वास्तविक ऐप परिदृश्य है जो हेक्साडेसिमल या बाइनरी के लिए समर्थन की आवश्यकता को उचित ठहराता है?", एक उदाहरण WinUI का अपना ColorPicker नियंत्रण है। इसमें एक हेक्साडेसिमल इनपुट बॉक्स शामिल है। इसमें कई अन्य नंबर प्रविष्टि टेक्स्टबॉक्स भी शामिल हैं। नए नियंत्रण को मान्य करने के तरीके के रूप में नए नंबरबॉक्स नियंत्रण का उपयोग करने के लिए कलरपिकर को अपडेट करने की संभावना को देखने लायक हो सकता है। यदि नंबरबॉक्स ColorPicker के वर्तमान कार्यान्वयन को सरल बना सकता है, तो यह एक जीत होगी।

यदि टेक्स्ट बॉक्स के लिए पतली बॉर्डर स्टाइल @chigy और WinUI डिज़ाइन टीम के निर्णय लेने से पहले नहीं मिलती है - मैंने सोचा कि मुझे एक डिज़ाइन मॉक अप तैयार करना चाहिए जो टेक्स्ट बॉक्स डिज़ाइन के वर्तमान प्रस्तावों से मेल खाता हो।

@kmahone - सहमत हुए। जैसा कि आपने आज सुबह वाटर कूलर में उल्लेख किया है, टेक्स्टबॉक्स के अपने उदाहरणों को बदलकर ColorPicker से पीछे बहुत सारे कोड को हटाने में सक्षम होना + नंबरबॉक्स के साथ स्थानीय सत्यापन तर्क अपने आप में एक जीत हो सकती है।

@mdtauk - क्या मैंने आपको कई बार कहा है कि आपके नकली अप अविश्वसनीय लग रहे हैं? मैं इन्हें शीघ्र ही कल्पना में लाऊंगा!

@SavoySchuler यदि विंडोज़ डिज़ाइन टीम को फ़ैब्रिक वेब टीम के साथ जाने का निर्णय लेना था, और 2 एपेक्स मोटी सीमाओं से 1epx सीमाओं तक जाना था - मुझे लगता है कि यह नंबरबॉक्स के साथ सबसे अच्छा काम करेगा - लेकिन व्यावहारिक होने के कारण, विंडोज डिज़ाइन टीम खुदाई कर सकती है ऊँची एड़ी के जूते अंदर और मोटी सीमाओं को रखें।

ज़रूर, @mdtauk! मैं जल्द ही भविष्य में @KevinTXY के लिए कार्यात्मक आवश्यकताओं को बंद करने की उम्मीद कर रहा हूं और मैं @chigy (जो # 524 पर एक अद्भुत काम करने में व्यस्त रहा है) के साथ उस डिजाइन अभिसरण वार्तालाप पर

सभी चर्चाओं के लिए धन्यवाद, मैं इस गर्मी में एक प्रशिक्षु के रूप में इस सुविधा पर काम करने के लिए रोमांचित हूं!

यदि यह किसी के लिए प्रासंगिक है, तो मैंने निम्नलिखित भंडार पर नियंत्रण का सी # प्रोटोटाइप शुरू कर दिया है।
https://github.com/KevinTXY/NumberBox

यह अनिवार्य रूप से मेरा पहली बार C#/UWP सीख रहा है, इसलिए यह धीरे-धीरे साथ आएगा और यदि कोई इसे देखता है तो मुझे इस पर प्रतिक्रिया प्राप्त करने में खुशी हो रही है कि क्या बेहतर किया जा सकता है!

निम्नलिखित विशेषताएं मोटे तौर पर लागू की गई हैं:

• संख्यात्मक इनपुट सत्यापन (अभी तक सत्यापन प्रस्ताव विनिर्देशों का पालन नहीं करता है, उसके लिए कोड पर प्रतीक्षा करेगा)
• मूल्य भंडारण / बाध्यकारी
• शून्य ट्रिमिंग
• पूर्ण कैलकुलेटर/सूत्र प्रविष्टि समर्थन

वर्तमान में स्पिनर बटन और परीक्षण ऐप सामग्री के साथ-साथ न्यूनतम/अधिकतम सत्यापन पर काम कर रहा है।

चीयर्स!

समयरेखा अद्यतन!

मैंने आज (गुरुवार) WinUI टीम के साथ मान्य किए गए कई अपडेट, सुझावों और फीडबैक के अंशों को उस युक्ति में एकीकृत किया है। मैं ऐसा करने में V1 के लिए एपीआई और व्यवहार घटकों को कमोबेश अंतिम रूप देने की उम्मीद कर रहा हूं।

अब, मैं इनपुट्स एंड एक्सेसिबिलिटी, डेटा एंड इंटेलिजेंस और विजुअल कंपोनेंट्स में आगे बढ़ूंगा।

अंतिम चरण दस्तावेज़ीकरण और दिशानिर्देश तैयार करना होगा।

मुझे लगता है कि असंबद्ध और सन्निहित विकल्प उपयोग के मामले के बिना बहुत विशिष्ट है कि माइक्रोसॉफ्ट के पहले पार्टी ऐप्स/खोल यूआई को या तो wpf या Win32 में करने की आवश्यकता है।

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

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

मैं एज के नवीनतम कैनरी बिल्ड को देख रहा था, और एक <input type="number"/> का डिज़ाइन देखा जो नंबरबॉक्स नियंत्रण के सबसे नज़दीक है।

बस मैंने सोचा कि मैं इसकी इस छवि को साझा करूंगा।

@mdtauk - सहमत, वैकल्पिक स्पिनबटन प्लेसमेंट विकल्प जोड़ने के लिए

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

@mdtauk -

@SavoySchuler मैं धाराप्रवाह नियंत्रण ध्वज सक्षम (प्रयोगात्मक नियंत्रण सहित) का उपयोग कर रहा हूँ

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

w3schools इनपुट प्रकार संख्या

साथ ही वह स्लाइडर करीब है, लेकिन बिल्कुल वैसा नहीं है जैसा कि WinUI करने की योजना है (उल्लिखित सर्कल थंब, भरे हुए सर्कल थंब की तुलना में)

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

उदाहरण:

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

<StackPanel Spacing="12" Padding="12" Width="200">
    <NumberBox Header="Dollar (US)"
               Value="1234.56"
               FractionDigits="2"
               Language="en-US" />
    <NumberBox Header="Euro (Netherlands)"
               Value="2345.67"
               FractionDigits="2"
               Language="nl-NL"/>
</StackPanel>

मैं एज के नवीनतम कैनरी बिल्ड को देख रहा था, और एक <input type="number"/> का डिज़ाइन देखा जो नंबरबॉक्स नियंत्रण के सबसे नज़दीक है।

बस मैंने सोचा कि मैं इसकी इस छवि को साझा करूंगा।

@mdtauk , @SavoySchuler ,
मुझे नहीं पता कि यह नियंत्रण कहां से आया। एज टीम में मेरे संपर्क के अनुसार, यहां वे नियंत्रण हैं जिनका वे उपयोग करेंगे।

स्लाइडर: https://explore.fastdna.net/components/slider/
नंबर बॉक्स: https://explore.fastdna.net/components/number-field/

मुझे यकीन नहीं है कि वे दृश्य को अपडेट करेंगे और अंतिम आउटपुट बिल्कुल इस तरह नहीं दिख सकता है (मुझे ऐसा लगता है, लेकिन यह मेरा जंगली अनुमान है)।

@chigy वह छवि एज के वर्तमान कैनरी बिल्ड से थी, लेकिन जैसा कि मैंने नोट किया है, यह एक डब्ल्यूआईपी है और यह एक वैकल्पिक ध्वज है जिसे आप चालू करते हैं।

मुझे लगता है कि यह बताता है कि वह फास्टडना परियोजना किस लिए है, जिसे मैंने पिछले अंक में लाया था। मैं

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

वे सेटिंग्स आमतौर पर "क्षेत्र" से आती हैं, इसलिए मुझे लगता है कि हम HomeGeographicRegion में DecimalFormatter कंस्ट्रक्टर को पास करेंगे। मुझे एपीआई में कोई अन्य स्थान नहीं दिख रहा है जहां हम उपयोगकर्ताओं को क्षेत्र को अनुकूलित करने की अनुमति देते हैं (हमारे दिनांक/समय स्वरूपक अनुकूलन योग्य नहीं लगते हैं?), लेकिन पिकर्स प्रारूप स्ट्रिंग को अनुकूलित करने की अनुमति देते हैं ताकि शायद हम अनुमति दे सकें कि यहाँ भी।

मुझे DecimalFormatter API में विभाजक वर्णों को अनुकूलित करने का कोई तरीका नहीं दिख रहा है, इसलिए उन्हें भाषा सेटिंग्स से खींचा जाना चाहिए। मैं

@jevansaks , अंतर्दृष्टि के लिए धन्यवाद! मैं यह सुनिश्चित करने के लिए @sonnemaf को टैग

@jevansaks क्या आप एक xaml उदाहरण लिख सकते हैं कि नंबरबॉक्स के लिए DecimalFormatter कैसे करें? मैं इसे एक्सएएमएल में परिभाषित करना चाहता हूं, न कि कोडबेंड से। DecimalSymbol और GroupingSymbol गुण होने से भी मेरे लिए काम होगा। हालांकि यह बहुत आसान हो सकता है।

<StackPanel Spacing="12" Padding="12" Width="200">
    <NumberBox Header="Dollar (US)"
               Value="1234.56"
               FractionDigits="2"
               DecimalSymbol="."
               GroupingSymbol="," />
    <NumberBox Header="Euro (Netherlands)"
               Value="2345.67"
               FractionDigits="2"
               DecimalSymbol=","
               GroupingSymbol="." />
</StackPanel>

* Does anyone have any real app scenarios that justify needing support for hexadecimal or binary?

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

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

क्या आप एक xaml उदाहरण लिख सकते हैं कि NumberBox के लिए DecimalFormatter कैसे करें? मैं इसे एक्सएएमएल में परिभाषित करना चाहता हूं, न कि कोडबेंड से। DecimalSymbol और GroupingSymbol गुण होने से भी मेरे लिए काम होगा। हालांकि यह बहुत आसान हो सकता है।

@sonnemaf हम सभी के साथ WinRT में काम करना है DecimalFormatter और दुर्भाग्य से यह आपको उन सेटिंग्स को अनुकूलित करने की अनुमति नहीं देता है। दशमलव प्रतीक या समूहीकरण प्रतीक को अनुकूलित करने का एकमात्र तरीका ओएस के क्षेत्र नियंत्रण कक्ष (जहां तक ​​​​मैं बता सकता हूं) में उपयोगकर्ता सेटिंग्स के माध्यम से है।

हालांकि उन सेटिंग्स के लिए उपयोगकर्ता के क्षेत्र का सम्मान करना सही लगता है - क्या आपके पास ऐसा परिदृश्य है जहां आपको उन्हें ओवरराइड करने की आवश्यकता है?

@sonnemaf

क्या किसी के पास कोई वास्तविक ऐप परिदृश्य है जो हेक्साडेसिमल या बाइनरी के लिए समर्थन की आवश्यकता को उचित ठहराता है?

क्षमा करें, मैंने इस पर ध्यान दिया और थोड़ी देर से उत्तर दिया। मेरा मानना ​​​​है कि हेक्स/बाइनरी सपोर्ट बहुत मददगार होगा। मैं .NET IoT प्रोजेक्ट से काफी जुड़ा हुआ हूं और हम ज्यादातर हेक्स/बाइनरी दुनिया में काम करते हैं क्योंकि हम बिट्स/बाइट्स में हेरफेर कर रहे हैं जो चीजों को नियंत्रित करने के लिए रजिस्टरों और पिनों को पढ़ते/लिखते हैं।

हेक्स/बाइनरी का समर्थन करना बहुत सराहनीय होगा। Thx

मुझे हेक्स या बाइनरी की आवश्यकता नहीं है। यह एक 'अच्छा होना' होगा, खासकर बाइनरी।

देव अद्यतन

हेलो सब लोग! हम नंबरबॉक्स स्पेक के साथ संतुष्ट हो रहे हैं, और मैं केवल इस बात पर ध्यान देना चाहता हूं कि

कुछ नोट:

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

@KevinTXY टेक्स्टबॉक्स के बजाय स्लाइडर बेस से प्राप्त करने का एक सुझाव था - क्या इसे चुना गया है?

• प्लेसहोल्डरटेक्स्ट
• हैडर
• मूलपाठ
• सत्यापन चिह्न
• सत्यापन संदेश
• चयन अग्रभूमि
• चयन पृष्ठभूमि
• फोकस राज्यों/संसाधनों, आदि

मुझे लगता है कि ये कुछ टेक्स्टबॉक्स चीजें हैं जिनकी मुझे आवश्यकता है। "स्पष्ट पाठ" बटन के बारे में निश्चित नहीं है, जो पाठ के लंबे तारों के साथ अधिक समझ में आता है।

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

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

@KevinTXY टेक्स्टबॉक्स के बजाय स्लाइडर बेस से प्राप्त करने का एक सुझाव था - क्या इसे चुना गया है?

NumberBox वर्तमान में इसका स्वयं का नियंत्रण है (Windows.UI.Xaml.Controls.Control का विस्तार करता है) जिसमें टेक्स्टबॉक्स को विस्तारित करने के बजाय इसके मार्कअप में टेक्स्टबॉक्स शामिल है। स्लाइडर दिलचस्प लगता है, लेकिन मुझे लगता है कि यह कार्यान्वयन को थोड़ा हैकी बना देगा, इन नियंत्रणों में बहुत सारी संपत्तियां भी हैं जो हमें नंबरबॉक्स में नहीं लगती थीं। मैं प्रधान मंत्री नहीं हूं, लेकिन इसे विकसित करने के अपने अनुभव से मुझे लगता है कि विकास को सरल बनाने और भविष्य में विस्तार के लिए यह एक अच्छा मार्ग है।

मुझे लगता है कि ये कुछ टेक्स्टबॉक्स चीजें हैं जिनकी मुझे आवश्यकता है। "स्पष्ट पाठ" बटन के बारे में निश्चित नहीं है, जो पाठ के लंबे तारों के साथ अधिक समझ में आता है।

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

मूल्य पूर्वावलोकन के लिए, वहां कुछ भी अंतिम रूप नहीं दिया गया है और यह केवल एक खुले प्रश्न के रूप में कल्पना में है। मुझे लगता है कि सबसे आसान अस्थायी समाधान यह होगा कि डेवलपर्स के लिए पूर्वावलोकन मूल्य को उनकी इच्छानुसार प्रदर्शित किया जाए - जो कि पूर्वावलोकन संस्करण के दायरे में आसानी से हो सकता है लेकिन मैं इसे कॉल करने के लिए @SavoySchuler & Co. के लिए छोड़

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

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

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

आह हाँ, रेंजबेस, वह था।

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

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

अद्यतन: एक कोड पीआर अब मौजूद है !

मैं वहां कुछ मुद्दों को ट्रैक कर रहा हूं, हालांकि अधिकांश डिजाइन से संबंधित नहीं हैं।

धन्यवाद, @xyzzer और @mdtauk! हमने रेंजबेस की जांच की है और ऐसा लगता है कि टेक्स्टबॉक्स को उप-वर्गीकरण के रूप में उतना ही सामान ले जाना है। अभी तक, हम नियंत्रण में टेक्स्टबॉक्स रखने और केवल आवश्यक गुण और एक्सेसिबिलिटी सुविधाओं को जोड़ने के साथ रहेंगे। यह अभी भी एक सार्थक विचार था और हमारी पहुंच-योग्यता बातचीत को सूचित करने में मदद करता है जो अभी हो रही है।

@mdtauk , शुरुआती सूची के लिए धन्यवाद! @KevinTXY ने आपके द्वारा सूचीबद्ध एपीआई को उजागर करना शुरू कर दिया है और मैं जल्द ही बाकी की समीक्षा करूंगा।

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

नामकरण

इतनी सारी टिप्पणियाँ थीं कि कल्पना मुझसे दूर हो गई है इसलिए मैं बस एक नज़र रखना शुरू कर रहा हूँ कि चीजें ठीक हो जाएँ। सबसे पहले, मैंने कुछ नामकरण देखा जो वास्तव में सी # सम्मेलन का पालन नहीं करते हैं - हाँ मुझे पता है कि ये नियंत्रण सी ++ में लिखे गए हैं लेकिन मुझे अभी भी लगता है कि यह मंच में अन्य नामकरण के साथ असंगत है।

| प्रकार | वर्तमान नाम | प्रस्तावित नाम |
|-------|----------------|-------------------|
| बूलियन | गणना स्वीकार करता है | गणना स्वीकृत |
| बूलियन | हाइपरड्रैग इनेबल्ड | IsHyperDragEnabled |
| बूलियन | हाइपरस्क्रॉल सक्षम | IsHyperScrollEnabled |

चरण आवृत्ति

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

उदाहरण के लिए MinValue = 0, MaxValue = 6, StepFrequency = 2. अप ऐरो वैल्यू का उपयोग करना {2, 4, 6} काफी उचित होगा। क्या उपयोगकर्ता 0.5 को वैध मान के रूप में टाइप कर सकता है? या राउंडिंगमोड के आधार पर इसे 0 या 2 तक गोल किया जाएगा?

न्यूनतम/अधिकतम मूल्य

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

अपडाउन रिपीट बटन

एक और विशेषता जिस पर चर्चा नहीं की गई है जहां तक ​​​​मुझे पता है कि ऊपर/नीचे बटन वास्तव में दोहराना बटन बनाना है (मुझे लगता है कि उन्हें होना चाहिए)। यदि वे दोहराए गए बटन हैं तो देरी/अंतराल गुणों को स्लाइडर नियंत्रण की तरह जोड़ा जाना चाहिए: स्लाइडर। अंतराल स्लाइडर । विलंब

अंक

क्या आप एक विवरण जोड़ सकते हैं कि IntegerDigits और FractionDigits क्या दर्शाते हैं? मेरा अनुमान है कि वे संख्या के प्रत्येक भाग के लिए अंकों की संख्या को सीमित करते हैं। IntegerDigits = 2 का अर्थ है कि अधिकतम मान 99 हो सकता है। FractionDigits = 3 का अर्थ है कि MaxValue 0.999 हो सकता है। साथ ही, महत्वपूर्ण अंक इन दो गुणों को कैसे ओवरराइड करता है?

नकारात्मक शून्य?

इस संपत्ति की आवश्यकता क्यों है? क्या यह अपने आप में स्थानीयकरण की बात है? मैंने कभी "-0.0" या "-0" नहीं देखा है। यह हमेशा "0" होता है।
बूलियन IsZeroSigned;

स्थानीयकरण

मैं दृढ़ हूं कि यूआई स्थानीयकरण और संख्या प्रारूप को ओवरराइड करने में सहायता के लिए मुझे इस नियंत्रण की आवश्यकता है। मेरे पास कई उपयोग (वित्तीय ऐप्स) हैं जहां मुझे स्थानीय और विदेशी राशियों की आवश्यकता होती है जिन्हें अलग-अलग प्रदर्शित किया जाना चाहिए। मैं इसे कल्पना में कहीं भी नहीं देखता।

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

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

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

एकमात्र जटिलता जो मैं देख रहा हूं वह नियंत्रण से संबंधित संस्कृति/संख्याफॉर्मैटइन्फो को रख रही है। मुझे लगता है कि यह कस्टम IValueConverter पर जाने वाले XAML में कनवर्टर पैरामीटर हो सकता है लेकिन इसे नियंत्रण में संभालने के लिए शायद एक क्लीनर तरीका होना चाहिए।

इस संपत्ति की आवश्यकता क्यों है? क्या यह अपने आप में स्थानीयकरण की बात है? मैंने कभी "-0.0" या "-0" नहीं देखा है। यह हमेशा "0" होता है।

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

मैं दृढ़ हूं कि यूआई स्थानीयकरण और संख्या प्रारूप को ओवरराइड करने में सहायता के लिए मुझे इस नियंत्रण की आवश्यकता है। मेरे पास कई उपयोग (वित्तीय ऐप्स) हैं जहां मुझे स्थानीय और विदेशी राशियों की आवश्यकता होती है जिन्हें अलग-अलग प्रदर्शित किया जाना चाहिए। मैं इसे कल्पना में कहीं भी नहीं देखता।

@SavoySchuler शायद हमें DecimalFormatter वर्ग में भाषा सेटिंग्स का समर्थन करना चाहिए? हालांकि मैं इससे परिचित नहीं हूं कि यह कैसे व्यवहार करता है।

ठीक है, मुझे लगता है कि मैं यहां मूलभूत समस्या को समझता हूं। सी ++ दुनिया में आपके पास DecimalFormatter तक पहुंच है लेकिन सी # दुनिया में (क्या मैं WinUI का उपभोग करता हूं) मैं आम तौर पर एक IFormatProvider (एक निर्दिष्ट संस्कृति से नंबरफॉर्मैटइन्फो) का उपयोग करता हूं। NumberFormatInfo में पहले से ही अधिकांश गुण हैं (संयोग से IsZeroSigned गायब है) इसलिए मैं सोच रहा था कि देवों को यह निर्दिष्ट करने की अनुमति दें या IFormatProvider। खैर, एक समस्या है, C++ एक IFormatProvider का उपयोग नहीं कर सकता क्योंकि यह .net दुनिया से है।

तो यह नियंत्रण सी # और सी ++ में स्थानीयकरण का पूरी तरह से समर्थन कैसे करता है क्योंकि उनके पास ऐसा करने के दो अलग-अलग तरीके हैं? ठीक है, जब तक कि माइक्रोसॉफ्ट के पास एक चतुर समाधान नहीं है, मैं केवल दो संभावनाओं के बारे में सोच सकता हूं:

1. संख्या स्वरूपण के लिए सभी गुणों को पूरी तरह से जोड़ें (NumberFormatInfo और DecimalFormatter को प्रभावी ढंग से पुन: कार्यान्वित करना)। सिर्फ IsZeroSigned, IntegerDigits, FractionalDigits, आदि को जोड़ने से इसे कवर नहीं किया जा सकता है। NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes, आदि सभी भी आवश्यक हैं।
2. जैसा कि @eugenegff ने सुझाव दिया है और

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

तो यह नियंत्रण सी # और सी ++ में स्थानीयकरण का पूरी तरह से समर्थन कैसे करता है क्योंकि उनके पास ऐसा करने के दो अलग-अलग तरीके हैं?

हम तुम्हें सुनते हैं! यह कुछ ऐसा है जिसकी हम ऑफ़लाइन जांच कर रहे हैं लेकिन मूल रूप से .NET प्लेटफॉर्म से अलग अपना स्थानीयकरण करता है। मुझे लगता है कि ओवरराइड करने के लिए कॉलबैक एक महान एस्केप हैच है, लेकिन मुझे आशा है कि आपका विकल्प 1 वह मार्ग है जिस पर हम जा सकते हैं। फिलहाल WinRT API में फॉरमेटिंग और पार्सिंग के लिए हमारे लिए आवश्यक सभी कस्टमाइज़ेशन नॉब्स नहीं हैं। हम अभी भी जांच कर रहे हैं।

जाँच नहीं की गई है कि क्या इस पर पहले ही चर्चा की जा चुकी है, लेकिन जल्दी से पूछना चाहता था कि क्या किसी को गणना के लिए फ़ंक्शन समर्थन के लिए एक बड़ी आवश्यकता या अधिक महत्वपूर्ण रूप से कोई मिसाल दिखाई देती है, जिसका अर्थ नीचे या अधिक में से कोई भी है:
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

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

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

एक ऑपरेटर के साथ टेक्स्ट में टाइप करना शुरू करने की अनुमति देने के लिए और अधिक मूल्यवान क्या होगा, इसलिए यदि आप टेक्स्ट पर क्लिक करते हैं - यह डिफ़ॉल्ट रूप से सभी का चयन करेगा और आप या तो एक नया मान टाइप कर सकते हैं बिना पिछले को हटाने के लिए पहले हटाएं दबाएं या बस "*1.2" या "x1.2" [Enter] जैसा कुछ टाइप करें और वर्तमान मान को 1.2 से गुणा करें, भले ही दर्ज किए गए टेक्स्ट में अब दर्ज किया गया मान न हो। वही बात "+2", "-5", "/3", "% 120", आदि के लिए काम करेगी।

इसका उपयोग कुछ पेशेवर अनुप्रयोगों में किया जाता है।

हमें (BeLight Software, Live Home 3D project) को मूल्य <=> पाठ रूपांतरण के लिए प्लग करने योग्य ValueConverter की आवश्यकता है, अन्यथा NumberBox हमारे लिए अनुपयुक्त होगा।

मुझे लगता है कि उन कार्यों का उपयोग बहुत दुर्लभ होगा, मेरे पास मेरे ऐप में कोण इनपुट है लेकिन यह सिर्फ एक डिग्री मान है। मेरे लिए सबसे महत्वपूर्ण उपयोग केवल समय बचाने के लिए और मानसिक रूप से उस गणना को करने से बचने के लिए मौजूदा या मौजूदा संख्या से विभाजित करने में सक्षम होना है। (बीटीडब्ल्यू मुझे लगता है कि एडोब ऐप्स में 4 अंकगणितीय ऑपरेटर हैं: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -खेत)

कॉस() ​​जैसे कार्य भी आप शायद इसे नहीं चाहते हैं जहां यह समझ में नहीं आता है, जब तक कि आप किसी प्रकार का एक्सेल ऐप नहीं बना रहे हों।

मेरे लिए सबसे महत्वपूर्ण उपयोग केवल समय बचाने के लिए और मानसिक रूप से उस गणना को करने से बचने के लिए मौजूदा या मौजूदा संख्या को विभाजित करने में सक्षम होना है।

ठीक है अच्छा है! जैसा लगता है वैसा ही @xyzzer ने प्रस्तावित किया। मैं इसी तरह के कार्यान्वयन पर एक नज़र डालूंगा और देख सकता हूं कि ऐसा करने के लिए प्राकृतिक और सहज महसूस करने के लिए जगह है या नहीं।

हमें (BeLight Software, Live Home 3D project) को मूल्य <=> पाठ रूपांतरण के लिए प्लग करने योग्य ValueConverter की आवश्यकता है, अन्यथा NumberBox हमारे लिए अनुपयुक्त होगा।

मैंने आपके द्वारा दिए गए स्लाइडर उदाहरण पर एक नज़र डाली और यह बहुत ही उचित लगता है - मैं NumBox के लिए IValueConverter में मान देख सकता था। मैं जल्द ही इस पर गौर करूंगा और हम यह तय करने का प्रयास करेंगे कि क्या यह युक्ति में उचित रूप से फिट बैठता है। हालांकि अभी तक कुछ भी वादा नहीं किया है!

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

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

मुझे आश्चर्य है कि स्थानीयकरण के बारे में अभी भी प्रश्न हैं।

समस्या यह है कि भाषा वह चीज नहीं है जो स्वरूपण को नियंत्रित करती है, यह क्षेत्र/संस्कृति सेटिंग्स है। स्थानीयकरण यूआई स्ट्रिंग्स को सही भाषा में प्रदर्शित करने के लिए अद्यतन करने के बारे में है जबकि संख्या/मुद्रा/डेटाटाइम स्वरूपण क्षेत्र द्वारा नियंत्रित किया जाता है। अधिक जानकारी यहाँ: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture। और मामलों को जटिल बनाने के लिए विंडोज़ आपको डिफ़ॉल्ट को ओवरराइड करके यूआई में अपनी लोकेल सेटिंग्स को अनुकूलित करने की अनुमति देता है - ताकि आप कह सकें कि आप चाहते हैं कि आपका दशमलव विभाजक डिफ़ॉल्ट के बजाय कोई यादृच्छिक वर्ण हो। और फिर उसके ऊपर, .NET ऐप्स को अनुकूलित करने की अनुमति देता है, साथ ही डेवलपर्स यहां उस स्तर के अनुकूलन की अपेक्षा कर रहे हैं।

समस्या यह है कि भाषा वह चीज नहीं है जो स्वरूपण को नियंत्रित करती है, यह क्षेत्र/संस्कृति सेटिंग्स है। स्थानीयकरण यूआई स्ट्रिंग्स को सही भाषा में प्रदर्शित करने के लिए अद्यतन करने के बारे में है जबकि संख्या/मुद्रा/डेटाटाइम स्वरूपण क्षेत्र द्वारा नियंत्रित किया जाता है। अधिक जानकारी यहाँ: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture। और मामलों को जटिल बनाने के लिए विंडोज़ आपको डिफ़ॉल्ट को ओवरराइड करके यूआई में अपनी लोकेल सेटिंग्स को अनुकूलित करने की अनुमति देता है - ताकि आप कह सकें कि आप चाहते हैं कि आपका दशमलव विभाजक डिफ़ॉल्ट के बजाय कोई यादृच्छिक वर्ण हो। और फिर उसके ऊपर, .NET ऐप्स को अनुकूलित करने की अनुमति देता है, साथ ही डेवलपर्स यहां उस स्तर के अनुकूलन की अपेक्षा कर रहे हैं।

Language एक मान लेता है जिसका अनुवाद CultureInfo --ध्यान दें कि अप्रबंधित कोड विकास में संस्कृति को लोकेल कहा जाता है। इसमें एक NumberFormat संपत्ति है जो एक NumberFormatInfo प्रकार है जिसमें दशमलव, समूहीकरण, नकारात्मक संकेत, और बहुत कुछ के गुण शामिल हैं।

मेरी समझ यह है कि यदि आप सिस्टम सेटिंग्स पर निर्भर होने के बजाय विशिष्ट स्वरूपण या अन्य स्थानीयकरण विशिष्टताओं को नियंत्रण पर लागू करना चाहते हैं, तो ऐसा करने का तरीका Language निर्दिष्ट करना है।

संपत्ति के विवरण में स्पष्ट रूप से कहा गया है कि यह "स्थानीयकरण/वैश्वीकरण भाषा की जानकारी सेट करता है जो फ्रेमवर्क एलिमेंट पर लागू होता है"

या हो सकता है कि मैंने उन दस्तावेज़ों को गलत समझा हो जिनका मैं संदर्भ दे रहा हूं, लेकिन वे सभी उस पृष्ठ का बैक अप लेते हैं जो आपके द्वारा लिंक किए गए पृष्ठ में शामिल है।
हो सकता है कि यह अलग-अलग शर्तों का उपयोग करके सी ++ और सी # के साथ एक शब्दावली समस्या है।
मुझे क्या पता है कि एक्सएएमएल में भाषा की स्थापना यह है कि मैं किसी अन्य ऐप में और किसी अन्य नियंत्रण के साथ संस्कृति/लोकेल को कैसे मजबूर करूं।

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

Language एक मान लेता है जिसका अनुवाद CultureInfo

देशी/WinRT में नहीं, हमें बस एक BCP-47 लैंग्स स्ट्रिंग मिलती है। और यही समस्या है। .NET में आप CultureInfo को बंडल करते हैं जिसमें भाषा सेटिंग्स और प्रारूप सेटिंग्स होती हैं। WinRT में यह अलग है और CultureInfo ऑब्जेक्ट के बराबर नहीं है।

मैंने सुना है कि आईसीयू एपीआई जो हम खोज रहे हैं उसे सक्षम कर सकते हैं लेकिन हमें अभी तक इसकी जांच करने का मौका नहीं मिला है।

मुझे लगता है कि माइक्रोसॉफ्ट को इस पर बुलेट काटने और .net संस्कृतियों/स्थानीयकरण (कल्चरइन्फो) और देशी/विनआरटी के बीच रूपांतरण तंत्र को पूरी तरह कार्यान्वित करने पर विचार करना होगा। आदर्श रूप से आप चीजों को करने के नए तरीके पर विचार नहीं करेंगे:

मुझे लगता है कि प्रबंधित कोड वह है जिसमें अधिकांश LOB ऐप्स लिखे गए हैं और इसे शुरू से ही सही तरीके से करने की आवश्यकता है। WinRT को .net के समान स्थानीयकरण तंत्र/तकनीक प्राप्त करने की आवश्यकता है और रूपांतरण स्वचालित होने की आवश्यकता है।

क्या यह बहुत अधिक काम होगा? शॉर्ट टर्म: हां, लॉन्ग टर्म: नहीं। क्या इससे नंबरबॉक्स नियंत्रण जारी होने में देरी हो सकती है? शायद, जब तक कि अल्पावधि में कॉलबैक का उपयोग नहीं किया जाता।

हालांकि इसे ठीक करने की जरूरत है या कहीं और समस्याएं होने वाली हैं। मैं पहले से ही कुछ इसी तरह के मुद्दों को अन्य परिदृश्यों जैसे संपादन योग्य CalendarDatePicker, आदि के साथ देख सकता हूं। (#735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
जाहिरा तौर पर FastDNA टीम अपने इनपुट नंबर फ़ील्ड डिज़ाइन के लिए अपने स्पिनर नियंत्रण पर भी काम कर रही है, और वे एक प्रस्ताव लेकर आए जो विचार करने योग्य हो सकता है।

उन्होंने यह भी पूछा कि हम तीरों के बजाय शेवरॉन का उपयोग क्यों कर रहे हैं।

https://github.com/microsoft/fast-dna/issues/2202

यहां तक ​​​​कि अगर हम बटनों को एक साथ रखते हैं, स्टैक्ड विस्तारित डिज़ाइन को होवर के रूप में रखते हुए, एक विचार हो सकता है जब नियंत्रण चौड़ाई बहुत संकीर्ण हो? हो सकता है कि सभी माइक्रोसॉफ्ट यूआई ढांचे में काम करने वाले लेआउट पर कुछ आम सहमति हो?

@mdtauk , हमें बताने के लिए धन्यवाद।
FastDNA लोगों के साथ जाँच कर रहा है कि क्या यह वह डिज़ाइन है जिस पर वे परीक्षण कर रहे हैं और उपयोगिता को मान्य कर रहे हैं।

नंबरबॉक्स पर वापस

ठीक है टीम,

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

पुराने वर्कफ़्लो में बहुत सारा सामान है, इसलिए मैं किसी भी खुले या उत्तर वाले प्रश्नों को संरक्षित कर रहा हूँ और उन्हें एक नए विशिष्ट पीआर में पोर्ट कर रहा हूँ जहाँ @teaP और मैं अपने शेष खुले विषयों को हल करना समाप्त कर देंगे:

• स्थानीयकरण
• डिजाइन (विशेष रूप से ऊपर/नीचे बटन के संबंध में)
• हाइपरस्क्रॉल/हाइपरड्रैग

ध्यान दें कि सत्यापन विषय हल हो गया है। साथ @LucasHaines ' इनपुट सत्यापन काम है कि इससे पहले कि WinUI 3.0 और NumberBox नियोजन रिलीज किया जा रहा है, हम NumberBox V1 के समर्थित सत्यापन करने के लिए मोड कम कर दिया है:

enum NumberBoxBasicValidationMode
{
विकलांग,
अमान्य इनपुट अधिलेखित,
};

विनयूआई 3.0 और सह-अपेक्षित इनपुट सत्यापन कार्य आओ, हम उस एनम को मूल रूप से नियोजित IconMessage और TextBlockMessage सत्यापन मोड के साथ NumberBox V2 में विस्तारित करना चाहेंगे।

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

ओफ़्फ़। यह मेरे करीब आ रहा था कि मैं खुद ऐसा करने की कोशिश कर रहा हूं।

हाहा मैं इस पर निष्क्रिय रूप से काम करना पसंद करता लेकिन इस सेमेस्टर ने मुझे खत्म कर दिया है। यह देखकर खुशी हुई कि यह लिपटा हुआ है मैं इस पर नज़र रखूँगा!

NumberBox की आरंभिक प्रतिबद्धता अभी लाइव है!

कृपया - ध्यान रखें कि यह अभी भी एक कार्य-प्रगति है, जिसमें देव और पीएम दोनों पक्षों पर सक्रिय समस्या ट्रैकिंग है। यदि आप सुविधाओं पर बग या सामान्य ढीले सिरे देखते हैं, जिन्हें पहले से ही उपयुक्त लिंक पर नोट नहीं किया गया है, तो हमें बताने के लिए सशक्त महसूस करें। मैं

@SavoySchuler , क्या आप कल्पना के लिए एक नया पीआर खोलेंगे? साथ ही, क्या आपने इस बात पर ध्यान दिया कि मैंने इस टिप्पणी में विशेष रूप से NaN डिस्प्ले के आसपास क्या लिखा है? धन्यवाद।

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

चरण आवृत्ति

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

साथ ही, क्या उपयोगकर्ता परिभाषित चरण के बाहर किसी मान को इनपुट करने में सक्षम होगा?
उदाहरण के लिए न्यूनतम = 0, अधिकतम = 6, चरण आवृत्ति = 2. ऊपर तीर मान का उपयोग करना {2, 4, 6} पर्याप्त होगा। क्या उपयोगकर्ता 0.5 को वैध मान के रूप में टाइप कर सकता है? या इसे 0 या 2 तक पूर्णांकित किया जाएगा?

गोलाई

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

स्थानीयकरण

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

पाठ रैपिंग

संपादित करें: मुझे अगली बार पूरी कल्पना पढ़नी चाहिए।

आपने एक नई 'IsWrapEnabled' संपत्ति क्यों बनाई है? क्या ऐसा इसलिए है क्योंकि आपको लगता है कि 'टेक्स्ट' शब्द नंबरबॉक्स पर बहुत अच्छी तरह से लागू नहीं होता है?

साथ ही, मैं समझता हूं कि शायद लपेटें और WrapWithOverflow दोनों को समान रूप से लागू किया गया है, लेकिन फिर दोनों एनम मानों को समकक्ष होने दें और दस्तावेज़ीकरण में कार्यक्षमता का वर्णन करें।

कीबोर्ड एक्सेलेरेटर को सही तरीके से हैंडल करें

कृपया सुनिश्चित करें कि यह नियंत्रण टेक्स्टबॉक्स की तुलना में बेहतर कुंजीपटल त्वरक का उपयोग करने का समर्थन करता है। शायद यह तब तक नहीं किया जा सकता है जब तक टेक्स्टबॉक्स तय नहीं हो जाता है, लेकिन # 1435 वास्तव में मेरे लिए एक समस्या है जो बहुत सारे बदसूरत काम का कारण बनती है। टेक्स्टबॉक्स स्वयं 'Ctrl+V' पेस्ट को हैंडल करेगा और फिर कोई भी कीबोर्ड एक्सेलेरेटर उठाया जाएगा। हालांकि, कीबोर्ड एक्सेलेरेटर के भीतर यह जानने का कोई तरीका नहीं है कि टेक्स्टबॉक्स ने अभी अपना काम किया है।

एक त्वरित विचार। क्या कोई एंगल मोड होना चाहिए जो डिग्री ग्लिफ़ को मान में जोड़ दे (और 360 ° रैप के लिए कोई तर्क)

°

या भविष्य में टेक्स्टबॉक्स #784 . के लिए मेरे प्रत्यय प्रस्ताव के साथ इस परिशिष्ट को बेहतर ढंग से संभाला जाएगा

@mdtauk , एक INumberFormatter2 के साथ डिग्री प्रतीक जोड़ना संभव होगा - यह एक और अच्छा कारण है जिसे सामान्य रखने की आवश्यकता है। आप किसी संख्या को एक स्ट्रिंग में बदलने और स्ट्रिंग को वापस नियंत्रण में भेजने के लिए जो कुछ भी आवश्यक है वह कर सकते हैं।

रैपिंग के लिए, असल में IsWrapEnabled प्रॉपर्टी इसी के लिए है... मुझे अगली बार डॉक्यूमेंटेशन के अंत को पढ़ने की जरूरत है।

नीचे की रेखा मुझे लगता है कि हम मौजूदा एपीआई के साथ वह सब कुछ कर सकते हैं जो आप चाहते हैं।

@mdtauk , एक INumberFormatter2 के साथ डिग्री प्रतीक जोड़ना संभव होगा - यह एक और अच्छा कारण है जिसे सामान्य रखने की आवश्यकता है। आप किसी संख्या को एक स्ट्रिंग में बदलने और स्ट्रिंग को वापस नियंत्रण में भेजने के लिए जो कुछ भी आवश्यक है वह कर सकते हैं।

रैपिंग के लिए, असल में IsWrapEnabled प्रॉपर्टी इसी के लिए है... मुझे अगली बार डॉक्यूमेंटेशन के अंत को पढ़ने की जरूरत है।

नीचे की रेखा मुझे लगता है कि हम मौजूदा एपीआई के साथ वह सब कुछ कर सकते हैं जो आप चाहते हैं।

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

@teaP नए कॉम्पैक्ट ओवरले स्पिन बटन में एक शो जोड़ना और एनीमेशन छिपाना संभव होगा?

क्या आपने कॉम्बोबॉक्स और फ़्लायआउट तत्वों के साथ अन्य फॉर्म फ़ील्ड से बेहतर मिलान करने के लिए इसमें ऐक्रेलिक जोड़ने पर विचार किया है?

संपादित करें: यह डार्क थीम में दृश्यता के इस मुद्दे को ठीक करेगा। क्या टेक्स्टबॉक्स के केंद्रित रंग से मेल खाने या वर्तमान थीम रंगों से मेल खाने का इरादा है? वैसे भी, ऐक्रेलिक इसे हल करता है।

@SavoySchuler , क्या आप कल्पना के लिए एक नया पीआर खोलेंगे? साथ ही, क्या आपने इस बात पर ध्यान दिया कि मैंने इस टिप्पणी में विशेष रूप से NaN डिस्प्ले के आसपास क्या लिखा है? धन्यवाद।

@adrientetar निश्चित रूप से। जब नंबरबॉक्स खाली होता है, तो Value को NaN पर सेट किया जाएगा (जैसा आपने अनुरोध किया है) और PlaceholderText दिखाएगा।

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

चरण आवृत्ति

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

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

साथ ही, क्या उपयोगकर्ता परिभाषित चरण के बाहर किसी मान को इनपुट करने में सक्षम होगा?
उदाहरण के लिए न्यूनतम = 0, अधिकतम = 6, चरण आवृत्ति = 2. ऊपर तीर मान का उपयोग करना {2, 4, 6} पर्याप्त होगा। क्या उपयोगकर्ता 0.5 को वैध मान के रूप में टाइप कर सकता है? या इसे 0 या 2 तक पूर्णांकित किया जाएगा?

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

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

उपयोग की जाने वाली गोलाई रणनीति को आपके स्वरूपण के माध्यम से परिभाषित किया जाता है। DecimalFormatter उदाहरण पर व्याख्या करने के लिए, यहां एक राउंडिंग प्रॉपर्टी का एक उदाहरण

गोलाई

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

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

स्थानीयकरण

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

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

पाठ रैपिंग

संपादित करें: मुझे अगली बार पूरी कल्पना पढ़नी चाहिए।

~ आपने एक नई 'IsWrapEnabled' संपत्ति क्यों बनाई है? यह TextBlock.TextWrapping और TextWrapping Enum का उपयोग करने के TextBox/XAML सम्मेलन के विरुद्ध जाता है। क्या ऐसा इसलिए है क्योंकि आपको लगता है कि 'टेक्स्ट' शब्द नंबरबॉक्स पर बहुत अच्छी तरह से लागू नहीं होता है?~

~ इसके अलावा, मैं समझता हूं कि शायद Wrap और WrapWithOverflow दोनों को समान रूप से लागू किया गया है, लेकिन फिर दोनों एनम मानों को समकक्ष होने दें और दस्तावेज़ीकरण में कार्यक्षमता का वर्णन करें। यहां एक नई संपत्ति बनाने का मतलब है कि हमें नए मूल्य कन्वर्टर्स की आवश्यकता है, आदि ... मेरे विचार से मौजूदा परंपरा को तोड़ने का कोई कारण नहीं है। ~

कीबोर्ड एक्सेलेरेटर को सही तरीके से हैंडल करें

कृपया सुनिश्चित करें कि यह नियंत्रण टेक्स्टबॉक्स की तुलना में बेहतर कुंजीपटल त्वरक का उपयोग करने का समर्थन करता है। शायद यह तब तक नहीं किया जा सकता है जब तक टेक्स्टबॉक्स तय नहीं हो जाता है, लेकिन # 1435 वास्तव में मेरे लिए एक समस्या है जो बहुत सारे बदसूरत काम का कारण बनती है। टेक्स्टबॉक्स स्वयं 'Ctrl+V' पेस्ट को हैंडल करेगा और फिर कोई भी कीबोर्ड एक्सेलेरेटर उठाया जाएगा। हालांकि, कीबोर्ड एक्सेलेरेटर के भीतर यह जानने का कोई तरीका नहीं है कि टेक्स्टबॉक्स ने अभी अपना काम किया है।

नंबरबॉक्स में टेक्स्टबॉक्स होता है और शीर्ष पर गुण और कॉन्फ़िगरेशन जोड़ता है। मैं @jevan को टैग टेक्स्टबॉक्स स्तर पर ठीक करने की आवश्यकता हो सकती है।

कुल मिलाकर, शानदार प्रतिक्रिया @robloo! मैं यह सुनिश्चित करने में आपके द्वारा लिए गए समय की सराहना करता हूं कि हम V1 नंबरबॉक्स के साथ उतने ही व्यापक और पूर्ण हैं जितना हम हो सकते हैं! कृपया मुझे बताएं कि क्या आपके कोई और प्रश्न हैं। मैं

@mdtauk

एक त्वरित विचार। क्या कोई एंगल मोड होना चाहिए जो डिग्री ग्लिफ़ को मान में जोड़ दे (और 360 ° रैप के लिए कोई तर्क)

°

या भविष्य में टेक्स्टबॉक्स #784 . के लिए मेरे प्रत्यय प्रस्ताव के साथ इस परिशिष्ट को बेहतर ढंग से संभाला जाएगा

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

मुझे लगता है कि #784 के लिए आपका प्रस्ताव हमारे मंच के लिए अब तक का सबसे व्यापक प्रस्ताव है। अगर उस प्रस्ताव पर कार्रवाई नहीं होती है, तो यह मुझे एक उपयुक्त V2 फीचर नंबरबॉक्स के रूप में फॉलबैक के रूप में प्रभावित करता है।

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

यहां अन्य सभी संपत्तियों के बीच स्व-दस्तावेजीकरण होने के लिए, हम "स्पिनबटनस्टेप" की तर्ज पर कुछ पर विचार कर रहे हैं, क्या यह तर्क विचलन के लिए पर्याप्त औचित्य होना चाहिए

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

@robloo और @mdtauk , मुझे ° के बारे में उत्तर देने से पहले धागे में और पढ़ना चाहिए था। मुझे विश्वास नहीं है कि यह वर्तमान में Text अंदर इस प्रतीक को दिखाने के लिए समर्थित है क्योंकि नंबरबॉक्स Text और Value कसकर सिंक में रखता है ताकि आपको अनुमति देने के उद्देश्य से डेवलपर्स हड़प सकें रूपांतरण के ऊपरी भाग के बिना आपको कभी भी किस प्रकार की आवश्यकता होती है। मुझे उपलब्ध स्वरूपण गुणों के माध्यम से इसे प्राप्त करने का कोई तरीका नहीं दिख रहा था, लेकिन यदि आप कोई तरीका जानते हैं, तो कृपया मुझे बताएं!

हम अभी V1 रिलीज़ के ठीक सामने आ रहे हैं, लेकिन V2 के लिए हम फिर से उपसर्ग/प्रत्यय/विशेष वर्णों पर एक नज़र डालेंगे। इस बीच, मेरा मानना ​​है कि @mdtauk का #784 का प्रस्ताव अब तक मंच के लिए सबसे व्यापक समाधान है। कृपया उस प्रस्ताव को एक अंगूठा दें और एक टिप्पणी दें यदि यह एक ऐसी सुविधा है जिसकी आपको आवश्यकता है।

@adrientetar , स्क्रॉल-टू-चेंज ने इसे V1 के लिए बनाया लेकिन ड्रैग-टू-चेंज को V2 में देरी हुई। चूंकि हम अभी भी उन सुविधाओं को पूरा करना चाहते हैं, हमने अभी तक आपके अनुरोध पर चर्चा करने के लिए इसे तैयार नहीं किया है कि शिफ्ट + ऊपर / नीचे चरण 10 की इकाइयों में और Ctrl + Shift + ऊपर / नीचे चरण 100 की इकाइयों में है।

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

@SavoySchuler

आपकी टिप्पणियों के लिए बहुत-बहुत धन्यवाद।

यहां अन्य सभी संपत्तियों के बीच स्व-दस्तावेजीकरण होने के लिए, हम "स्पिनबटनस्टेप" की तर्ज पर कुछ पर विचार कर रहे हैं, क्या यह तर्क विचलन के लिए पर्याप्त औचित्य होना चाहिए

मुझे वह शब्दावली बहुत पसंद है, मुझे याद आया कि स्लाइडर के पास पहले से ही StepFrequency संपत्ति है। चूंकि ऐसा है, इसलिए सम्मेलन से विचलित होने का कोई मतलब नहीं है जैसा कि @jevansaks ने कहा है।

स्वरूपण के माध्यम से गोलाई को नियंत्रित किया जाता है। यहाँ एक पूर्णांकन गुण का उदाहरण दिया गया है जिसे DecimalFormatter के लिए सेट किया जा सकता है।

मान लें कि उपयोगकर्ता नंबरबॉक्स में "1/3" दर्ज करता है। क्या निम्नलिखित क्रम सही है:

• फोकस / एंटर के खो जाने पर एक्सप्रेशन का मूल्यांकन किया जाएगा और 0.33333333...34 के दोहरे मान की गणना की जाएगी
• ०.३३३३३३३३३...३४ DecimalFormatter को पास कर दिया जाएगा
• 0.33333333...34, आपकी सेटिंग के आधार पर, "0.30" तक पूर्णांकित किया जा सकता है (बस कठिन होने के लिए)
• उस "०.३०" मान को तब उपयोगकर्ता को प्रदर्शित करने के लिए टेक्स्टबॉक्स में रखा जाएगा
• डबल Value अब {0.33333333...34} है और Text मान अब "0.30" है
• पढ़ना डबल Value गोल संख्या में प्रदर्शित किया जाता है नहीं लौटेगा Text
  (या दशमलव स्वरूपित मान किसी स्ट्रिंग में रूपांतरण के बाद फिर से पार्स किया गया है? और फिर पूरी चीज का पुनर्मूल्यांकन किया गया है?)

मुझे इस बात की भी चिंता है कि मूल्य और पाठ गुण आंतरिक रूप से इतने कसकर युग्मित हैं। दस्तावेज़ीकरण इस युग्मन को परिभाषित नहीं करता है और यदि यह अत्यधिक संरचित नहीं है तो दो-तरफा निर्भरता कभी मजेदार नहीं होती है।

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

अनुक्रम होना चाहिए:

• उपयोगकर्ता टेक्स्ट इनपुट -> पार्सर -> डबल वैल्यू -> फ़ॉर्मेटिंग -> टेक्स्ट

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

मूल्य और पाठ अनुक्रम के बीच गोलाई को सटीक रखने के लिए और अधिक होगा:

• यूजर टेक्स्टुअल इनपुट -> पार्सर -> वैल्यू -> राउंडिंग -> वैल्यू -> फॉर्मेटिंग -> टेक्स्ट

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

@adrientetar , स्क्रॉल-टू-चेंज ने इसे V1 के लिए बनाया लेकिन ड्रैग-टू-चेंज को V2 में देरी हुई। चूंकि हम अभी भी उन सुविधाओं को पूरा करना चाहते हैं, हमने अभी तक आपके अनुरोध पर चर्चा करने के लिए इसे तैयार नहीं किया है कि शिफ्ट + ऊपर / नीचे चरण 10 की इकाइयों में और Ctrl + Shift + ऊपर / नीचे चरण 100 की इकाइयों में है।

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

एक बड़ा वेतन वृद्धि होना चाहिए, और दूसरा छोटा होना चाहिए - Adobe ऐप्स में चयनित क्षेत्रों/वस्तुओं को कुहनी मारने के समान

क्या आप मुझे उन परिदृश्यों के बारे में अधिक संदर्भ दे सकते हैं जिनमें आप इस सुविधा का उपयोग करेंगे?

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

आपके उपयोगकर्ता कैसे जानते हैं कि यह उपलब्ध है?

यह केवल एक विशेषता है जो आधुनिक उपकरणों में है, जैसे Adobe XD, Framer...

क्या आप मुझे यह समझने में मदद कर सकते हैं कि यह आपके समाधान में स्थानीय रूप से लागू किए जाने की तुलना में सभी नंबरबॉक्स में डिफ़ॉल्ट (या कम से कम उपलब्ध) क्यों होना चाहिए?

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

एक बड़ा वेतन वृद्धि होना चाहिए, और दूसरा छोटा होना चाहिए - Adobe ऐप्स में चयनित क्षेत्रों/वस्तुओं को कुहनी मारने के समान

रेंजबेस में स्मॉलचेंज और लार्ज चेंज के गुण हैं। हम न्यूमेरिकअपडाउन के अपने संस्करण में BeLight सॉफ़्टवेयर में रेंजबेस से प्राप्त होते हैं और एरोअप और एरोडाउन शॉर्टकट का उपयोग करके स्मॉलचेंज द्वारा और पेजअप और पेजडाउन शॉर्टकट का उपयोग करके लार्ज चेंज द्वारा मूल्य बदलते हैं।

और हम यहाँ अकेले नहीं हैं,
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

कम्युनिटी कॉल के दौरान मेरे दिमाग में आए कीबोर्ड न्यूमेरिक कीपैड के बारे में सिर्फ एक टिप्पणी...

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

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

कैलक्यूलेटर ऐप भी "." को फिर से लिखता है। इसे दशमलव विभाजक वर्ण के रूप में व्याख्या करने के लिए दबाएं।

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

शायद एक संपत्ति सुविधा को सक्षम (यदि ऑप्ट-इन) या अक्षम (यदि ऑप्ट-आउट) करने की अनुमति दे सकती है। जैसे KeyPadDotAsDecimalSeparator="false" ?

V2 नंबरबॉक्स प्रस्ताव: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

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

हम यह भी जानते हैं कि हर चीज ने इसे V1 रिलीज में नहीं बनाया। कुछ अत्यधिक वांछित इनपुट सत्यापन कॉन्फ़िगरेशन WinUI 3.0 सुविधा कार्य पर निर्भर हैं, कुछ वांछित सुविधा की आवश्यकता सत्यापन/अनुप्रयोग में देर से सामने आई है, और कुछ विशेषताएं जिन्हें हम जानते थे कि V1 रिलीज के बाद बेहतर खोज की जाएगी।

हम WinUI 3 रिलीज के साथ अपने इच्छित नंबरबॉक्स फीचर काम को पूरा करना चाहते हैं। मैंने उन आवश्यक सुविधाओं पर प्रतिक्रिया एकत्र करने के लिए एक मुद्दा खोला है जो V1 से गायब हैं। अगर नंबरबॉक्स में आपकी जरूरत की कोई चीज नहीं है, तो कृपया यहां एक टिप्पणी छोड़ना सुनिश्चित करें: https://github.com/microsoft/microsoft-ui-xaml/issues/1736