كنقطة انطلاق ، لدى Telerik 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 Community Toolkit على بعض أوجه القصور:

ملحق TextBoxRegex مع ValidationType = "Decimal" لا يدعم كافة ثقافات واجهة المستخدم. بدلاً من ذلك ، تم إصلاحه على InvariantCulture. في اللغة الإنجليزية ، القيم العشرية هي "10.1234" مع نقطة. في الإسبانية أو الألمانية ، يتم كتابة القيم العشرية "10،1234". سيكون تحليل اللغة الإنجليزية صحيحًا ؛ ومع ذلك ، سيكون إدخال المستخدم الأسباني أو الألماني فقط "101234" مع فقد الجزء الكسري.

انظر: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2700

يجب أن يزيد السهمان لأعلى ولأسفل أو ينقصان القيمة بقيمة يمكن للمطور تعيينها ، ولكن يجب أن يكون الافتراضي هو عدد صحيح مقداره 1

• قيم min / max الملتفة جيدة ، على سبيل المثال عند اختيار زاوية
• القدرة على إضافة لاحقة
• انقر فوق مربع النص واسحب لأعلى / لأسفل لتغيير القيم ، يحتوي Adobe XD على هذا في مدخلات الأرقام.

يدعم تطبيقي في WinRT XAML Toolkit أيضًا السحب لأعلى / لأسفل لتغيير القيم ويجعلها أكثر قابلية للاستخدام عند الاستخدام بالماوس من النقر فوق الأزرار في سيناريوهات معينة.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

مرحبا،sonnemaf،ArchieCoder،robloo،mdtauk،adrientetar، وxyzzer! لقد تم تكليفي لهذا الاقتراح.

أولاً ، شكرًا لك sonnemaf على إرسال هذا. لقد عرضته في Microsoft Build 2019 الأسبوع الماضي وحظي بهتافات من الجمهور! تعكس استجابة المجتمع هنا في التعليقات أيضًا الإثارة التي لدينا لرؤية NumberBox يحدث.

لقد قرأت تعليقات الجميع وقمت بتحديث قسم النطاق ليعكس المدخلات التي تلقيتها. سأكون ممتنًا لو استغل الجميع الفرصة للتحقق من هذا التحديث الصغير وإخباري إذا لم ألتقط طلباتك بدقة ، مع ملاحظة أنه سيتم التعامل مع بعض التفاصيل (مثل تنسيق الترجمة) على مستوى المواصفات.

مرحبًا SavoySchuler ،

هذا الأسبوع ، أعمل على ميزة إمكانية الوصول في تطبيقي. ستكون هذه ميزة إضافية إذا تم التعامل مع إمكانية الوصول بشكل صحيح باستخدام عنصر التحكم الجديد على سبيل المثال ، يمكن نطق الزيادة بصوت عالٍ بدلاً من "زائد" ، "ناقص". البقية تبدو جيدة بالنسبة لي

التأكد من أن الراوي قادر على قراءة القيم بشكل صحيح بحيث يكون من الواضح أن ما يحدث هو أمر مهم.

لست متأكدًا مما إذا كانت وحدة التحكم Xbox ستحتاج إلى أي ضغط للتركيز للتأكد من أن العصي التناظرية و D-Pad ستعمل بشكل صحيح

تصحيح صغير - يجب أن يعمل السحب لزيادة / تقليل على حقل النص نفسه حتى يتم تنشيطه. في تطبيقي ، اضطررت إلى وضع بعض التراكب الشفاف أعلى حقل النص لتمكينه وأيضًا إخفاء مؤشر الماوس أثناء السحب بحيث لا تحد حدود عنصر التحكم أو الشاشة من مسافة السحب وذلك عند الانتهاء من السحب وأظهر المؤشر مرة أخرى - يظهر في المكان الذي اختفى فيه لأول مرة.

SavoySchuler لقد حصلت على مهمة لطيفة. يمكنني العيش مع نطاقك. من الجيد أن تمتلك الآلة الحاسبة (WinUI 3.0 أو 3.1). لقد قمت بالتطوير في العديد من بيئات سطح المكتب (VB6 و WinForms و WPF و UWP) ودائمًا ما فاتني NumberBox. أخيرا سوف نحصل عليه.

ربما يمكنك أيضًا إضافة عجلة تمرير الماوس لأعلى / لأسفل. يدعم Blend for Visual Studio هذا.

أحب أيضًا ميزة السحب للتغيير ، وهو شيء استخدمته كثيرًا في Expression Blend.

لست متأكدًا مما سيفعله التحقق من صحة الإدخال ولا يفعله. هل ستكون لوحة المفاتيح min / max فقط أم لوحة المفاتيح المحددة أيضًا (الأحرف az ، إلخ)؟ هل سيتعامل مع لصق الأرقام غير الصالحة؟

أود قراءة المواصفات الكاملة.

ArchieCoder ، أسمعك بصوت عال وواضح. تعد إمكانية الوصول أولوية وأفضل معالجة لها مقدمًا. لقد بدأت قسم إمكانية الوصول والمدخلات في هذا الاقتراح حيث أضفت ملاحظتك.

mdtauk ، سؤال رائع كما هو الحال دائمًا. لقد أضفت هذا إلى قسم إمكانية الوصول والمدخلات كملاحظة للنظر فيه.

xyzzer ، أنت على حق. عند إعادة التنظيم ، قائمة النطاق ، قمت بتجميع الأزرار لأعلى / لأسفل والسحب للتغيير كوظيفة ذات صلة. عند إعادة قراءتها ، بدا الأمر كما لو كنت أقترح أن يكون السحب للتغيير ميزة على الأزرار. لقد قمت بنقل خاصية السحب للتغيير إلى القسم الخاص بها لتوفير الوضوح.

تضمين التغريدة سأقوم بنشر رابط للمواصفات بمجرد فتحها ، والذي من المحتمل أن يكون اليوم أو الأسبوع المقبل. من فضلك لا تشعر بالتشجيع للانضمام إلي في كتابتها! حتى ذلك الحين ، أضفت التمرير للتغيير إلى النطاق هنا.

الكل ، مع ملاحظة حول دعم الآلة الحاسبة - أؤمن بالقيمة. أنا أعمل مع فريقي لمعرفة ما إذا كان هذا شيء يجب أن نضعه في شكل نمطي في حالة إمكانية الاستفادة من الوظيفة بشكل أكبر في النظام الأساسي. بالإضافة إلى ذلك ، هناك مسألة إلى أي مدى نذهب مع دعم الآلة الحاسبة؟ هل سيفعل ترتيب العمليات البسيط في + - / *؟ أو شيء أكثر شمولاً مثل الاتصال بنوع من خدمات wolfram alpha؟ قد يسمح لنا استكشاف مسار معياري بالبدء بالحالة الأساسية مع عدم حظر الفرصة لشكل أكثر شمولاً لدعم الآلة الحاسبة. سأكون مهتمًا بمعرفة احتياجات الجميع هنا.

للتحقق من صحة الإدخال ، لدي نفس السؤال. هل min ، max ، no letter ، ولا لصق غير صالح يغطيه؟

أجد ميزة الآلة الحاسبة لطيفة ، ولكن عمليًا كيف يمكن للمستخدم اكتشاف هذه الميزة؟ هل سيكون هناك القليل من تلميح القطعة حول هذا؟

ArchieCoder ، هل تعتقد أن نص العنصر النائب المخصص الباهت في NumberBox يمكن أن يطالب المستخدم بشكل مناسب؟ إذا كان الأمر كذلك ، أتخيل أن سلسلة مثل "أ + ب - ج" أو "إدخال المعادلة" يمكن أن تكون طرقًا مختصرة لتقديم تلك المعلومات. قام Excel أيضًا بإنشاء معيار مع ظهور "=" في بداية المعادلة. ربما بمجرد أن ينقر المستخدم على NumberBox ، يظهر "=" غير قابل للتغيير في المقدمة ثم يكتب المستخدم خلفه؟

لدينا بالفعل ToolTip أو TeachingTip الأثقل للإرشاد على مستوى التطبيق الذي يمكننا أن نطلب من المطورين الاعتماد عليه ، لكن أفضل ما لدي هو حل هذا الأمر داخل NumberBox نفسه.

أنا مهتم بسماع أفكارك هنا!

سيكون العنصر النائب طريقة جيدة بالفعل طالما أن السياق الآخر غير مطلوب بسبب محدودية المساحة. أعتقد أن عرض NumberBox سيكون أصغر من مربع نص على سبيل المثال.

ما لم يكن عنصر التحكم يدعم الأرقام الفارغة - سيظهر دائمًا قيمة ،
لذلك لن يكون هناك مساحة لسلسلة عنصر نائب بداخله.

يوم الجمعة 17 مايو 2019 الساعة 10:14 صباحًا ArchieCoder [email protected]
كتب:

سيكون العنصر النائب طريقة جيدة حقًا طالما أن السياق الآخر ليس كذلك
مطلوب بسبب ضيق المساحة. أعتقد أن عرض NumberBox سيفعل
تكون أصغر من مربع نص على سبيل المثال.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483؟email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43TUL52HS4DFVREXG43
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

ArchieCoder ، بالنظر إلى أمثلة sonnemaf (شكرًا لك مرة أخرى على هذه) ، فإن أي NumberBox ليس عريضًا بما يكفي لعرض نص العنصر النائب لـ "a + b - c" لن يكون عريضًا بدرجة كافية لإنشاء تجربة مستخدم موصى بها لـ إدخال المعادلات في. في هذا الصدد ، أتصور أن خيار الحل هذا لا يزال قابلاً للتطبيق لهذا الغرض. ومع ذلك ، أعتقد أنك تنقر على منطقة لم نعالجها بعد - السيناريوهات التي نريد فيها NumberBox مضغوطًا / إدخال رقم بسيط فقط. أتخيل أن دعم الآلة الحاسبة سيحتاج إلى واجهة برمجة تطبيقات لتعطيله ، وفي هذه الحالة لا نحتاج إلى الاهتمام بأنفسنا بنص العنصر النائب الطويل أو كسر قيود المساحة الدقيقة التي قد يحتاجها شكل المعادلة في NumberBox - على الرغم من أن بعض خيارات نص العنصر النائب للوضع المضغوط قد لا يزال لطيفًا ، حتى لو كان لشيء مثل "#" أو "على سبيل المثال 2".

xyzzer ، شكرًا على طرح هذا الأمر. دعونا نتأكد من أن هذه هي تجربة المستخدم الصحيحة أولاً ويمكننا معرفة التنفيذ من هناك! ليست هناك حاجة حتى الآن لوضع حد أقصى لبحثنا عن تجربة المستخدم _ right_ بسبب القيود التقنية التي قد نتمكن من تخفيفها. : استرخاء:

لدي سؤال ذو أولوية أعلى للجميع:

هل تفضل أن يكون لديك عنصر تحكم NumberBox الذي يدمج هذه الميزات بشكل مستقل عن TextBox القياسي أم تفضل أن تكون هذه الميزات مخبأة في TextBox كإمكانيات أصلية يمكن تنشيطها من خلال واجهات برمجة التطبيقات أو InputScope؟

(sonnemaf،ArchieCoder،robloo،mdtauk،adrientetar، وxyzzer)

يعد وضع كل هذا في عنصر تحكم TextBox تغييرًا مهمًا.

تم إدخال التحقق من صحة الأحرف.

استخدام تخطيط لوحة المفاتيح الصحيح مع InputScope

اختلاف سلوكيات الفأر.

القدرة على عرض الأزرار الدوارة كما هو الحال في إصدار FabricWeb.

إذا كان من الممكن إضافة كل هذه الأشياء ، مع تعداد السلوك لتحديد نوع TextBox ، دون التأثير على أي شخص آخر يستخدم حاليًا TextBox في تطبيقهم ، فهذا جيد.

ويمكنك أيضًا التفكير في الجمع بين سلوكيات TextBox الأخرى مثل رمز يمكن أن يمثل البحث أو التقويم الذي يعمل كزر. أقنعة لأشياء مثل عناوين IP أو عناوين URL التي تعرض "http: //" في نمط نص العنصر النائب عند إدخال نص بجانبه.

لدى FabricWeb مجموعة متنوعة مع TextFields الخاصة بهم.

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

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

سأذهب بالتأكيد مع عنصر تحكم NumberBox الخاص بدلاً من تحويل كل هذه الميزات إلى عنصر تحكم TextBox (على غرار كيف يوجد أيضًا عنصر تحكم PasswordBox وليس TextBox مع "كلمة مرور" لوضع الإدخال).

سيكون عنصر التحكم في NumberBox أكثر من مجرد حقل إدخال بسيط لعناوين IP ، على سبيل المثال. سيأتي مع ميزات إمكانية الوصول / التمرير والسحب الفريدة ، ودعم الآلة الحاسبة ، ... البيانات). وبما أنه سيتم اقتراح المزيد من الميزات / المتطلبات الخاصة للتحكم في NumberBox ، يمكننا الحفاظ على فصل لطيف ونظيف بين كل من NumberBox و TextBox.

سيظهر هذا spearation أيضًا في الوثائق وتخطيط التطبيق xaml (يمكن اكتشاف NumberBox بسهولة أكبر من ، على سبيل المثال ، TextBox مع مجموعة من الخصائص مع تحديد أحدها وضع الإدخال). بدلاً من قراءة وثائق TextBox حول إمكانيات الإدخال الرقمية الخاصة به ، سيكون هذا الجزء لطيفًا ومرتبًا في وثائق تحكم NumberBox محددة (تمامًا كما هو الحال مع PasswordBox اليوم).

فيما يتعلق بمظهر عنصر التحكم ، أعتقد أنه يمكن عرض الوحدة / اللاحقة جانبًا بحجم أصغر / لون غير مشبع بحيث يميز عن القيمة نفسها:

عند تحريك الماوس فوق عنصر التحكم ، يمكن أن تتلاشى الأسهم لأعلى / لأسفل بدلاً من الوحدة:

البديل هو عناصر التحكم في الأرقام من figma.com ، عندما تحوم فوق الوحدة ، يمكنك النقر فوق + سحب يسار / يمين لتغيير القيمة.

اليسار / اليمين مثير للاهتمام لأنه من الأسهل تحريك الماوس إلى اليسار / اليمين من تحريك الماوس لأعلى / لأسفل (لا تحتاج إلى رفع معصمك).

اشياء اخرى:

• عند النقر فوق منطقة النص غير المركزة ، يجب أن تحدد كل المحتوى. بحيث انقر فوق + اكتب قيمة + أدخل يغير القيمة
• Shift + انقر فوق سهم أو Shift + Up / Down عند التركيز زيادة أو نقصان بمقدار 10 (يجب أن تكون هذه القيمة قابلة للتخصيص أيضًا على ما أعتقد).
• لا أعتقد أن السهم لأعلى / لأسفل مفيد جدًا للمستخدم. إذا أراد المستخدم قيمة محددة ، فسيكتبها فقط ، وإذا لم يكن متأكدًا من القيمة التي يريدها ، فيمكنه تصور مجموعة من التغييرات في القيمة بالنقر فوق + السحب. لذا من المحتمل أن تكون الأسهم لأعلى / لأسفل اختيارية على الأقل.

يؤدي وضع مؤشر

• الموقع
• إمكانية الوصول
• اختيار
• لصق
• التحويلات

يمكن تجنب كل ذلك عن طريق وضع هذا في العنوان أو الوصف أو TextBlock منفصل.

سأختار عنصر تحكم NumberBox منفصل بخاصية القيمة وربما لا يكون خاصية نصية. يجب أن تكون القيمة Double حتى نتمكن من ربطها (x: Bind). لست متأكدًا مما إذا كان يجب علينا أيضًا دعم نوع البيانات العشري ، وكيف.

أعتقد أن دعم الأرقام الفارغة أمر لا بد منه (شكرًا xyzzer). يجب أن تكون الخاصية Value على Nullableنوع البيانات. لست متأكدًا مما إذا كان هذا سيتسبب في حدوث مشكلات ملزمة عند ربطه بقيمة غير قابلة للإلغاء.

في حين أن التكوين له فوائد وله سلوك مرتبط لمرقمة
يمكن تنفيذ الوضع وإرفاقه بـ TextBox - أعتقد أنه سيكون كذلك
انها معقدة ومحدودة بلا داع.
تتعلق بعض أكبر المشكلات التي قد تواجهها على الأرجح بالتنفيذ
إمكانية الوصول. أعتقد أنه يدعم بعض أنماط إمكانية الوصول -
ستحتاج إلى تنفيذ واجهات معينة في TextBox
من شأنه أن يجعل الأمر مربكًا إذا لم يكن TextBox في وضع مربع الأرقام.

يوم الاثنين 20 مايو 2019 الساعة 2:33 صباحًا Fons Sonnemans [email protected]
كتب:

أعتقد أن دعم الأرقام الفارغة أمر لا بد منه (شكرًا xyzzer
https://github.com/xyzzer ). يجب أن تكون الخاصية Value على Nullable
نوع البيانات. لست متأكدًا مما إذا كان هذا سيتسبب في حدوث مشكلات ملزمة عند إلزامه
قيمة غير قابلة للإلغاء.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483؟email_source=notifications&email_token=AANMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AANMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

لدي سؤال آخر للجميع. هل تحتاج / تفضل التحقق من صحة الإدخال أو إخفاءه؟

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

يعد التحقق من الصحة أمرًا ضروريًا ، حيث لا يمكنك إضافة رقم إلى سلسلة. ويلزم تقييم العوامل الحسابية ومعالجتها.

هل تحتاج إلى عرض رسالة خطأ إذا لم تتمكن من الحساب ، ولست متأكدًا منها.

قد يكون الإخفاء مفيدًا ، ولكن من المحتمل أن يتم تضمينه في Textbox نفسه ، لذلك يمكن معالجة إدخال عنوان URL والبريد الإلكتروني. سيكون NumberBox عبارة عن أرقام هواتف وعناوين IP وما إلى ذلك

لا أعتقد أنه يجب استخدام NumberBox لأرقام الهواتف أو عناوين IP. هذه تبدو أشبه بامتدادات بسيطة لإخفاء / تصفية لمربع نص. NumberBox هو شيء تريد استخدامه لإدخال قيمة واحدة.
ربما يكون هناك إمكانية للتحكم في صندوق العملة ، لكنني أشعر أيضًا أنه يجب أن يكون عنصر تحكم منفصل مختلفًا عن TB أو NB.

xyzzer يبدو أن جعل NumberBox أكثر مرونة لأي نوع من المدخلات الرقمية فكرة جيدة بالنسبة لي. يمكن اشتقاقه من عنصر تحكم TextBox ، ويمكن أن يكون لعنصر التحكم هذا خاصية Mask ، بالإضافة إلى خصائص سلوكية أخرى.

بعض هذه الخصائص على NumberBox يمكن أن تكون:

• إظهار / إخفاء أزرار الدوران
• السماح بزيادة القيم وإنقاصها
• السماح بحساب القيم
• السماح بإدخال مقنع
• أقنعة مترجمة مثل أرقام الهواتف أو عناوين IP

الخصائص التي يمكن إضافتها إلى TextBox يمكن أن تكون:

• خاصية القناع - سلسلة XAML لتحديد تنسيق مخصص ([email protected]) بالإضافة إلى الأقنعة المترجمة مثل الرموز البريدية / الرموز البريدية
• عرض نص البادئة / اللاحقة (_http: // _ كبادئة على سبيل المثال)
• إظهار / إخفاء زر الإجراء - مع رمز والنقر فوق خاصية الحدث
• الرمز (يعرض مربع بحث Fabric UI رمزه على اليسار ويتم تنشيطه عندما يتم التركيز على المربع)

هذه الصور هي من Fabric UI TextField - وهي تدعم كل هذه الحالات المختلفة - يجب أن نهدف إلى جلب عناصر تحكم Fluent WinUI 3.0 إلى التكافؤ حيثما أمكن ذلك

أزرار Fabric UI Spinner صغيرة جدًا بحيث لا يمكن لمسها ، لذا أود تنسيقها بشكل مختلف بحيث يكون الأزرار لأعلى ولأسفل جنبًا إلى جنب ، وليست مكدسة فوق بعضها البعض

بالنسبة لي ، يجب أن يكون التحقق من الصحة أمرًا ضروريًا ، كما أن الإخفاء أمر جيد. لم أحب ابدا اخفاء؛ إنه جامد للغاية.

rudyhuyn اقترح على مستودع Windows Calculator ميزة رائعة. mdtauk علق عليه.

يمكنك فتح نافذة منبثقة للحاسبة من NumberBox مشابهة لمنتقي التاريخ / الوقت / التقويم.

على غرار ما قاله xyzzer أعلاه. هناك اختلاف جوهري بين الرقم والسلسلة التي تحتوي على سلسلة من الأرقام.
أفضل طريقة سمعت بها عن الاختلاف الموصوف هي أنه يمكنك إجراء عمليات الضرب والقسمة على رقم. يمكنك طلب نصف عدد والقسمة على اثنين. لا يمكنك طلب نصف رمز بريدي أو "رقم هاتف" والحصول على شيء ذي معنى.

يمكن أن يؤدي مزج NumberBox المحدد الذي يحتوي على قدرات رياضية مع وظائف لالتقاط قيم أخرى تتكون من أرقام إلى مشكلات أخرى أيضًا.
قد تبدأ "أرقام الهواتف" بالأصفار البادئة (أو علامة الجمع) وهناك يكون لها معنى. لعدد _ لا يفعلون ذلك وسيتم تجريدهم.
غالبًا ما يتم تنسيق "أرقام الهواتف" أيضًا باستخدام أقواس وواصلات. عند معالجتها كعمليات رياضية ، يمكن بسهولة تفسيرها على أنها تتطلب الضرب والطرح.

السماح بالإخفاء بنفس طريقة TextBox وكطريقة لتنسيق المدخلات يخاطر بإرباك الفرق بين NumberBox و TextBox ومتى يجب استخدام كل منهما.

يعد التحقق البسيط من عندما يأتي التحقق من الصحة إلى النظام الأساسي ، فإن هذا لا ينتج عنه طرق متضاربة للتحقق أو شيء يمكن أن ينتهي به الأمر بسهولة إلى دفع المطورين لنشر التحقق من الصحة إلى مواقع متعددة .

سأحتفظ بالتحقق لأستند فقط إلى هذه الخصائص:

• أقصى قيمة
• الحد الأدنى للقيمة
• AllowDecimalPlaces

بشكل منفصل ، يجب أن يكون هناك إشارة إلى

• ناتج غير صالح من الحسابات
• كيفية التعامل مع القيمة المدخلة / الملصقة / المحسوبة وما يتم استخدامه في الربط. هناك حاجة لعرض العملية الحسابية أو القيمة غير الصالحة لإثبات أنها غير صالحة ولكن لا يمكن تمرير هذا إلى أي خاصية دعم ،

ستحتاج الأقنعة إلى تحمل بصري لتوضيح ما هو مطلوب ، بينما لن يتم استخدام مدخلات الحساب الأساسية جنبًا إلى جنب مع المدخلات المقنعة.

يبدو أن عناصر التحكم في نص Fabric Web تتعامل مع هذا بشكل جيد - ولكن بالطبع نطاق NumberBox منفصل عن التحسينات العامة والملائمة النهائية لعنصر التحكم TextBox الافتراضي.

الأزرار الدوارة (وربما القائمة المنبثقة الاختيارية للحاسبة) هي الأشياء المرئية الوحيدة التي تبدو خاصة بـ NumberBox.

بالنسبة للخصائص ، ربما إذا تم تمكين أزرار لوحة المفاتيح لأعلى ولأسفل لتغيير القيمة - يمكن تضمين قيمة الخطوة حتى تتمكن من اختيار مقدار الزيادة أو الإنقاص عند الضغط على المفتاح.

mdtauk ، تعجبني قيمة الخطوة ، ولكن ليس فقط عند الضغط على المفتاح. أيضًا على زر التمرير وأعلى / لأسفل.

sonnemaf بالتأكيد ، الخطوة جيدة لشيء ثنائي مثل علامة عجلة الماوس أو الضغط على مفتاح أو مفتاح لأسفل. ربما المسافة المقطوعة بعيدًا عن الصندوق يمكن أن تزيد من مقدار الخطوة؟

إذن StepMinimum و StepMaximum ربما؟

إذن StepMinimum و StepMaximum ربما؟

ليس لدي أي فكرة عما قد تتعلق به هذه القيم أو ما يمكن توقعه بالنسبة لهم.
إذا كان الغرض من "الخطوة" هو تحديد الزيادات ، فسمها "زيادة".

سيسمح هذا Max:100 Min:0 Increment:10 بالسماح فقط بتحديد القيم 0 و 10 و 20 و 30 و 40 و 50 و 60 و 70 و 80 و 90 و 100.

قد يؤدي تغيير مقدار الخطوة / الزيادة بناءً على المسافة المقطوعة إلى تغييرات غير متوقعة في القيمة. إذا كان الغرض من عنصر التحكم هذا هو تسهيل تحديد القيم الرقمية ، فعندئذٍ إذا بدأت القيمة تتغير بكميات متفاوتة ، فمن المحتمل أن أجد هذا الأمر محبطًا للغاية والذي من شأنه أن يهزم الهدف الأساسي المتمثل في وجود عنصر تحكم مخصص لتسهيل الأمر.

mrlacey أستخدم الخطوة لأنها الخاصية المسماة لشريط التمرير وأشرطة التقدم ، ولكن يمكن استخدام الزيادة إذا كانت مفضلة. لا ترتفع القيمة وتنخفض طالما لم يتم الخلط بين الزيادة وبين زيادة القيمة فقط.

يوجد اقتراح للنقر والسحب لأعلى أو لأسفل لزيادة القيمة أو تقليلها. إذا كان المستخدم يتوقع تغيير القيمة بشكل أسرع ، فكلما قمت بالسحب لأعلى أو لأسفل ، فإن وجود قيمة Stap Min و Max سيسمح للمطور بالتحكم في ذلك مع تغير دلتا. لذلك يمكن أن تتخطى مسافة السحب الصغيرة 0.1 أو 1 - لكن السحب أكثر يمكن أن يتغير بخطوات 5 أو 10 على سبيل المثال.

أنا لا أقول أن مسافة السحب يجب أن تغير سرعة تغيير القيمة - فقط لأنها فكرة قد تكون مفيدة ، إذا شعرت أنها طبيعية وأعطت المستخدم بعض الشعور بالثقة والتحكم.

ردود فعل رائعة للجميع! لقد فتحت المواصفات والعلاقات العامة لبدء العمل على التفاصيل.

KevinTXY سينضم إلي كمطور لهذا التحكم. سنبقي محادثة المتطلبات مستمرة هنا ونبدأ في API / مثال محادثة محددة على العلاقات العامة.

يرجى الشعور بالتشجيع للانضمام إلي في كتابة المواصفات.

تُعد مواصفات TeachingTip مثالاً مميزًا تمامًا لما ستبدو عليه المواصفات النهائية. سيكون المخطط الرئيسي هو:

• وصف
• أمثلة لكل واجهة برمجة تطبيقات / ميزة
• القواعد الارشادية
• API (IDL)

الأفكار العظيمة ، أحب أين يذهب كل هذا. إضافة سنتي:

• بدون شك ، أعتقد أن هذا يجب أن يكون NumberBox منفصلًا بدلاً من التكامل مع TextBox. علاوة على ذلك ، هناك الكثير من الميزات الجيدة التي تمت مناقشتها هنا ولكن يجب علينا أيضًا الحفاظ على NumberBox خفيف الوزن. لذلك ، أقترح اشتقاق CalculatorBox أو شيء مشابه من NumberBox والذي يمكن أن يحتوي على مدخلات متقدمة "2 + 3" أو زر لفتح آلة حاسبة.
• يحتاج التوطين إلى التفكير جيدًا في المواصفات مسبقًا. بالإضافة إلى ذلك ، هناك حالات تريد فيها تجاوز واجهة المستخدم المحلية. لذلك ، قد يكون تعيين خاصية NumberformatInfo أو CultureInfo مفيدًا جدًا. على سبيل المثال ، في بعض التطبيقات يتم تعقب قيمة أجنبية ومحلية. يمكن أن يكون كل تنسيق مختلف.
• يحتاج عنصر التحكم إلى دعم نقل منزلة عشرية. هذا أكثر صعوبة من مجرد التحقق من صحة تنسيق على كل نص تم تغييره. يجب تتبع كل إدخال حرف واستبدال المكان العشري السابق حسب الحاجة.
• يجب أن تكون أي أسهم زيادة / إنقاص قابلة للتهيئة لإيقاف تشغيلها للحصول على مربع إدخال عادي فقط - مرة أخرى نحتاج إلى عنصر تحكم خفيف الوزن هنا للحالات المطلوبة كجزء من عناصر التحكم الأخرى.
• هناك شيء آخر لم تتم مناقشته وهو أننا بحاجة إلى دعم أنواع متعددة بشكل مثالي - عشري ، وعدد صحيح ، وربما طويل ، ومزدوج ، وما إلى ذلك ... قد يغير هذا كثيرًا من الأشياء بشكل أساسي ولم أفكر في ذلك بشكل كامل حتى الآن. .
• يجب أن تكون القيمة بالتأكيد لاغية. تختلف القيمة غير المحددة عن الصفر.
• هناك فكرة أخرى غير مهمة وهي السماح بتحديد الدقة العشرية للأنواع العشرية أو المزدوجة أو العائمة.

أنا متأكد من أن المزيد من الأفكار ستتبع. إنني أتطلع إلى قراءة المواصفات!

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

لدي المواصفات / العلاقات العامة المملوءة بواجهات برمجة التطبيقات وأمثلة لكل منها. أعتقد أنني تناولت التنسيق وفقًا لمواصفاتك من خلال تعداد للأنواع الأساسية المحددة مسبقًا (لا تزال قيد التقدم) بالإضافة إلى خاصية التنسيق المخصصة التي ستتجاوز الأنواع المحددة مسبقًا إذا تم تعيينها.

يرجى التحقق من ذلك وإخباري إذا لم يحل مخاوفك أو إذا كان من الممكن إضافته أو تحسينه. سأقبل طلبات السحب التي تساهم في المواصفات المطلوبة هنا.

• لوحظ التحقق من الصحة كضرورة. لقد وصفت عنصر التحكم هذا للاشتقاق من TextBox للحصول على إخفاء وخصائص داعمة أخرى مجانًا.

• لمخاوفmrlacey ، أضفت واجهة برمجة تطبيقات لتمكين / تعطيل تجريد الأصفار البادئة التي يمكن استخدامها جنبًا إلى جنب مع سلسلة التنسيق المخصص لتمكين سيناريوهات إدخال سلسلة رقمية مخصصة (مع ملاحظة أن أرقام الهواتف الدولية وعناوين IP موجودة بالفعل في قائمة أنواع التنسيقات الأساسية المحتملة).

• يقترن هذا بالقدرة على تمكين / تعطيل دعم الآلة الحاسبة ، بالنسبة لي ، يهبط التقاطع لعنصر تحكم يمكن أن يكون خفيف الوزن للقيم / السلاسل الرقمية ولكنه يوفر أيضًا دعمًا كافيًا للحساب والتخصيص. أعتقد أن إيجاز الأمثلة يسلط الضوء على هذا ، لكنني مهتم بسماع أي شخص يعتقد أن هذا سيجعل استخدام التحكم المحتمل أكثر تعقيدًا.

• sonnemaf أقدر حداثة وبديهية الأيقونة> مثال على الآلة الحاسبة المنبثقة. بالنسبة لي ، هذا مشتق من مفهوم CalendarDatePicker ويمكن أن يكون اعتبارًا ممتازًا لميزة V2 ما لم يكن هناك دفعة قوية من الجميع هنا يجب أخذها في الاعتبار لـ V1؟

قد تكون الآلة الحاسبة المنبثقة منطقية إذا كان هناك تنسيق مع جهود الحاسبة مفتوحة المصدر. كلاهما من أجل التناسق في مظهر Calculator Flyout ، ولكن أيضًا في المحرك خلفه.

لست متأكدًا مما إذا كان هذا هو المكان المناسب لنشر هذه الصورة ، ولكن إليك تصميمات للحالات المختلفة التي تتوافق مع المواصفات.

الصورة بمقياس 200٪

mdtauk ما هو الغرض من

ما الحالة التي تحاول كل صورة إظهارها؟ بدون توضيح ذلك ، قد نقوم بعمل افتراضات مختلفة عن افتراضاتك.

هل يُقصد بها أن تكون مراجع مثالية بالبكسل؟

هل يمكنك تحديد مكان اختلاف شيء ما في صورك عن الإعداد الافتراضي للنظام الأساسي أو عنصر التحكم الأساسي بحيث يكون من الواضح ما (إذا كان هناك أي شيء) الذي تضيفه أو تغيره.

mrlacey يمكنني

والغرض منها هو محاولة توضيح كيف يمكن أن تبدو عناصر التحكم هذه مع عناصر التحكم المختلفة المقترحة مثل البادئة واللاحقة والأقنعة والأزرار لأعلى ولأسفل. يتم استقراءها من تصميمات التحكم في FabricWeb ، ولكن باستخدام عناصر XAML مثل FocusReveal والتحكم في حجم الأزرار.

توضح الأمثلة Rest - Focus - Disabled state

ستكون الآلة الحاسبة المنبثقة ميزة رائعة لـ V2.

لست متأكدا من أين أضع ملاحظاتي. هل يجب أن أقوم بعمل علاقات عامة على المواصفات أم يمكنني الاستمرار في كتابة أفكاري في هذه المسألة؟

عدد صحيح

هل ستكون قيمة عدد صحيح لـ NumberBoxFormatType مفيدة؟

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

لغة

هل ستستخدم اللغة لتحديد العملة ، رموز تجميع الأرقام العشرية؟

في المثال التالي ، يتم تعيين اللغة على nl-NL. هل هذا يعني أن البادئة هي علامة اليورو ، والرمز العشري هو فاصلة بعدها بكسران عشريان وتجميع الأرقام عبارة عن نقطة؟ العملة السلبية لها علامة ناقص في المقدمة ولا يوجد أقواس كما هو الحال في الولايات المتحدة.

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

هل هذا كافٍ نظرًا لوجود العديد من خيارات تنسيق الأرقام والعملات في Windows.

قيمة الممتلكات أو الممتلكات

هل نحتاج إلى خاصية Value وما هو النوع (الرقمي) الذي ستكون عليه. سأستخدمه لتوثيق البيانات. هل يجب أن يكون رقمًا مزدوجًا أم عشريًا أم عدد صحيح. هل نحتاج إلى دعم Nullable (ضعف؟ ، عشري ؟، int؟). لا أريد استخدام خاصية Text لعنصر تحكم TextBox الموروث لتجميع البيانات. نحن بحاجة إلى دعم النظام العشري أيضًا ، المضاعفة ليست كافية.

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

ماذا لو كانت خاصية الراتب للموظف لاغية(عدد عشري؟). هل نحتاج إلى خاصية التبعية ValueNullableDecimal. التاريخ المحدد لعنصر تحكم منتقي التاريخ هو Nullable. Nullable مشكلة خاصة مع ربط البيانات.

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

نفس الشيء مع MinValue و MaxValue. هم الآن عدد صحيح في المواصفات ولكن ألا ينبغي أن يكون هذا مزدوجًا ؟.

sonnemaf لأن المواصفات تقول أن عنصر التحكم مخصص لأي شيء يمكن إدخال الأرقام فيه ، أعتقد أن هذا يعني أنه يتعامل مع "القيمة" كنص ويعتمد على الشفرة المستهلكة للتحويل حسب الضرورة. إنه ليس مثاليًا ولكن حتى إذا كان هناك خاصية Value طويلة أو عائمة ، فلا يزال هناك الكثير من المناسبات التي تكون فيها التحويلات ضرورية.
إنه أفضل من الأحمال الزائدة لكل نوع رقمي.
ثم هناك أشياء يتم تصميم عنصر التحكم من أجلها ولا يمكن تحويلها إلى نوع "رقمي" ، مثل الرمز البريدي للولايات المتحدة أو رقم الهاتف أو عنوان IP. بالنسبة لهذه الأنواع من القيم ، يبدو أن الحصول على النص هو الخيار الأفضل (فقط).
أعتقد أنه من الأسهل (على الأقل في الإصدار الأولي الحصول على طريقة واحدة للوصول إلى القيمة المدخلة والاعتماد على المحولات عند الضرورة. يمكنني رؤية مكان لمجموعة من المساعدين (أو الفئات الفرعية) قادمون إلى مجموعة الأدوات في البداية ثم بعض يتم دمجها في عنصر التحكم الرئيسي بناءً على التعليقات.

هل خاصية Language ضرورية؟ لماذا لا يكون هذا هو نفسه UILocale؟ قد تكون هناك أسباب وجيهة ، ولكن يبدو أن هذا يجب أن يكون قابلاً للتكوين من قِبل المستخدم (على مستوى نظام التشغيل) وقد يؤدي منح القدرة على تحديد تنسيق معين إلى المزيد من المشكلات للمطورين عندما لا يتطابق التنسيق في مكان آخر أو ما يستخدمه المستخدم التطبيق يريد. بعيدًا عن رأسي: ماذا لو لصق أحدهم قيمة بتنسيق مختلف؟

mdtauk ما هو الغرض من

ما الحالة التي تحاول كل صورة إظهارها؟ بدون توضيح ذلك ، قد نقوم بعمل افتراضات مختلفة عن افتراضاتك.

هل يُقصد بها أن تكون مراجع مثالية بالبكسل؟

هل يمكنك تحديد مكان اختلاف شيء ما في صورك عن الإعداد الافتراضي للنظام الأساسي أو عنصر التحكم الأساسي بحيث يكون من الواضح ما (إذا كان هناك أي شيء) الذي تضيفه أو تغيره.

mrlacey هل هذا هو نوع الشيء الذي كنت تريده؟

mdtauk هذا أفضل قليلاً لأنه يشرح بعض ما تحاول إظهاره.

لا يزال السؤال الأساسي مطروحًا: ما هو هدفك من إظهار هذا؟ هل هي مجرد فكرة؟ هل هي نسختك المفضلة بعد استكشاف الأفكار المختلفة؟ إذا كان الأمر كذلك ، فلماذا هذه هي الأفضل / المفضلة؟

إن مقارنة عناصر التحكم الحالية بالطريقة التي تريد أن تظهر بها عناصر التحكم الجديدة في الأنماط العريضة للنظام الجديدة المفضلة لديك تعني أنه لا يمكن فصل ما هو محدد لعنصر التحكم مع ما هو موجود في الأنماط الواسعة للنظام المفضل لديك.

على سبيل المثال ، ذكرت تغيير الشفافية على الحدود. هل هذا التغيير مخصص لجميع عناصر التحكم أم هذا فقط؟ وفي أي دول؟

قد يكون إعطاء أحجام صريحة (للأزرار) مشكلة في تركيبات التصميم حيث لا يتم ترجمتها دائمًا بشكل متساوٍ بناءً على حجم الحاوية الخاصة بهم التي يتم تغيير حجمها. هل يجب أن تكون دائمًا مربعة؟ أم أن عرضها ثابت على أساس ارتفاع التحكم الافتراضي؟

كيف تقترح فرشاة الخلفية للبادئات واللواحق؟ أفترض وجود فرشاة نظام ، لكن أي واحدة؟

الإخفاء غير مشمول في هذه المواصفات. هل الغرض من الأمثلة "المقنعة" الخاصة بك هو الارتباط بسلاسل التنسيق؟
كيف يتوافق المثال المقنع مع التنسيق؟
أفترض أنك مثال يعرض إدخال عنوان IP للإصدار 4 ولكن يبدو أن هناك الكثير من الافتراضات بناءً على مدى دقة كل شيء يبدو مناسبًا. هل يجب أن تحتوي جميع القيم غير القابلة للإدخال على خلفية وهوامش؟ ماذا لو لم يتم عرضها دائمًا؟ هل يجب توسيع المحتوى ليناسب كل المساحة المتاحة ، كما يبدو في مثالك؟ كيف ستتم معالجة المساحة المخصصة للقيم غير القابلة للإدخال عند تحريك محتوى أكبر من المساحة المتاحة؟

mdtauk هذا أفضل قليلاً لأنه يشرح بعض ما تحاول إظهاره.

لا يزال السؤال الأساسي مطروحًا: ما هو هدفك من إظهار هذا؟ هل هي مجرد فكرة؟ هل هي نسختك المفضلة بعد استكشاف الأفكار المختلفة؟ إذا كان الأمر كذلك ، فلماذا هذه هي الأفضل / المفضلة؟

إن مقارنة عناصر التحكم الحالية بالطريقة التي تريد أن تظهر بها عناصر التحكم الجديدة في الأنماط العريضة للنظام الجديدة المفضلة لديك تعني أنه لا يمكن فصل ما هو محدد لعنصر التحكم مع ما هو موجود في الأنماط الواسعة للنظام المفضل لديك.

على سبيل المثال ، ذكرت تغيير الشفافية على الحدود. هل هذا التغيير مخصص لجميع عناصر التحكم أم هذا فقط؟ وفي أي دول؟

لم تتضمن مواصفات NumberBox أي أمثلة مرئية ، وتعد الصور الموجودة في الاقتراح الأصلي أمثلة تقريبية للوظائف. هناك PR # 524 آخر حيث يتم تحديث قوالب التحكم بقيم CornerRadius في 2epx ، وهو أيضًا نفس التقريب المستخدم بواسطة Fabric Web.

لذا ، بافتراض أن عناصر التحكم المشتقة من TextBox سيتم تحديثها أيضًا بشكل مشابه ، فقد استخدمت ذلك كدليل لإظهار كيف يمكن أن تتناسب الوظيفة المقترحة لـ NumberBox مع ذلك. تمتلك حقول نص الويب النسيجية بالفعل دعمًا لقيم البادئة واللاحقة ، لذلك أخذت هذا التصميم للتو ، واستخدمت مقاييس XAML.

قد يكون إعطاء أحجام صريحة (للأزرار) مشكلة في تركيبات التصميم حيث لا يتم ترجمتها دائمًا بشكل متساوٍ بناءً على حجم الحاوية الخاصة بهم التي يتم تغيير حجمها. هل يجب أن تكون دائمًا مربعة؟ أم أن عرضها ثابت على أساس ارتفاع التحكم الافتراضي؟

يحتوي TextBox الحالي على بعض الأزرار المدمجة ، مثل SearchBox ، وزر كشف كلمة المرور ، وزر مسح النص. تقترح أهداف اللمس لـ XAML أن تكون الأزرار 32 × 32 epx - لقد أبقيتها مربعة واستخدمت هذا التوجيه.

كيف تقترح فرشاة الخلفية للبادئات واللواحق؟ أفترض وجود فرشاة نظام ، لكن أي واحدة؟

في المثال الخاص بي ، استخدمت Theme Foreground Color ولكن باستخدام Opacity بنسبة 15 ٪. تستخدم وحدات FabricWeb ما يقرب من 10٪ ، وتستخدم أزرار XAML 20٪.
توجد قيم فرشاة مماثلة مثل ListLowBrush ولكنها قد تحتاج إلى فرشاة TextBoxAppendixBackground جديدة. ستستخدم مقدمة النص نفس فرشاة PlaceholderTextForeground.

الإخفاء غير مشمول في هذه المواصفات. هل الغرض من الأمثلة "المقنعة" الخاصة بك هو الارتباط بسلاسل التنسيق؟
كيف يتوافق المثال المقنع مع التنسيق؟
أفترض أنك مثال يعرض إدخال عنوان IP للإصدار 4 ولكن يبدو أن هناك الكثير من الافتراضات بناءً على مدى دقة كل شيء يبدو مناسبًا. هل يجب أن تحتوي جميع القيم غير القابلة للإدخال على خلفية وهوامش؟ ماذا لو لم يتم عرضها دائمًا؟ هل يجب توسيع المحتوى ليناسب كل المساحة المتاحة ، كما يبدو في مثالك؟ كيف ستتم معالجة المساحة المخصصة للقيم غير القابلة للإدخال عند تحريك محتوى أكبر من المساحة المتاحة؟

لن أتظاهر بأن لدي كل الإجابات عن هذا ، وكيف يتم عرضه بشكل مرئي على عنصر التحكم سوف ينخفض ​​إلى كيفية تنفيذ تنسيق القناع في عناصر التحكم.

لقد استخدمت عنوان IP v4 لأنه المثال المميز في المواصفات ، وكان هدفي الأصلي هو توضيح ما تم اقتراحه (على الرغم من عدم توفر أمثلة البادئة واللاحقة ، لذلك اخترت قيمًا أخرى)

لقد ألقيت نظرة على كيفية تعامل عناصر التحكم الأخرى مع التقنيع ، ويستخدم البعض نصًا مضمنًا يحرك علامة الإقحام كقيم يتم إدخالها. سيقوم الآخرون بإدخال أشياء مثل الأقواس والواصلات عند إدخال رقم الهاتف. يستخدم البعض علامات الجدولة أو مفاتيح الأسهم للتنقل بين المقاطع. أقرب مثال من Microsoft يتبادر إلى الذهن هو إدخال مفاتيح المنتج أثناء تثبيت Windows.

اعتقدت أن استخدام نفس التصميم مثل العناصر الملحقة ، من شأنه أن يتناسب مع الجمالية ، لكنني أدرك أن هذا يضيف إلى طول عنصر التحكم ليناسب كل شيء ، وقد يستخدم المضمّن المساحة بشكل أفضل.

مجرد ملاحظة أثناء عملي مع TextBox الآن ، لا يوجد حدث واحد للإشارة إلى تغيير القيمة من قبل المستخدم (على سبيل المثال ، اتحاد التركيز المفقود والضغط على مفتاح الإرجاع) ، على غرار https://doc.qt.io /qt-5/qlineedit.html#textEdited سيكون من الرائع وجود ذلك في NumberBox كما هو مخصص لهذا النوع من التعديلات. بالمناسبة ، إذا كان سيتم التعامل مع جميع أنواع القيم مثل عناوين IP ، فربما يكون مربع "الرقم" ضيقًا جدًا من الاسم؟ يمكن أن يكون ValueBox أو نحو ذلك

adrientetar يبدو NumberBox جيدًا كاسم ، لأنه يتم احتساب جميع المدخلات كأرقام. يحتوي عنوان IP على 4 أرقام وأرقام هواتف وعملة وقياسات وما إلى ذلك.

DigitBox و NumeralBox وما إلى ذلك كلها متغيرات لا تتناسب تمامًا مع أسلوب تسمية Microsoft.

لا يلزم أيضًا أن تكون القيم رقمية بطبيعتها ، لذا يمكن أن يكون ValueBox مضللًا بعض الشيء.

sonnemaf و mdtauk ، لقد تحدثت إلى فريقي حول فكرة الآلة الحاسبة المضمنة وباختصار نحن

سأحتاج إلى بعض المساعدة منك لتحقيق ذلك. الطريقة التي نبقى بها على رأس مجموعة الأفكار الرائعة التي تأتي من خلال إعادة الشراء لدينا هي ألا تكون مدفوعة بالأفكار فحسب ، بل مدفوعة بالسيناريو أيضًا. (أشارك هذا لأن التحدث بهذه اللغة سيمنح طلبات الميزات الخاصة بك نفوذًا ملموسًا في جميع أنحاء الريبو الخاص بنا.)

هل يمكن لأي منكما تمكينني بسيناريوهات حقيقية لآلة حاسبة مضمنة في أي من التطبيقات التي تطورها؟ السياق ، لقطات الشاشة ، ملفات تعريف المستخدم كلها مساعدة. (بريدي الإلكتروني هو أيضا على ملفي الشخصي جيثب إذا كنت تفضل أن تبقي تفاصيل سرية.)xyzzer،mrlacey،robloo، @ فيليكس ديف،adrientetar، وArchieCoder، فلا تشجيعهم على تبادل السيناريو استخدامك إذا كانت هذه الميزة تهمك أيضًا.

بعد هذه الخطوة ، فإن الشيء الوحيد الذي يمكن أن يخنق هذه الميزة هو خطر تضخيم حجم DLL الخاص بـ WinUI مع محرك تطبيق الآلة الحاسبة. سأبحث في هذا بالتوازي لتحديد نطاق الجدوى.

لقد طرحت سابقًا مشكلة معالجة عنصر التحكم هذا لأكثر من مجرد أنواع رقمية.

هناك اختلاف جوهري بين الرقم والسلسلة التي تحتوي على سلسلة من الأرقام.

كان هذا قبل نشر المسودة الأولى للمواصفات ، لذا أفترض أن هذا قد تم النظر فيه واتخاذ قرار جعل عنصر التحكم هذا يتعامل مع "القيم الرقمية التقليدية" وكذلك "السلاسل التي تحتوي على أرقام رقمية".

لا أعتقد أن أي شخص سيحاول حقًا أن يجادل بأن عنوان IPv4 كان "رقمًا" بأي تعريف آخر غير أنه لا يتم تمثيله عادةً كتسلسل منسق من الأرقام. في الواقع ، إنها مجرد قيمة 4 بايت.

تضمين التغريدة

• ربما إدخال المصاريف - إدخال تلك العناصر من إيصال حيث تكون بعض العناصر شخصية والبعض الآخر جزء من العمل.
• تطبيق مطعم عند تقسيم الفاتورة ، أو ربما حساب الإكرامية؟
• تطبيق تحرير سداسي عشري ، لحساب قيمة الإزاحة لنقل التحديد إلى؟

سيكون وجود عنصر تحكم يدعم عناوين IP إضافة رائعة إلى النظام الأساسي ولكن لا أعتقد أن NumberBox هو التحكم الصحيح لهذا السيناريو.

كما ذكرنا من قبل ، فإن التحكم في NumberBox من شأنه:

• استخدم لوحة المفاتيح الافتراضية Number عند استخدامها على جهاز بدون لوحة مفاتيح فعلية
• لديك 2 زر - / +
• عرض نافذة منبثقة مع آلة حاسبة أو السماح للمستخدم بكتابة العمليات الحسابية الأساسية

لا معنى لأي من هذه الميزات مع عنوان IP. حتى تصميم عنصر التحكم مختلف جدًا.

علاوة على ذلك ، يجب أن نضع في اعتبارنا أنه إذا كنا ندعم عناوين IPv4 ، فيجب علينا أيضًا دعم عناوين IPv6 ، وليس باستخدام الأرقام ولكن باستخدام الأرقام السداسية العشرية.

أعتقد أنه سيكون من المنطقي عدم تضمين دعم عنوان IP في عنصر التحكم هذا ولكن بدلاً من ذلك ، العمل على عنصر تحكم جديد MaskedTextBox لـ UWP (دعم IPv4 ، IPv6 ، رقم الهاتف ، الرمز البريدي ، SSN ، إلخ ...) باستخدام واجهة مستخدم غنية (كما هو موضح بواسطةmdtauk) لاستبدال / تحسين TextBoxMask من مجموعة أدوات المجتمع (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

سيكون وجود عنصر تحكم يدعم عناوين IP إضافة رائعة إلى النظام الأساسي ولكن لا أعتقد أن NumberBox هو التحكم الصحيح لهذا السيناريو.

كما ذكرنا من قبل ، فإن التحكم في NumberBox من شأنه:

• استخدم لوحة المفاتيح الافتراضية Number عند استخدامها على جهاز بدون لوحة مفاتيح فعلية
• لديك 2 زر - / +
• عرض نافذة منبثقة مع آلة حاسبة أو السماح للمستخدم بكتابة العمليات الحسابية الأساسية

لا معنى لأي من هذه الميزات مع عنوان IP. حتى تصميم عنصر التحكم مختلف جدًا.

علاوة على ذلك ، يجب أن نضع في اعتبارنا أنه إذا كنا ندعم عناوين IPv4 ، فيجب علينا أيضًا دعم عناوين IPv6 ، وليس باستخدام الأرقام ولكن باستخدام الأرقام السداسية العشرية.

أعتقد أنه سيكون من المنطقي عدم تضمين دعم عنوان IP في عنصر التحكم هذا ولكن بدلاً من ذلك العمل على عنصر تحكم جديد MaskedTextBox لـ UWP (دعم IPv4 ، IPv6 ، رقم الهاتف ، الرمز البريدي ، SSN ، إلخ ...) باستخدام واجهة مستخدم غنية (كما هو موضح بواسطةmdtauk) واستبدال / تحسين TextBoxMask من مجموعة أدوات المجتمع (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

rudyhuyn أنا أتفق في الغالب مع ما قلته للتو هنا ، وكانت الرسوم التوضيحية الخاصة بي مخصصة للمواصفات المقترحة.

ولكن كما ذكر آخرون ، لا يجب أن يقتصر مربع النص المقنع على الأرقام فقط ، ويمكن أن يتضمن سلاسل أيضًا. يعد مربع Microsoft Product Key مثالاً جيدًا ، حيث يتم قبول 5 مجموعات من 0-9 أحرف AZ.

حتى لو تم فصل Masking ، ما زلت أعتقد أن هناك حالات استخدام جيدة لتضمين خصائص PrefixText و SuffixText إلى عنصر التحكم NumberBox. العملة والقياسات ، كلها تتطلب نوعًا من السياق.

أزرار التدوير مخصصة فقط لزيادة القيم وإنقاصها ، لذلك تقع هذه الأزرار أيضًا ضمن نطاق عنصر تحكم NumberBox.

يمكن أن تصبح البادئة واللاحقة خصائص لعنصر التحكم TextBox نفسه ، وبالتالي موروثة بواسطة عناصر التحكم الأخرى. (قد يكون هناك استثناء لـ PasswordBox إذا فتح أي ثغرات أمنية)

يمكن أن تكون أقنعة القيم المشتركة تعدادًا (جنبًا إلى جنب مع CustomFormatMask) لعنصر التحكم المنفصل هذا. قد تتضمن بعض هذه الأقنعة سياق ثقافي ، مثل الرمز البريدي للمملكة المتحدة الذي يكون أبجديًا رقميًا ، وأرقام التأمين الوطني في المملكة المتحدة بعد تنسيق خاص وما إلى ذلك.

SW1A 2AA

مثال على الرمز البريدي في المملكة المتحدة (رقم 10 داونينج ستريت)

يبدو أنني لم أنجح في تحديث الصفحة هذا الصباح قبل إرسال ردي ... شكرًا لكم جميعًا يا نجوم موسيقى الروك لأخذ هذا الاقتراح إلى مستوى جديد تمامًا! أعلم أن الكلمات أفرطت في استخدامها على GitHub ، لكنني أعني ذلك!

mdtauk - النماذج الخاصة بك رائعة. لم أقم بعد بصياغة نماذج أولية لتصميمات عنصر التحكم هذا. هل يمكنني تقسيم النموذج الخاص بك وإضافته إلى المواصفات كنماذج أولية للمصممين لدينا لبدء لوحة الألوان الخاصة بهم؟ سأتواصل وأطلب مصممًا اليوم وأرى ما إذا كان بإمكاني حثهم على الرد على سلسلة mrlacey هنا. سأقرأ موضوعك وأرد عليه بتفاصيل أكثر دقة بعد قليل.

sonnemaf ، شكرا لك مرة أخرى! أود أن أشجعك على نسخ تعليقك وإعادة نشره هنا في علامة تبويب محادثة طلب السحب . هذا هو المكان الذي سيبدأ فيه فريقنا الهندسي الانخراط في واجهة برمجة التطبيقات ومستوى التنفيذ. من أجل تقديم إجابة شاملة ، هنا أيضًا أبدأ في صياغة المبادئ التوجيهية والتوثيق. سأقدم تعهدات بـ [DEV] للأولى و [PM] للأخيرة. بخلاف ذلك ، لا يزال هذا المنتدى مناسبًا لمناقشة المتطلبات عالية المستوى (مثل الآلة الحاسبة المضمنة ونماذجmdtauk ).

mdtauk : أتفق معك ، البادئة / اللاحقة ستكون إضافة جيدة لـ TextBox ولا تقتصر على الأرقام ، بعض الأمثلة:

• اطلب من الموظف إدخال عنوان بريده الإلكتروني عندما يكون المجال هو نفسه دائمًا (@ microsoft.com على سبيل المثال).
• أدخل اسم النموذج عندما يبدأ دائمًا بـ W-

إلخ...

يجب عليك فتح تذكرة أخرى حتى نتمكن من بدء مناقشة حولها!

rudyhuyn هل ترى القدرة على عدم دعم شيء مثل عنوان IP ولكن القدرة على دعم رقم هاتف أو رمز بريدي كعملية؟
فكرتي هي أنك إذا بدأت في تقييد بعض الأشياء دون غيرها ، فيجب تحديد القواعد الخاصة بما يتم تغطيته بوضوح شديد.
إن مجرد دعم القيم التي يمكن أن تظهر على شكل عدد صحيح ، أو عدد عشري ، وما إلى ذلك يجعل الأمور واضحة جدًا ولا يزال يخلق عنصر تحكم يوفر الكثير من القيمة.

SavoySchuler تصاميمي تحت تصرفك بالكامل ، لقد قمت بنشرها لمحاولة المساعدة في تصور التحكم لكل شخص يساهم.

rudyhuyn إذا كنت

أرقام الهواتف mrlacey (بصرف النظر عن أحرف التنسيق) هي أرقام نقية - لكنها لا تندرج تحت أي نوع من حالات الاستخدام الحسابية ، فهل تناسب TextBox المقنع بشكل أفضل ، أم أن هناك قيمة في توفير الدعم لها في NumberBox؟

عند إنشاء عنصر التحكم والوثائق التي توفر حالة استخدام واضحة وأمثلة لاستخدام عنصر التحكم في أي سياق مهم.

mrlacey : لا أفعل.

كما قلت من قبل ، يجب أن نفصل بين الأعداد الحقيقية ، ليس فقط ما يستخدم من 0 إلى 9 أحرف ولكن يرتبط بقيمة حسابية.

يستخدم عنوان IP ورقم الهاتف و SSN والرمز البريدي من 0 إلى 9 أحرف ولكن ليس له قيم حسابية (يمكنك إضافة 2 منهم ، إذا أضفت ".00" إلى النهاية ، فإنك تغير معنى القيمة ، وما إلى ذلك) . في هذه الحالات ، تكون القيمة عبارة عن سلسلة ، وليست int / double ، سيكون MaskedTextBox أكثر منطقية.

علاوة على ذلك ، يستخدم الرمز البريدي فقط أرقامًا في الولايات المتحدة ، ولكن ليس في كندا على سبيل المثال ، يمكن أن يحتوي عنوان IPv6 على أحرف AF ، ويمكن أن يحتوي رقم الهاتف على علامة + (555-123-4567 و + 555-123-4567 هما نوعان مختلفان أرقام الهواتف) ، إلخ ...

لتلخيص رأيي ، يجب أن يكون NumberBox.Value مزدوجًا وليس سلسلة.

أرقام الهواتف mrlacey (بصرف النظر عن أحرف التنسيق) هي أرقام نقية - لكنها لا تندرج تحت أي نوع من حالات الاستخدام الحسابية ، فهل تناسب TextBox المقنع بشكل أفضل ، أم أن هناك قيمة في توفير الدعم لها في NumberBox؟

قد تتكون أرقام الهواتف بالكامل من أرقام (بالإضافة إلى التنسيق) ولكن هذا لا يجعلها أرقامًا. لا يمكنك إجراء أي نوع من العمليات الحسابية عليها والحصول على شيء ذي معنى.
أيضًا ، يمكن أن يبدأ البعض بعلامة الجمع.
كما أن عدد الأصفار البادئة في رقم الهاتف له معنى. بالنسبة للقيمة الرقمية ، فهي ليست كذلك.
الوظائف الأخرى في عنصر التحكم ، مثل العمليات الحسابية أو الأزرار لأعلى ولأسفل ، لا تعني أي معنى لـ "رقم الهاتف".

يجب أن يقتصر عنصر التحكم هذا على القيم التي يمكن تحويلها إلى int / uint أو رقم عشري دون المخاطرة بفقدان المعلومات.

للتأكد من توليف هذه التعليقات بشكل مناسب ، يرجى إعطائي إبهامًا على هذا التعليق إذا كنت تعتقد أن هذا هو أفضل مكان لجميع أنواع إدخال السلاسل الرقمية (مثل أرقام الهواتف و IPv4) من خلال أنواع التنسيقات وإبهام- لأسفل إذا كان يجب تأجيل هذه الوظيفة إلى عنصر تحكم آخر أو جديد بحيث يركز NumberBox حصريًا على الرياضيات والتقاط القيمة الرياضية. (تتطلب ملاحظة الميزات التي تدعم العمليات الحسابية مثل وضع الآلة الحاسبة والأزرار لأعلى / لأسفل التمكين عبر واجهات برمجة التطبيقات ذات الصلة.)

لا أستطيع أن أضمن أن يتم اتخاذ قرار بشأن هذا بطريقة ديمقراطية لأنني سأتخذ القرار الذي ينتج عنه أفضل عائد على الاستثمار لعملائنا على مستوى العالم - ولكنه سيساعد في التحقق مما أعتقد أنني أراه هنا: لا أحد يطلب ذلك لدعم العدد سلاسل ويفضلون عنصر تحكم مخصص لذلك.

SavoySchuler Numbers التي يمكن تشغيلها

لقد قمت للتو بالمزامنة مع الفريق هنا وأردت مشاركة التحديثات حول بعض أسئلتنا المفتوحة:

• نحن نستمع إلى ملاحظاتك ونوافق على أن NumberBox ليس المكان المناسب للسلاسل الرقمية. تم استبدال خصائص FormatKinds و CustomFormat بواجهات برمجة تطبيقات أكثر تحديدًا للتحكم في تنسيق الأرقام بطرق أكثر سهولة.
• البادئة واللاحقة تنتمي بالفعل إلى TextBox (الذي سيرثهم NumberBox منه). سأمنح mdtauk أو سأبدأ وأربطه هنا. في الوقت الحالي ، سيتجنب ذلك حظر NumberBox على إخراج الترجمة / التشغيل الآلي.
• سيتم الاحتفاظ بالتغذية النهائية في NumberBox (بعد الحساب والتقريب وما إلى ذلك) كسلسلة في خاصية Text التي تأتي من TextBox AND كمزدوج في خاصية قيمة جديدة. نعتزم الحصول على هذه التعليقات لبعضنا البعض بحيث ينعكس التغيير في أحدهما على الآخر. والغرض من ذلك هو التخلص من أكبر قدر ممكن من العمل عن يديك والحصول على القيمة الجاهزة للوصول إليها حسب حاجتك.
• كان StepSize مفقودًا كخاصية في المواصفات.
• سيتم تغيير أنواع الأعداد الصحيحة إلى Double.
• ما زلنا متحمسين لفكرة الآلة الحاسبة المضمنة ونبحث عن المزيد من السيناريوهات لمساعدتنا في تحسين ذلك. mdtauk ، شكرًا لك على الرد على هذه النقطة من التعليقات بالفعل!
• فيما يتعلق بالتحقق من صحة الإدخال ، تكمن الفكرة في إرسال حدث من نوع ValueChanged أولاً والذي سيعطي المطور الفرصة لمعالجة الإدخال أو التعامل معه عند إرسال نموذج النهاية / الكتلة حسب الحاجة. إذا لم يتم اتخاذ أي إجراء تصحيحي (مثل فرضه في غضون الحد الأدنى / الحد الأقصى ، وإزالة الأحرف غير الصالحة ، وما إلى ذلك) ، فسيعرض NumberBox بدلاً من ذلك إشارة خطأ للمستخدم حول مدخلاته. يتيح هذا النهج ذو الشقين للمطورين الاستجابة إذا فضلوا ذلك ، ولكنه يسمح أيضًا بإرجاء التصحيح للمستخدم.

كان هناك قدر هائل من التعليقات التي ما زلت أستجيب لها. شكرًا على سعة صدرك ، سأرد على الجميع هنا وعلى الريبو الخاص أيضًا!

"فن مفهوم NumberBox مع آلة حاسبة مضمنة." مجتمع WinUI ، مايو 2019 (ملون)

(مجاملة من ryandemopoulos )

SavoySchuler لقد طلبت بعض أمثلة السيناريوهات حيث يمكن استخدام نوع عنصر التحكم (عناصر التحكم) الذي نناقشه. لدي اثنان في تطبيقي قد يكونان أمثلة جيدة.

الحالة 1: يوجد محرر إعدادات للرسوم البيانية ثنائية الأبعاد حيث يمكنك ضبط المحور.

• هذا يحتاج فقط إلى إدخال رقمي بسيط. قد تكون أزرار الزيادة +/- مفيدة هنا.
• ستكون القيمة المزدوجة جيدة ولكن يجب التحقق من صحة المدخلات عند الضغط على الأحرف. يجب ألا يتمكن المستخدم من الضغط على "a" وإظهاره في مربع الإدخال. لا ينبغي أن يؤدي التحقق من صحة الإدخال إلى جعل الحدود حمراء وتحذير المستخدم - ببساطة لا ينبغي أن يكون من الممكن إدخال قيمة غير صالحة.
• يجب أن تكون الأقلمة مدعومة بالتحكم وتحريك المكان العشري (سواء كانت فاصلة أو نقطة أو ما إلى ذلك) التي يتم التعامل معها كحالة خاصة (أستمر في طرح هذا الأمر لأنه من السهل تفويته)

الحالة 2: يوجد حقل إدخال لقيمة العملة كما هو موضح أدناه. هذا عنصر تحكم مخصص "CurrencyBox"

• يمكن أن يستخدم هذا زر الآلة الحاسبة والقدرة على إدخال المعادلات 2 + 3 سيكون لها بعض القيمة هنا (ما زلت أشعر أن هذا يجب أن يكون عنصر تحكم منفصل رغم ذلك)
• القيمة المزدوجة ليست مثالية لهذا. أود أن أقترح تغيير مواصفات القيمة من ضعف إلى عشري لدعم هذا النوع من حالات الاستخدام . خلاف ذلك ، فإن الأمر متروك للمطور لتحليل نص السلسلة.
• هناك حالة خاصة هنا حيث يتم التعامل مع علامة السالب بشكل منفصل. هذا يسهل على المستخدم عدم ارتكاب خطأ في التوقيع. لا أتوقع في الواقع أن يدعم NumberBox ذلك خارج الصندوق.
• تعد محاذاة النص مهمة للتعيين وستكون البادئة / اللاحقة مفيدة للغاية لإظهار رمز العملة (من المحتمل أن تظل الترجمة مشكلة في معرفة ما إذا كان سيتم إظهار الرمز على اليمين أو اليسار ؛ ومع ذلك ، يمكن أن يكون للتطبيق نفسه هذا المنطق)
• يمكن للمستخدم إدخال قيمة أجنبية أو محلية. يمكن أن يختلف NumberFormatInfo و CultureInfo لكلا هاتين القيمتين عن ثقافة واجهة المستخدم. لذلك ، من أجل الترجمة ، يجب أن يدعم عنصر التحكم التجاوز إلى NumberFormatInfo المخصص.

الآن في التطبيق ، يتم استخدام Windows Community Toolkit لكلتا الحالتين مع الخصائص المرفقة بـ TextBox على النحو التالي:
TextBoxRegex.ValidationMode = "ديناميكي"
TextBoxRegex.ValidationType = "عشري"

بعض التعليقات النهائية (آسف ، هذا طويل جدًا!)

• أعتقد أننا نناقش 3 عناصر تحكم مختلفة هنا. NumberBox شريطية ، وهو CalculatorBox يمكن أن يحتوي على معادلات وإدخال رقمي متقدم (زر الحاسبة!) ، وأخيراً MaskedTextBox للإدخال غير الرقمي مثل أرقام الهواتف وعناوين IP. يجب ألا نربكهم ، والاتفاق على كيفية فصل هذه المفاهيم هو مفتاح للمضي قدمًا في المواصفات.
• لا يمكننا أن نفقد التركيز على حالة الاستخدام الأساسية والأكثر فائدة للجدل: مربع نص عادي المظهر لا يحتوي على أكثر من ترشيح الإدخال ، لذا يمكن إدخال رقم صالح فقط. يجب أن تكون جميع الخيارات الأخرى قابلة للإيقاف (أفكر في زيادة +/- أزرار)
• ما زلت أقترح التغيير من ضعف إلى عشري في المواصفات لالتقاط الدقة العشرية بدقة في القيمة المحللة. بالإضافة إلى ذلك ، من المحتمل أن نعتبر إدخال عدد صحيح مختلفًا عن إدخال الرقم المنطقي. من المحتمل أن تكون هذه خاصية جديدة في API "IsInteger = true" للتغيير من القيمة الافتراضية العشرية.

تحرير: تمت إزالة فكرة للتبديل من ضعف إلى عشري لنوع NumberBox.Value. لم أكن مخطئًا في افتراض أن هذا موجود في عالم C ++ WinRT. إنه لا يفعل ذلك ، وبدلاً من ذلك يكون فقط في .net core / framework.

robloo ، بخصوص هذا التعليق النهائي ، لا يوجد نوع عشري في WinRT.

مصحح أخطاء Visual Tree الخاص بـ XAML Toolkit هو أداة تعتمد بشكل كبير على عنصر التحكم NumericUpDown الخاص بمجموعة الأدوات حيث تكون الزيادة / التناقص باستخدام سحب الماوس والأزرار ولوحة المفاتيح كلها مهمة. قد يساعد إدخال الآلة الحاسبة أيضًا:

robloo و @ xyzzer ، هذا هو بالضبط نوع المعلومات الذي أبحث عنه!

التحقق من صحة / اخفاء

robloo ، أنا مهتم بشكل خاص النقطة 2 - التحقق من الصحة مقابل الإخفاء. دعنا نتحدث عن سيناريو "المدخلات السيئة" حتى الآن:

• يكتب مستخدم جديد "اثنين" في NumberBox الخاص بك.
• يثير NumberBox حدث "ValueChanged" الذي يمنحك الفرصة لإعادة إدخال غير رقمي إلى "0" - أو خلاف ذلك - إذا اخترت ذلك. إذا لم يتم اتخاذ أي إجراء ، إذن ...
• تتوهج ركلات التحقق من الصحة في NumberBox باللون الأحمر وتبرز رسالة خطأ للمستخدم لإعلامه بأنه لا يُسمح إلا بإدخال رقمي (لم يتم ترشيد هذا الجزء بشكل كامل حتى الآن ، لذا فإن هذا مجرد افتراض).

هل تمنحك سلسلة الأحداث هذه القدرة على إنشاء التجربة التي تحتاج إلى إنشائها؟

أفهم أن الإخفاء قد يكون افتراضيًا مرغوبًا فيه ، ولكن دعني أشارك ما ناقشه فريقي الأسبوع الماضي - لقد وصلنا إلى الاتجاه الذي يُفضل فيه التحقق من الصحة (مؤشر / رسالة الخطأ) في عناصر تحكم Fluent لأن البديل ، الإخفاء ، يمكن أن يكون محبطًا و مربكًا للمستخدمين النهائيين عندما لا يواجهون أي إخراج من إدخال لوحة المفاتيح الخاصة بهم. هناك طريقة أخرى للتفكير في الأمر وهي أن التحقق من الصحة يوفر مستوى من الشفافية والمعلومات للمستخدم يجعله أكثر وعياً بالتجربة بدلاً من الإكراه بصمت. وبالتالي ، كان مسار العمل الحالي لدينا هو البناء في التحقق الأساسي من الصحة مع عدم حظر الفرصة للمطور لإضافة التحقق المتقدم من الصحة (قريبًا إلى TextBox) أو إخفاء عبر حدث ValueChanged حسب الحاجة. للفهم ، هذا مرن بدرجة كافية للسماح بتلبية جميع الاحتياجات أثناء تقديم التجربة الموصى بها كخيار افتراضي.

ما هي افكارك هنا؟ سأكون مهتمًا بأي أفكار لديك لتضمين هذه المفاهيم بشكل أكبر أو بناء تجربة أفضل إذا استطعنا.

تنسيق القيمة

إلى نقاطك الأخرى ، robloo ، لقد أضفت خاصية الدقة DecimalPrecision إلى المواصفات . تعيين هذا = "0" سيحقق الأعداد الصحيحة. بالإضافة إلى ذلك ، يمكن أن يساعد تعيين MinValue = "0" في الحفاظ على الأرقام غير سالبة (أو يعتبر حدث ValueChanged فرصة أخرى لإجبار الإدخال على القيم المطلقة).

هل بحثت في المواصفات حتى الآن؟ أعتقد أنني قمت بتضمين جميع الخصائص اللازمة لتمكين تجاربك بشكل كامل (في انتظار التحقق من الصحة مقابل مناقشة الإخفاء) لكنني حريص على معرفة ما إذا كنت تعتقد أنني فاتني أي شيء.

التقنيع ، يمكن أن يكون محبطًا ومربكًا للمستخدمين النهائيين عندما لا يواجهون أي إخراج من إدخال لوحة المفاتيح الخاصة بهم.

100٪ موافقون نعم. أفضل شيء تفعله هو التحقق من صحة LosingFocus / EnterPressed واستعادة القيمة القديمة إذا لم يتم التحقق من صحة القيمة المكتوبة ، وهذا هو السبب في أن الإشارة التي يتم تشغيلها في LosingFocus / EnterPressed وتحتوي على oldValue / newValue ستكون مثالية.

adrientetar ، نقطة رائعة! هل هذه تجربة تحتاج إلى إنشائها؟ إذا كان الأمر كذلك ، فسأرى ما يتعين علينا القيام به حتى يرسل حدث ValueChanged كلاً من القيمة القديمة والقيمة الجديدة.

SavoySchuler إنه شيء أريد أن أفعله في تطبيقي بالفعل ، سأقوم ببناء هذا السلوك بنفسي ما لم يفعله عنصر التحكم افتراضيًا.

الشيء الآخر الذي أريده هو Shift + ↑ / للزيادات بمقدار 10 و Ctrl + Shift + / للزيادات بمقدار 100 ، على الرغم من أنني أعتقد أن الزيادات 100 ليس لها معنى دائمًا.

نقطة عظيمة! يجب أن نتأكد من أن عنصر التحكم مشتق من RangeBase الذي
يحدد كل من SmallChange و LargeChange وأننا نستخدم كلاهما في
على أقل تقدير.
هل هناك مثال لتركيبات لوحة المفاتيح القياسية لاستخدامها في الاستدعاء
تغيير كبير على RangeBase الخاص بـ UWP أو WinForms / ComCtl (؟) NumericUpDown؟

يوم الإثنين 3 يونيو 2019 الساعة 3:50 مساءً Adrien Tétar [email protected]
كتب:

SavoySchuler https://github.com/SavoySchuler إنه شيء أريده
في تطبيقي بالفعل ، سأقوم ببناء هذا السلوك بنفسي ما لم تفعله السيطرة
بشكل افتراضي.

الشيء الآخر الذي أريده هو Shift + ↑ / ↓ للزيادات من 10 و
Ctrl + Shift + ↑ / للزيادات من 100 ، على الرغم من أنني أحسب زيادات قدرها 100
ليس من المنطقي دائمًا أن يكون لديك.

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483؟email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VM47
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

سوف أتحقق من ذلك للتحقق ، لكنني واثق تمامًا من أنه يجب ترك اختصارات لوحة المفاتيح للتطبيقات حتى يتم تنفيذها. لقد جربت ذلك باستخدام مبرر إمكانية الوصول رقم 21 وإدخال اختصارات لوحة مفاتيح جديدة هي لعبة محفوفة بالمخاطر للعبها نظرًا لأن جميع هذه الاختصارات تقريبًا التي لم يطالب بها Windows قد تم أخذها الآن على مستوى التطبيق (يقال إن TeachingTip كان قادرًا على القفز فوق عربة F6) - لكنني سأتحقق لمعرفة ما إذا كان تركيز التحكم يسمح بأي استثناء هنا!

تم إنشاء 2018 عندما تم الإعلان عن حالات التحقق من صحة عناصر تحكم TextBox ، باستخدام INotifyDataErrorInfo.
قد يكون هذا جيدًا للاستخدام مع التقنيع للتحقق من صحة أو إبطال السلسلة النصية الحالية.

تحرير: استخدام الأيقونة ولون الحد السفلي السميك للمساعدة في التعرف على حالات عمى الألوان ، وعند النظر إليها باللونين الأبيض والأسود. يمكن عمل نص الخطأ السفلي كتلميح على الأيقونة إذا كانت المساحة مرتفعة.

mdtauk أنت

استقراء SavoySchuler سهل استنادًا إلى المثال الموضح في Build 2018

وهناك الكثير من الأمثلة للنظر إليها :)

معذرة ، هذه واحدة طويلة أخرى!

SavoySchuleradrientetar أرى بالتأكيد من أين ببياناتك أدناه. لن أزعم أنه في الغالبية العظمى من الحالات ، يعد هذا هو أفضل طريقة للتعامل مع التحقق من الصحة. ومع ذلك ، لا بد لي من الاعتقاد بأن هناك بعض الحالات الخاصة حيث من الواضح جدًا أن الإدخال الرقمي فقط هو أنك في الواقع تقدم للمستخدم معروفًا من خلال عدم السماح له بإلقاء القبض على الشخصية الخطأ.

التقنيع ، يمكن أن يكون محبطًا ومربكًا للمستخدمين النهائيين عندما لا يواجهون أي إخراج من إدخال لوحة المفاتيح الخاصة بهم.

100٪ موافقون نعم. أفضل شيء تفعله هو التحقق من صحة LosingFocus / EnterPressed واستعادة القيمة القديمة إذا لم يتم التحقق من صحة القيمة المكتوبة ، وهذا هو السبب في أن الإشارة التي يتم تشغيلها في LosingFocus / EnterPressed وتحتوي على oldValue / newValue ستكون مثالية.

ومع ذلك ، قررت أن أتجول في تطبيقات أخرى لمعرفة كيفية التعامل معها. لا أعتقد أن أي شخص يقوم بأبحاث أكثر من Microsoft حول تفاعل المستخدم ، لذلك قمت بسحب إصدار سطح المكتب 64 بت من Word ثم إصدار UWP من OneNote كمرجع. إنه يتفق تمامًا إلى حد ما مع ما تقوله يا رفاق. يمكنني كتابة أي نص في حجم الخط أو مربعات إدخال حجم الشكل والتي من الواضح أنها مدخلات رقمية فقط. إنه يتحقق إلى حد كبير من فقدان التركيز ويعود إلى آخر إدخال صالح.

| العنوان | الموافقة المسبقة عن علم | التعليق |
| ------ | ----- | ------------ |
| إدخال حجم خط UWP OneNote | | يمكن إدخال أي قيمة من لوحة المفاتيح ، ويتم التحقق من صحتها تلقائيًا وإعادة تعيينها إلى آخر قيمة صالحة عند فقد التركيز |
| إدخال حجم خط كلمة سطح المكتب | | يمكن إدخال أي قيمة من لوحة المفاتيح ، ويتم التحقق من صحتها تلقائيًا عند فقد التركيز وتظهر رسالة خطأ إذا كانت غير صالحة. عند النقر على [موافق] يعيد التعيين إلى آخر قيمة صالحة. |
| رسم بياني UWP OneNote 2D | | يمكن إدخال أي قيمة من لوحة المفاتيح. سيتم ببساطة تجاهل القيم غير الصالحة واستخدام آخر إدخال صالح في الحساب (لا يتم التحقق من صحة التركيز المفقود). سيؤدي الضغط على أزرار الزيادة +/- إلى الزيادة باستخدام آخر إدخال صالح. |
| إدخال حجم شكل كلمة سطح المكتب | | يمكن إدخال أي قيمة من لوحة المفاتيح ، ويتم التحقق من صحتها تلقائيًا عند فقد التركيز وإعادة التعيين إلى آخر قيمة صالحة عند فقد التركيز. |

لذلك أعتقد أنني أثبتت أنني مخطئ مما يعني أنني يجب أن أتفق معك!

التعليقات الجانبية:

• كما ذكر سابقًا شخص آخر ، عندما يركز NumberBox على لوحة المفاتيح بلوحة مفاتيح تعمل باللمس / افتراضية ، يجب أن تظهر لوحة المفاتيح الرقمية فقط.
• تعتبر الزيادة إلى الأسفل على اليسار والزيادة إلى الأعلى على اليمين فكرة مثيرة للاهتمام للمناقشة هنا من حيث التصميم. أحبها!
  

• يكتب مستخدم جديد "اثنين" في NumberBox الخاص بك.
• يثير NumberBox حدث "ValueChanged" الذي يمنحك الفرصة لإعادة إدخال غير رقمي إلى "0" - أو خلاف ذلك - إذا اخترت ذلك. إذا لم يتم اتخاذ أي إجراء ، إذن ...
• تتوهج ركلات التحقق من الصحة في NumberBox باللون الأحمر وتبرز رسالة خطأ للمستخدم لإعلامه بأنه لا يُسمح إلا بإدخال رقمي (لم يتم ترشيد هذا الجزء بشكل كامل حتى الآن ، لذا فإن هذا مجرد افتراض).
  هل تمنحك سلسلة الأحداث هذه القدرة على إنشاء التجربة التي تحتاج إلى إنشائها؟
  ما هي افكارك هنا؟ سأكون مهتمًا بأي أفكار لديك لتضمين هذه المفاهيم بشكل أكبر أو بناء تجربة أفضل إذا استطعنا.

أنا أفهم تمامًا وأوافق على أن إضافة التحقق من صحة الإدخال أمر رائع للنظام الأساسي ككل. ومع ذلك ، فقد وصفت للتو بشكل أساسي التحقق من صحة الإدخال بدون معالجة خاصة لرقم. لذلك ، ما فائدة NumberBox بخلاف التحليل التلقائي للقيمة؟ كمطور ، يبدو أن TextBox مع التحقق من صحة البيانات هو نفسه إلى حد ما.

أعتقد أنه بناءً على الأمثلة المذكورة أعلاه ، يجب أن تكون الوظيفة خارج الصندوق مزيجًا من أفكارنا وهذا ما يقوله adrientetar . يمكن للمستخدم كتابة أي قيمة حتى يحصل على التعليقات المرئية. ومع ذلك ، عند التركيز على الخسارة ، يتم التحقق من صحة القيمة تلقائيًا ويتم إرجاع الرقم الصالح السابق (أو الفارغ) تلقائيًا إلى. هذا يوفر على المطور متاعب الاضطرار إلى التعامل مع التحقق من صحة الإدخال بأنفسنا (نعلم بالفعل أنه يجب أن يكون رقمًا في NumberBox). كما أنه يميز بوضوح عن مجرد TextBox مع التحقق من صحة البيانات.

فيما يتعلق بالأحداث ، ما زلت أرغب في أن تتاح لي الفرصة لإلغاء تغييرات النص إذا أصبحت حالة الاستخدام هذه أكثر وضوحًا. لذلك ، بالإضافة إلى ValueChanged ، أوصي بحدث ValueChanging و TextChanging للسماح بمقارنة الإدخال وإلغائه. بالتأكيد هناك حاجة إلى OldValue و NewValue بغض النظر ، فإن هذا سيسمح لنا على الأقل بتغييرها بسرعة إلى OldValue إذا لزم الأمر (على الرغم من أن UWP يحب التعطل عند تعديل TextValue داخل حدث ما).

فيما يتعلق بالمواصفات: أفكار جيدة مع DecimalPrecision ، سأحتاج إلى مزيد من الوقت لمراجعتها وإضافة تعليقاتي. هناك الكثير من الفروق الدقيقة مثل القيمة الافتراضية يجب أن تكون String = Empty و Value = Null وعندما يتم الضغط على زر زيادة +/- يجب أن تعامل القيمة بدلاً من ذلك على أنها صفر بدلاً من فارغة.

mdtauk لا ينبغي أن يكون من الممكن بشريًا إنشاء مثل هذه الرسوم التوضيحية الجيدة بهذه السرعة :)

robloo شكرا لك على التعليق
قد يكون من الأفضل التمسك بالرموز لأعلى ولأسفل المستخدمة في أزرار الدوران الحالية ، لتجنب الالتباس مع العمليات الحسابية التي يمكن أن يؤديها NumberBox.

يستخدم iOS عنصر تحكم "متدرج" ، لكن إدخال النص منفصل ، ولا يوجد حساب مضمّن.

إليك بعض التصميمات التي وجدتها

يبدو أن التصميم الذي اخترته يتناسب مع أسلوب Microsoft النموذجي لعنصر التحكم هذا ، لكنه الخيار الأفضل أم الاختيار الصحيح. سأكون مهتمًا بسماع رأي الآخرين في ذلك.

تحرير: تمت إضافة بعض نماذج النماذج البديلة (ولكن أعتقد أن الفكرة الأولى هي الأفضل ...)

أتفق مع mdtauk على موقع +/- ، الأول هو الأفضل.

يوجد قالب تحكم XAML بحيث يمكن للمستخدم (المطور) دائمًا إنشاء قالب مخصص للتخطيطين الآخرين.

robloo ، لست بحاجة إلى الاعتذار عن الردود التفصيلية - خاصةً عندما يحزمون بعض الأسئلة المفتوحة في المواصفات ليتم تشغيلها بواسطة المطورين / الفريق والتأكد من عدم وجود عبء أداء غير مقبول في القيام بذلك. أعتقد أنه سيكون من الراحة الرائعة للمستخدمين إذا تمكنا من تحقيق ذلك.

أنت تطرح نقطة رائعة حول التحقق ...

[1] وقت السؤال: هل سيكون أي شخص ضد نظام التحقق الذي يعيد المدخلات غير المقبولة تلقائيًا إلى القيمة السابقة بينما يعرض الأحداث التي من شأنها أن تسمح للمطور بإلغاء هذا السلوك وبدلاً من ذلك يقرر ما يجب فعله / رفع مؤشرات الخطأ أو الرسائل؟

بصريًا ، أرى ميزة UpDownButtons المنفصلة في المثال الذي نشرته. أعتقد أن mdtauk و sonnemaf على المسار الصحيح

أعتقد أن هناك سيناريوهات لأزرار UpDown المنفصلة. يذهب عقلي إلى المهام التي تتوقع مدخلات قليلة وأحادية الاتجاه أو تلك التي يسعى فيها المطور إلى جعل أخطاء الإدخال أصعب. أعتقد أن هذه هي التجربة التي تقدمها العديد من التطبيقات والمواقع ، على سبيل المثال ، عندما يشتري أحدهم تذاكر فيلم أو حفلة موسيقية.

سؤالي إذن ...

[2] وقت السؤال: هل يجب أن نعتمد على Xaml ControlTemplate لإنشاء NumberBox مع UpDownButtons المنفصلين (على سبيل المثال ، هذا ليس شائعًا بما يكفي لتبرير الدعم خارج الصندوق) أم يجب تضمين خاصية لإعداد ما إذا كانت أزرار UpDown تظهر متجاورة مقابل الانفصال؟

سأقوم بإجراء pingchigy لهذا السؤال لأن إرشادات نظام تصميم Fluent قد تتجاوز هذا السؤال الثاني.

يجب أن أدرج اعتبارات إمكانية الوصول لمحادثة UpDownButtons: قرب أزرار UpDownButtons من بعضها البعض يتيح الوضوح المفاهيمي لمستخدمي الراوي / قارئ الشاشة مع الحفاظ أيضًا على كفاءة التنقل لمستخدمي التنقل باستخدام لوحة المفاتيح ومن المهم أيضًا عدم المساومة على ذلك.

إذا لم يكن عنصر التحكم عريضًا جدًا ، فقد ترغب في تكديس الأسهم بشكل عمودي (أعلم أنني بحاجة إلى ذلك في تطبيقي). ربما يمكن جعل التحكم يستجيب لعرضه المحدد؟ يعود ذلك إلى إرشادات التصميم الطلاقة لتحديدها بهذه الطريقة إذا اعتقدوا أنها منطقية.

لقد قمت بتحديث الاقتراح بأسئلتنا الثلاثة المفتوحة.

شكرا لك mdtauk لتصاميم المفاهيم!

adrientetar يسعدني أنك أشرت إلى ذلك باعتباره حاجة. يبدو وكأنه ربما نحتاج إلى تعداد لهذه التكوينات الثلاثة؟

إذا لم يكن عنصر التحكم عريضًا جدًا ، فقد ترغب في تكديس الأسهم بشكل عمودي (أعلم أنني بحاجة إلى ذلك في تطبيقي). ربما يمكن جعل التحكم يستجيب لعرضه المحدد؟ يعود ذلك إلى إرشادات التصميم الطلاقة لتحديدها بهذه الطريقة إذا اعتقدوا أنها منطقية.

كان هناك اقتراح للسماح لعناصر التحكم بأن تكون على دراية وتجاوب مع مقدار المساحة المتاحة لها # 677 يمكن استخدام هذا لإعادة وضع أزرار Spin حيث يصبح عنصر التحكم أضيق. ربما يجب أن تكون هناك خاصية لـ NarrowWidth مشابهة لـ MinWidth ، أو ربما حتى NumberOfDigits لتكون بمثابة تلميح؟

فيما يتعلق بمثال النص الرمادي - أخشى أن هذا قد يشجع المستخدم على ملء القيم التي تظهر ، بدلاً من العمل كتلميح لما ستكون النتيجة النهائية. يبدو تمامًا مثل PlaceholderText.

ماذا عن استخدام AccentColor ووزن الخط المختلف لإبرازه

رابط رائع ،mdtauk. أتخيل أنه إذا كان هذا هو الطريق الذي نسلكه ، فيمكننا التعامل مع هذا مع تعداد يحتوي على قيم مثل [تلقائي ، عمودي ، أفقي ، منفصل] حيث سيفضل Auto Horizontal حتى يفرض الضغط على Vertical. أفكار؟

أيضا ، لقد قمت بتحديث الصورة! أعتقد أنك محق في أن النص الرمادي قد يبدو وكأنه موجه ، والذي إذا تم اتباعه ، سيؤدي إلى حدوث خطأ بسبب "=".

رابط رائع ،mdtauk. أتخيل أنه إذا كان هذا هو الطريق الذي نسلكه ، فيمكننا التعامل مع هذا مع تعداد يحتوي على قيم مثل [تلقائي ، عمودي ، أفقي ، منفصل] حيث سيفضل Auto Horizontal حتى يفرض الضغط على Vertical. أفكار؟

الفكرة الأولية هي ، هل سيكون الرقم الموجود في الحاوية كبيرًا بما يكفي حيث ستكون هناك حاجة إلى اتجاه رأسي؟ لا يقوم AutoCompleteBox بتحريك زر البحث الخاص به ، وعادة ما تكون السلاسل أطول من الأرقام.

إذا كان الأمر يرجع إلى المساحة المتاحة تمامًا ، فسيكون سلوك الاستجابة التلقائية (إذا تم منح هذا الاقتراح الضوء الأخضر) أفضل من التعداد. قد يؤدي منح المطورين الخيار في عنصر التحكم نفسه إلى استخدام أقل من ثابت لعنصر التحكم ، لكنني أعتقد أن هذا سيحتاج إلى أن يكون شيئًا يجب أن ينظر إليه بحث المستخدم ، بدلاً من وصفه لنا وحدنا على github.

يتمتع المطورون دائمًا بخيار إعادة تشكيل عنصر التحكم إذا كانوا يحتاجون إلى تخطيط مختلف لعنصر التحكم ، ومن الممكن تضمين نمط بديل لذلك إذا كنت ترغب في ذلك) انتقل إلى الجهد المبذول لجعل كل من الإعداد الافتراضي و يضمن النمط الرأسي والقوالب - و B) اختبار كلا الأنماط بشكل صحيح

mdtauk أوافق على أن الرموز لأعلى / لأسفل هي الأفضل. أردت فقط عرض مثال مع الأسهم على جوانب متقابلة من الإدخال. كما ذكرنا سابقًا ، يساعد ذلك على ضمان عدم قيام المستخدم بالضغط على الخطأ الذي يعد إلزاميًا تقريبًا في واجهة مستخدم تعمل باللمس. كان المثال الذي قدمته من OneNote يحتوي على رموز +/- ولكن كان يجب علي إضافتها لتجاهل الرموز نفسها.

تضمين التغريدة

[2] وقت السؤال: هل يجب أن نعتمد على Xaml ControlTemplate لإنشاء NumberBox مع UpDownButtons المنفصلين (على سبيل المثال ، هذا ليس شائعًا بما يكفي لتبرير الدعم خارج الصندوق) أم يجب تضمين خاصية لإعداد ما إذا كانت أزرار UpDown تظهر متجاورة مقابل الانفصال؟

أعلم أنه عندما تم إنشاء UWP لأول مرة ، كانت اللمسة الأولى - لذلك يمكن القول أن UpDownButtons المفككة سيكون أفضل. منذ ذلك الحين ، خفت متطلبات اللمس أولاً وبالتأكيد تكون الأزرار المجاورة لبعضها البعض أفضل عندما يكون لدى المستخدم طريقة إدخال دقيقة مثل الماوس (مسافة انتقال أقل). نظرًا لأن هذا يعتمد على حالة الاستخدام ، فأنا أوافق على أن التعداد مفيد لتحديد كيفية ظهور أزرار UpDownButtons.

بالنسبة لقيم التعداد ، ناقشنا عدة حالات وتعميم يمكننا إضافة المزيد:

• SeparatedHorizontal: سهم لأسفل على اليسار ، سهم لأعلى على اليمين
• SeparatedVertical: سهم لأسفل في الأسفل ، سهم لأعلى في الأعلى
• اليسار: كلا السهمين لأسفل ولأعلى بجانب بعضهما البعض على اليسار (في اتجاه أفقي)
• إلى اليمين: كلا السهمين لأسفل ولأعلى بجانب بعضهما البعض على اليمين (في اتجاه أفقي)
• أعلى: كلا السهمين لأسفل ولأعلى بجانب بعضهما البعض في الأعلى (في اتجاه رأسي)
• أسفل: كلا من السهمين لأسفل ولأعلى بجانب بعضهما البعض في الأسفل (في اتجاه رأسي)

إذا أصبح كل هذا معقدًا جدًا (كما هو سريعًا) ، فسأكون سعيدًا بإعادة قالب عنصر التحكم لحالات الاستخدام الخاصة بي في XAML.

فقط لطرح فكرة أخرى: تغيير اتجاه الرمز لأزرار UpDown المفككة قد يكون له معنى أيضًا [<] 123 [>]. لا تتردد في تجاهل هذا التعقيد الإضافي على الرغم من أنه يمكن بالتأكيد إعادة تصميمه على أساس كل تطبيق.

أيضًا ، ربما تمت معالجة بعض مخاوف إمكانية الوصول بالفعل في OneNote وهو المكان الذي اشتريت منه المثال.

robloo أعتقد أنه يجب الاحتفاظ بالمواضع اليمنى واليسرى التي ذكرتها من أجل الترجمة RtL و LtR - بدلاً من الإعدادات السرية.

فيما يلي آرائي

أنا أيضًا لست متأكدًا من أن وضع الأزرار فوق حقل النص أمر منطقي من الناحية الدلالية ، ناهيك عن وضع إصبعك على الزر ، قد يجعل من الصعب رؤية الرقم يتغير.

سيؤدي وجود كل مجموعة مضمنة في عنصر التحكم إلى الاستخدام الفوضوي ، ويمكن القيام بكل هذه الأشياء من خلال إعادة التشكيل إذا كانت هناك حاجة ملحة.

قد يكون للأزرار الموجودة أسفل حقل النص بعض الاستخدام في المساحات الضيقة ، وكخيار في عنصر التحكم نفسه ، لأنه يجعل الأزرار أكبر بكثير للنقر عليها. سواء كان ذلك كنمط مجمع مع عنصر التحكم ، أو تعدادًا بين:

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

مجرد سؤال سريع اقتراح ممكن: نظريًا ، في مربع الأرقام ، يجب أن يكون المرء قادرًا على إدخال الأرقام فقط في مربع الأرقام. ما مدى صعوبة تحليل الأرقام المكتوبة وترجمتها إلى أرقام فعلية لهذه الحقول؟

على سبيل المثال:
واحد + اثنان = 3
يترجم
1 + 2 = 3

أو
واحد زائد اثنين يساوي ثلاثة
يترجم إلى
1 + 2 = 3

إنها مجرد فكرة.

مجرد سؤال سريع اقتراح ممكن: نظريًا ، في مربع الأرقام ، يجب أن يكون المرء قادرًا على إدخال الأرقام فقط في مربع الأرقام. ما مدى صعوبة تحليل الأرقام المكتوبة وترجمتها إلى أرقام فعلية لهذه الحقول؟

على سبيل المثال:
واحد + اثنان = 3
يترجم
1 + 2 = 3

أو
واحد زائد اثنين يساوي ثلاثة
يترجم إلى
1 + 2 = 3

إنها مجرد فكرة.

هذا منطقي بالنسبة للغة الإنجليزية. تصبح مشكلة عندما تحتاج إلى ترجمة هذه النصوص وتحليلها للغات أخرى. وماذا عن مستخدم بولندي يكتب بالكلمات الإنجليزية؟

كما هو الحال الآن ، تمت مناقشة شكل الأرقام من 0 إلى 9 ، والأرقام العشرية ، وفواصل الأرقام ، والعوامل الحسابية فقط. لكن أنظمة الأرقام الأخرى قد تحتاج إلى الاهتمام بها.

ستكون إضافة ترجمات لغوية جهدًا كبيرًا ، وليس من الواضح ما هي الفائدة.

الآن ، إذا تم التلاعب بهذا التحكم عن طريق إدخال الصوت ، لذا فإن التحدث عن الرقم أو العملية - قد يتضمن ذلك تفسير اللغة التي يتم التحدث بها.

راوي:
"عدد وحدات البكسل بدون قيمة"

المستعمل:
"مائة وثمانية وعشرون بكسل"

[128 _________ | بكسل]

المستعمل:
"إضافة أربعة وستين بكسل"

[192 _________ | بكسل]

راوي:
"مائة واثنان وتسعون بكسل"

[1] وقت السؤال: هل سيكون أي شخص ضد نظام التحقق الذي يعيد المدخلات غير المقبولة تلقائيًا إلى القيمة السابقة بينما يعرض الأحداث التي من شأنها أن تسمح للمطور بإلغاء هذا السلوك وبدلاً من ذلك يقرر ما يجب فعله / رفع مؤشرات الخطأ أو الرسائل؟

إذا أصبح النص المدخل غير صالح ، فلماذا يتم تغيير القيمة إلى شيء أقدم؟ لا أعتقد أن محاولة الحفاظ على "آخر معرفة جيدة Value " هو أمر يجب أن يكون عنصر التحكم مسؤولاً عنه. دع عنصر التحكم يتعامل مع قيمة حالية واحدة (أو حالة خطأ) ودع التطبيق يتولى أي معالجة تاريخية إضافية حسب الضرورة عبر الحدث ValueChanged .

بالنسبة للإصدار الأولي ، أعتقد أنه سيكون جيدًا مع دعم موضع واحد فقط من الأزرار لأعلى / لأسفل حيث يمكن إعادة تشكيلها إذا لزم الأمر.
إذا كانت القدرة على تحديد موضع الأزرار لأعلى / لأسفل تعتبر ضرورة ، فإن أي تعداد تمت إضافته يجب أن يزيل الحاجة إلى امتلاك خاصية UpDownButtonsEnabled وقيمة التعداد Hidden يمكن أن تكون المضافة بدلا من ذلك.
لاحظ أيضًا أن وجود دعم مدمج لمعالجة موضع الأزرار لأعلى / لأسفل سيضيف تعقيدًا لأي شخص يحتاج إلى ضبط القوالب لأي شيء بخلاف الخيار المقدم.

shaheedmalik ، لعنصر التحكم

mrlacey، هل لديك فرصة لمراجعةrobloo الصورة تحليل مقارن لNumberBox مراقبة مماثلة لاستخدامه خلال ويندوز ؟ إن سلوك إعادة تعيين هذه الحقول إلى آخر إدخال صالح للأرقام فقط له بالفعل سابقة على مستوى النظام - مما يعني أنه سيتم الضغط على عنصر التحكم نفسه أو إرشادات المطور لمحاذاة هذا النمط. أميل إلى محاذاة عنصر التحكم هذا في تناسق مع تجربة Windows القياسية وإنشاء مسار للانحراف الضروري بدلاً من توحيد السلوك الذي ينحرف عن بقية النظام البيئي وتأكيد المبادئ التوجيهية لإنشاء هذا السلوك الافتراضي للنظام حيث أن الأخير سيخلق سهل وفعال للقضية المشتركة. أنا أشجع الاختلاف ، لذا يرجى إعلامي إذا كنت تعتقد أن هذا يضيف تعقيدًا غير ضروري إلى عنصر التحكم ، أو ربما ، ربما يتعين علينا إعادة تقييم هذه السابقة؟

| العنوان | الموافقة المسبقة عن علم | التعليق |
| ------ | ----- | ------------ |
| إدخال حجم خط UWP OneNote | | يمكن إدخال أي قيمة من لوحة المفاتيح ، ويتم التحقق من صحتها تلقائيًا وإعادة تعيينها إلى آخر قيمة صالحة عند فقد التركيز |
| إدخال حجم خط كلمة سطح المكتب | | يمكن إدخال أي قيمة من لوحة المفاتيح ، ويتم التحقق من صحتها تلقائيًا عند فقد التركيز وتظهر رسالة خطأ إذا كانت غير صالحة. عند النقر على [موافق] يعيد التعيين إلى آخر قيمة صالحة. |
| رسم بياني UWP OneNote 2D | | يمكن إدخال أي قيمة من لوحة المفاتيح. سيتم ببساطة تجاهل القيم غير الصالحة واستخدام آخر إدخال صالح في الحساب (لا يتم التحقق من صحة التركيز المفقود). سيؤدي الضغط على أزرار الزيادة +/- إلى الزيادة باستخدام آخر إدخال صالح. |
| إدخال حجم شكل كلمة سطح المكتب | | يمكن إدخال أي قيمة من لوحة المفاتيح ، ويتم التحقق من صحتها تلقائيًا عند فقد التركيز وإعادة التعيين إلى آخر قيمة صالحة عند فقد التركيز. |

mdtauk ، مع الإشارة إلى تعليقك على لغات LTR و RTL وجانب عنصر التحكم الذي يظهر عليه UpDownButtons. سأقوم بتشغيل هذا من قبل خبراء الترجمة للتأكد من أن هذا هو الاعتبار الذي يتم أخذ الاحتياجات في الاعتبار.

mrlacey أنت محق أيضًا في أن قيمة منطقية ستكون زائدة عن الحاجة إلى تعداد. سأحاول التحقق قريبًا مما إذا كانت هناك حاجة إلى أي تكوينات بديلة.

adrientetar ، أنت عميلنا الأساسي للأزرار الرأسية. هل لديك قصاصات شاشة أو سياق يمكن أن يساعدني في فهم قيود المساحة لديك بشكل أفضل؟ mdtauk جعلني أفكر بهذا الرد في وقت سابق:

الفكرة الأولية هي ، هل سيكون الرقم الموجود في الحاوية كبيرًا بما يكفي حيث ستكون هناك حاجة إلى اتجاه رأسي؟ لا يقوم AutoCompleteBox بتحريك زر البحث الخاص به ، وعادة ما تكون السلاسل أطول من الأرقام.

SavoySchuler (فيما يتعلق بإعادة التعيين إلى آخر قيمة جيدة) نظرًا لأن المواصفات ستضيف المزيد من الإمكانيات إلى NumberBox لمعالجة الأخطاء والإبلاغ عنها مقارنةً بعناصر التحكم في مراجعةrobloo ، كنت أتطلع إلى تحقيق المزيد من هذه الإمكانات.

ضع في اعتبارك هذا:

1. NumberBox بـ AllowsCalculations=True
2. أدخل 1100 يدويًا وانتقل إلى عنصر التحكم التالي
3. أدرك أن هذا ليس ما تريد الدخول
4. ارجع إلى عنصر التحكم وأدخل "99 × 12"
5. علامة التبويب إلى عنصر التحكم التالي وتعود القيمة مرة أخرى إلى عرض "1100" ("x" ليس هو نفسه "*" لذلك سيفشل في خطوة الحساب. أو ضع في اعتبارك أي عملية حسابية غير صالحة أخرى تفشل إذا لم يكن "x" غير " يتم عرضها عند الضغط عليه.)
6. يعرض الآن قيمة ليست نتيجة الحساب ، ولا يتم عرض رسالة خطأ ، ويتم فقد المجموع الذي تم إدخاله ، لذلك لا يوجد سجل لما حدث.

ما أريد أن يحدث عند الانتقال إلى عنصر التحكم التالي في الخطوة 5 هو

• تظل القيمة "99 × 12" هي القيمة Text
• يتم عرض حالة الخطأ.
• ValueChanged تشغيل حدث
• يمكن للمستخدم بعد ذلك رؤية أن هناك خطأ ما
• يمكن للمستخدم تصحيح المشكلة دون الحاجة إلى إعادة إدخال المبلغ بالكامل.
• يمكن لمنطق الكود / التطبيق أن يفعل شيئًا مناسبًا إذا لزم الأمر.

في حالة العودة تلقائيًا إلى آخر قيمة جيدة معروفة عند الإدخال:

• عندما لا يتم إدخال أي قيمة في حقل مطلوب ، هل سيتم الإشارة إلى حالة الخطأ؟
• أليست قيمة وجود حدث ValueChanged تتضاءل إلى حد كبير لأنه لن يبلغ عن حالة غير صالحة أبدًا؟

SavoySchulermrlacey وعند النظر إلى تلك الأمثلة في تطبيقات Microsoft الأخرى ...

يجب استبعاد أي نوافذ منبثقة مشروطة. وبدلاً من ذلك ، يجب التعامل مع ذلك من خلال حالة تحقق في عنصر التحكم نفسه.

صورة

إذا كانت هناك قيمة غير صالحة ، فربما يجب أن تظل المحتويات في هذه الحالة غير الصالحة ، ولكن فقط أثناء التركيز على عنصر التحكم. في حالة فقد التركيز ، تعود قيمة حقل النص ، لكن إشعار التحقق من الصحة يعرض ما أدخله المستخدم؟

InputScope: رقم أم FormulaNumber؟

كما ذكرنا سابقًا (في تعليق العلاقات العامة) ، لا يتضمن FormulaNumber "مساحة" والتي تتضمن جميع أمثلة الحساب هنا وفي المواصفات. يتضمن FormulaNumber أيضًا رموزًا رياضية لا يدعمها عنصر التحكم هذا

أنا أصوت لـ "رقم"

عدد

الصيغة

SavoySchuler أعني أنني أقوم فقط بإنشاء تطبيق سطح مكتب (لا أحاول

بالمناسبة ، لن يتم توسيط محتويات TextBox عموديًا ، وهذا مع VerticalContentAlignment = "Center".

يبدو مشابهًا لنوع الشريط الجانبي للخاصية الذي يستخدمه Paint 3D (والذي يستخدم أيضًا أسلوب التحكم الخاص به مع حدود أرق وأخف ، وما يشبه خاصية لاحقة)

إذا لم يتم تنفيذ السحب ، فيمكنك دائمًا القيام بما فعله Paint 3D ، ولديك شريط تمرير مرتبط بـ NumberBox.

إنه مشابه أيضًا لما تفعله Adobe من خلال وجود شريط تمرير منسدل في سيطرتها.

adrientetar يبدو أنك تقوم بعمل نسختك الخاصة من NumberBox هناك. سيكون للنص الموجود في TextBox الخاص بك محاذاة أساسية ، حيث سيكون للخطوط تنازلي يجب حسابه.

بالنسبة لـ NumberBox ، قد يكون هناك حالة لوجود أحرف مركزية بصريًا ، ولكن بعد ذلك لن تتم محاذاة NumberBoxes عند وضعها بجانب عنصر تحكم مشتق من TextBox أو TextBox مثل ComboBox.

عند إنشاء القوالب والأنماط الافتراضية ، يجب مراعاة خصائص Windows.UI.Xaml.Documents.Typography المختلفة ...

• أشكال الطباعة
• الطباعة.المحاذاة الرقمية + الطباعة.النمط الرقمي (الجدول قد يكون أفضل من النسبي)

mrlacey ، أنت تقدم حجة صحيحة. بناءً على رد adrientetar ، ماذا عن السيناريو التالي:

يتم تشغيل الأحداث التي تم تغييرها في القيمة / النص عند _ كل_ تغيير (للحالات التي يقوم فيها مستخدمو السحب / التمرير باختبار النطاق) ، وبالتالي ، يمكن أن يحدث التحقق باستمرار حيث يتم عرض رسالة الخطأ والمؤشر حتى يتم الضغط على "إدخال" / فقدان التركيز ، في في هذه الحالة ، فإن قيمة التحقق من الصحة تتجاوز القيمة الجيدة الأخيرة وتحل محلها (ما لم يتم تعطيل هذا السلوك من خلال الخاصية الخاصة به).

سوف أتحدث مع الفريق بعد ظهر هذا اليوم للتحقق مما إذا كان إطلاق الحدث المستمر / التحقق من الصحة فكرة واقعية - وإلا فقد نبني في النطاق المحدد بطريقة أخرى.

mdtauk ، لكنني أعتقد أنك على صواب مع LucasHaines ، هل يمكنك التحقق مني مرتين؟

jevansaks ، هل أنت قادر على تقييم اعتبارات InputScope أدناه؟

كما ذكرنا سابقًا (في تعليق العلاقات العامة) ، لا يتضمن FormulaNumber "مساحة" والتي تتضمن جميع أمثلة الحساب هنا وفي المواصفات. يتضمن FormulaNumber أيضًا رموزًا رياضية لا يدعمها عنصر التحكم هذا

أنا أصوت لـ "رقم"

عدد

الصيغة

تضمين التغريدة

يتم تشغيل الأحداث التي تم تغييرها في القيمة / النص عند كل تغيير (للحالات التي يقوم فيها المستخدمون بالسحب / التمرير باختبار النطاق) ، وبالتالي ، يمكن أن تحدث عملية التحقق باستمرار حيث يتم عرض رسالة الخطأ والمؤشر حتى يتم الضغط على "إدخال" / فقدان التركيز ، في في هذه الحالة ، فإن قيمة التحقق من الصحة تبطل وتستبدل آخر قيمة جيدة (ما لم يتم تعطيل هذا السلوك من خلال الخاصية الخاصة به).

يجب أن يتم تنشيط الحدث ValueChanged فقط عندما يتغير Value الفعلي ، وليس في كل مرة يتغير فيها Text .

ما لم يتم تعطيل هذا السلوك من خلال الممتلكات الخاصة به

ما هي هذه الخاصية الجديدة؟

لا أعرف كيف تعالج الأحداث الأكثر تكرارًا مشكلة القيم غير الصحيحة وحالات الخطأ التي يتم فقدها عند الرجوع إلى آخر قيمة جيدة معروفة.
أشعر أن بعض التجريب مطلوب هنا لفهم كيف سيكون هذا في الواقع. (إذا كان بإمكاني فقط العثور على الوقت ...)

في ملاحظة ذات صلة.

أفترض أن حدث TextChanged الموروث من TextBox لن يتم تعديله للمستهلك. ولكن ماذا عن حدث TextChanging ؟ هل سيكون هذا هو المكان الذي تتم فيه معالجة التحكم الجديدة المحددة؟ هل سيتمكن مستهلك عنصر التحكم من التعامل مع هذا الحدث أيضًا؟

متفق عليه - يستحق الاستكشاف ولكن الأفضل تجنبه. لقد قمت بمراجعة القسم الخاص بالتحقق من الصحة وأضفت خاصية IsInvalidInputOverwritten التي يتم تعطيلها افتراضيًا. ما رأي الجميع فيما يلي:

• المدخلات غير العددية الخاصة بالمنتدى أو التي تتجاوز قيم الحد الأدنى / الحد الأقصى ستطلق تحذير التحقق من صحة الإدخال .
• يمكن للمطور اعتراض أحداث ValueChanged أو TextChanged (التي تعرض الخاصية التي تم تغييرها والمراد تحديثها) ومعالجة الإدخال غير الصحيح يدويًا قبل عرض تحذير التحقق من صحة الإدخال .
• سيؤدي تمكين الخاصية IsInvalidInputOverwritten إلى إعادة الإدخال غير الصحيح إلى آخر حالة صالحة بدون عرض تحذير التحقق من صحة الإدخال . على سبيل المثال ، إذا تم تمكين IsInvalidInputOverwritten ، و StepSize = 0.2 ، و MaxValue = 3.0 ، وتزداد القيمة 2.9 ، وسيسجل 3.1 على أنه غير صالح وستتم الكتابة فوقه مرة أخرى إلى 2.9.

يمكن تلخيص الكثير من هذا بمسألة ما إذا كان يجب أن يتم التحقق من الصحة خلال الإدخال أو بعده. أنا أميل بعد ذلك من أجل الأداء ولأن تجربة تلقي عمليات التحقق أثناء الكتابة يمكن أن تكون مزعجة ويصعب الوصول إليها - مما يؤدي إلى أن يكون ما سبق هو التطبيق المفضل لدي حاليًا.

تعود FWIW و Adobe Photoshop و Illustrator إلى القيمة السابقة عندما تحاول إدخال قيمة غير صالحة. هذا له سلوك الحساب ، لكن لاحقة وحدة القياس هي جزء من النص ، والتي في حد ذاتها يمكن أن تسبب مشاكل في التحقق من الصحة :)

أردت طرح فكرة كنت أعارض نفسي بشأنها - يمكنني أن أتذكر في العديد من التجارب السابقة حيث كان لدي نوع من مربع رقم الفرز مع وظيفة زيادة / إنقاص ، فالتنزيل عن الحد الأدنى للقيمة سيعيدني إلى أعلى قيمة ، والعكس صحيح. كنت أرغب في معرفة ما إذا كان شيء مثل خاصية _ValuesWrap_ منطقيًا هنا.

من الواضح أن هذا ليس منطقيًا في كل حالة ، ولكن في حالات النطاق الرقمي المحدودة ، كان من البديهي بالنسبة لي في الماضي افتراض التفاف الأرقام في حالات مثل إدخال Age أو DateOfBirth أو حالات أخرى ذات نطاق صغير. من ناحية أخرى ، يحدث هذا في بعض الأحيان فقط لأنه في هذه الحالات يتم استخدام مربع اختيار متعدد الخيارات ، وتلك القيم تلتف عادةً بدلاً من التوقف. أردت فقط التحقق مما إذا كان هناك أي مبرر أو حاجة لذلك - بالطبع من المحتمل أن يتم تنفيذه من جانب المطور أيضًا من خلال أي حدث onValueChanged مع عمل إضافي.

cc SavoySchuler

فكرة رائعة ،KevinTXY. إذا احتاج أي من مطورينا هنا إلى شيء من هذا القبيل ، فيمكننا النظر في إضافته!

وقت السؤال: هل لدى أي شخص أي سيناريوهات حقيقية للتطبيق تبرر الحاجة إلى دعم نظام سداسي عشري أو ثنائي؟ التفاف القيم القصوى / الدقيقة؟

كنت أرغب في معرفة ما إذا كان شيء مثل خاصية ValuesWrap منطقيًا هنا.

نعم ، إذا كانت لديك خاصية زاوية تريد الانتقال إلى 359 → 0 ، تعديل 360 بشكل أساسي. الشيء الممتع هو أنه لا يزال يتعين علي تصنيف عنصر التحكم (كان في Qt) لأن MaxValue يمكن أن يكون شاملاً فقط ، لذلك يمكنني تحديد 359 أو 360 ، لكنني أردت حقًا أن أكون قادرًا على كتابة 359.99 ولكن ليس 360 (أي أردت <، وليس ≤).

يحتوي QSpinBox على خاصية التفاف لهذا الغرض https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

SavoySchuler فيما يتعلق بالنظام الست عشري ، أظن أن المحرر السداسي العشري قد يرغب في ذلك ولكن يبدو أنه حالة استخدام متخصصة حقًا ، لست مضطرًا لدعم كل شيء ممكن فقط تأكد من سهولة التحكم في الفئة الفرعية. في Qt ، يحتوي عنصر التحكم على طريقة تتحول من سلسلة نصية إلى القيمة العددية (سواء كانت int أو double) والتي يمكن تجاوزها.

على سبيل المثال ، إذا تم تمكين IsInvalidInputOverwritten ، و StepSize = 0.2 ، و MaxValue = 3.0 ، وتزداد القيمة 2.9 ، وسيسجل 3.1 على أنه غير صالح وستتم الكتابة فوقه مرة أخرى إلى 2.9.

ربما يمكنك تثبيت MaxValue في هذه الحالة.

SavoySchlerxyzzermrlacey لقد رأيت على Twitter أن هناك شيئًا قادمًا في 20H1 يوفر إدخالًا تنبؤيًا للنص.

قد يتداخل هذا مع ميزة إكمال المعاينة التي تحدثنا عنها ، وقد تحتاج إلى شيء ما تم قمعه في عنصر تحكم NumberBox. يبدو أن الوصول إلى عناصر تحكم Win32 و XAML ...

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

أفترض أن التعامل مع النظام السداسي أو الثنائي هو سيناريوهات أكثر تخصصًا من التعامل مع "السلاسل التي تشبه الأرقام" مثل أرقام الهواتف والرموز البريدية. (وإحضار التعقيد الخاص بهم)
على هذا النحو أعتقد أنها يجب أن تكون خارج نطاق التحكم في NumberBox.

عند الحديث عن ميزة حسابات المعاينة ، في حالة فقدها ، أقترح منح المستخدم الخيار لتشغيلها / إيقاف تشغيلها. لذا ربما تضيف خاصية مثل

public bool ShowPreviewResult { get; set; }

لماذا تظهر نتيجة المعاينة؟ 🤔 ليس كما لو أن المستخدم قد يغير صيغته اعتمادًا على النتيجة ، إذا كانوا يعرفون النتيجة التي يريدونها ، فسيقومون بكتابة ذلك على الفور

لماذا تظهر نتيجة المعاينة؟ 🤔 ليس كما لو كان المستخدم يفعل ما يكتبه اعتمادًا على النتيجة ، إذا كانوا يعرفون ما يريدون ، فسيقومون بكتابته على الفور

تتمثل إحدى ميزات عنصر التحكم في القدرة على الدخول في عملية حسابية ، مثل 32 * 4 والتي يمكن حلها كـ 128 - ستظهر ميزة المعاينة ما ستكون عليه هذه النتيجة عندما يفقد عنصر التحكم التركيز أو يتم الضغط على Enter.

adrientetar المعاينة ميزة مؤقتة حتى الآن. أعتقد أن القيمة ستكون جزئيًا في التحقق الموجه للمستخدم قبل بدء عملية التحقق من صحة عنصر التحكم ، على سبيل المثال ، يظهر فقط ما إذا كان يمكن حساب ما تم إدخاله / في الحدود ؛ على سبيل المثال ، التحقق من التوقعات ("هل ضربت مرات بدلاً من علامة الجمع؟"). هناك فائدة وعائد على الاستثمار هنا ليست واضحة بعد.

شكرا لردود الفعل مرة أخرى ، الجميع! يبدو أنه لا توجد حاجة ملحة أو تستدعي الاهتمام بالدعم الثنائي أو السداسي العشري في الوقت الحالي. يمكن أيضًا تصنيفها ضمن فئة فرعية أو اقتراحها كعنصر تحكم جديد أو اقتراحها لـ V2 حسب الحاجة.

SavoySchuler فيما يتعلق بـ "هل لدى أي شخص أي سيناريوهات تطبيق حقيقية تبرر الحاجة إلى دعم نظام سداسي عشري أو ثنائي؟" ، أحد الأمثلة على ذلك هو عنصر تحكم ColorPicker الخاص بـ WinUI. يتضمن مربع إدخال سداسي عشري. ويتضمن أيضًا عددًا من مربعات نص إدخال الأرقام الأخرى. قد يكون من المفيد النظر في إمكانية تحديث ColorPicker لاستخدام عنصر التحكم NumberBox الجديد كطريقة للتحقق من صحة عنصر التحكم الجديد. إذا كان بإمكان NumberBox تبسيط التنفيذ الحالي لـ ColorPicker ، فسيكون ذلك بمثابة فوز.

في حالة عدم تجاوز تصميم الحدود الرفيعة لمربعات النص @ chigy وقرار فريق تصميم WinUI - اعتقدت أنه يجب علي إعداد نموذج تصميم يطابق المقترحات الحالية لتصميم Text Box.

kmahone - متفق عليه. كما ذكرت في مبرد المياه هذا الصباح ، فإن القدرة على إزالة الكثير من التعليمات البرمجية الموجودة خلف ColorPicker من خلال استبدال مثيلاتها من TextBox + منطق التحقق المحلي مع NumberBox قد يكون فوزًا بحد ذاته.

mdtauk - هل أخبرتك مرات عديدة أن

SavoySchuler إذا قرر فريق تصميم Windows الوقوف إلى جانب فريق Fabric Web ، والانتقال من حدود سميكة epx إلى حدود 1epx - أعتقد أن ذلك سيعمل بشكل أفضل مع NumberBox - ولكن نظرًا لكونه عمليًا ، فقد يقوم فريق تصميم Windows بالحفر كعوبهم في والحفاظ على الحدود السميكة.

شيء أكيد ،mdtauk! آمل أن أغلق المتطلبات الوظيفية لـ وسأنتقل إلى محادثة تقارب التصميم مع

شكرًا لكم جميعًا على كل المناقشة ، يسعدني أن أعمل على هذه الميزة هذا الصيف كمتدرب!

إذا كان مناسبًا لأي شخص ، فقد بدأت نموذجًا أوليًا C # لعنصر التحكم في المستودع التالي.
https://github.com/KevinTXY/NumberBox

هذه هي المرة الأولى التي أتعلم فيها C # / UWP ، لذا ستأتي ببطء ، وإذا نظر إليها أي شخص ، يسعدني الحصول على تعليقات حول ما يمكن القيام به بشكل أفضل!

يتم تنفيذ الميزات التالية تقريبًا:

• التحقق من صحة الإدخال الرقمي (لا يتبع مواصفات اقتراح التحقق حتى الآن ، سينتظر رمز ذلك)
• تخزين القيمة / الربط
• تشذيب صفري
• الحاسبة الكاملة / دعم إدخال الصيغة

تعمل حاليًا على أزرار الدوران واختبار عناصر التطبيق بالإضافة إلى التحقق من الحد الأدنى / الأقصى.

هتافات!

تحديث الجدول الزمني!

لقد قمت بدمج العديد من التحديثات والاقتراحات وأجزاء من التعليقات في المواصفات التي سأقوم بالتحقق منها مع فريق WinUI اليوم (الخميس). آمل أن أكمل إلى حد ما واجهة برمجة التطبيقات والمكونات السلوكية لـ V1 في القيام بذلك.

الآن ، سوف أنتقل إلى المدخلات وإمكانية الوصول والبيانات والذكاء والمكونات المرئية.

ستكون الخطوة الأخيرة هي ترتيب الوثائق وتشكيل المبادئ التوجيهية.

أعتقد أن الخيار المفكك والمتجاور مناسب جدًا بدون حالة استخدام تحتاج تطبيقات الطرف الأول / واجهة مستخدم shell من Microsoft إلى القيام بها في WPF أو Win32.

إذا كنت تريد تضمينه ، فأنا أفضل أن يكون نمطًا مضمنًا يمكنك تطبيقه على عنصر التحكم ، بدلاً من أن يكون خيارًا. كيف يمكن لعناصر تحكم NumberBox المعاد تشكيلها التعامل مع تلك الخاصية ، في قوالبها الجديدة؟

إذا كان هناك إجماع على أنه يجب تضمين هذا الوضع ، فربما أقترح أن يصبح قيمة تعداد كجزء من SpinButtonPlacementMode . لست متأكدًا من اسم هذا الخيار. _Straddled_ ربما لا يكون محترفًا بدرجة كافية لول ، ولست متأكدًا من أن _Bookended_ أفضل.

كنت أنظر للتو إلى أحدث إصدار من Canary لـ Edge ، ورأيت تصميم <input type="number"/> وهو الأقرب إلى عنصر تحكم NumberBox.

فقط اعتقدت أنني سوف أشارك هذه الصورة منه.

mdtauk - موافق ، سيكون SpinButtonPlacementMode هو المكان المناسب لإضافة خيارات وضع SpinButton بديلة.

فيما يتعلق بموضوع الأسماء ، ظهر @ Felix-Dev بشكل صحيح على المواصفات التي قد لا يكون SpinButton هو الاسم الأكثر شهرة أو حدسيًا. SpinBox و UpDownButtons لها الأسبقية أيضًا في نظام Windows البيئي. سوف أتطرق إلى هذا قريبًا ، ولكن يرجى إعلامي إذا كان لدى أي شخص قضية ضد أي من هذه الخيارات.

mdtauk - شكرًا لك على مشاركة ذلك! أنا أدير Canary أيضًا ، لذلك سألقي نظرة وأرى ما إذا كان هناك أي شيء يمكننا تعلمه أو إذا كان هناك أي مجال لاقتراح مواءمة التطورات!

SavoySchuler أنا أستخدم علامة تم تمكين عناصر التحكم Fluent (بما في ذلك عناصر التحكم التجريبية)

أعتقد أن تطبيق WinUI سيكون تصميمًا أكثر تفكيرًا والذي يجب أن ينظر إليه Fabric Web و Edge ، لكن المحاذاة أمر جيد للقيام به.

w3schools رقم نوع الإدخال

كما أن شريط التمرير هذا قريب ، ولكن ليس تمامًا مثل ما تخطط WinUI للقيام به (إبهام دائري محدد ، مقارنة بإبهام دائري مملوء)

ما زلت غير متأكد من كيفية تعيين ميزات الترجمة. في الولايات المتحدة ، تُستخدم النقطة للفاصل العشري. في هولندا (حيث أعيش) نستخدم الفاصلة. فاصل التجميع في الولايات المتحدة هو الفاصلة ولكنه في هولندا هو النقطة.

مثال:

هل يجب استخدام خاصية Language لعنصر Framework لتحديد فاصل الأرقام والتجميع؟

<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>

كنت أنظر للتو إلى أحدث إصدار من Canary لـ Edge ، ورأيت تصميم <input type="number"/> وهو الأقرب إلى عنصر تحكم NumberBox.

فقط اعتقدت أنني سوف أشارك هذه الصورة منه.

mdtauk ، SavoySchuler ،
لا أعرف من أين أتت هذه السيطرة. وفقًا لجهة الاتصال الخاصة بي في فريق Edge ، إليك عناصر التحكم التي سيستخدمونها.

شريط التمرير: https://explore.fastdna.net/components/slider/
صندوق الأرقام: https://explore.fastdna.net/components/number-field/

لست متأكدًا مما إذا كانوا سيقومون بتحديث الصورة المرئية وقد لا يبدو الناتج النهائي تمامًا مثل هذا (أفترض ذلك ، لكن هذا تخميني الجامح).

chigy كانت هذه الصورة من إصدار Canary الحالي لـ Edge ، ولكن كما أشرت ، فهي قيد العمل قيد التقدم وهي علامة اختيارية تقوم بتشغيلها.

أعتقد أن هذا يفسر الغرض من مشروع فاستدنا ، والذي ذكرته في عدد سابق. 🙂

هل يجب استخدام خاصية Language لعنصر Framework لتحديد فاصل الأرقام والتجميع؟

تأتي هذه الإعدادات عادةً من "المنطقة" ، لذلك أعتقد أننا سنمرر في

لا أرى طريقة لتخصيص الأحرف الفاصلة في DecimalFormatter API لذا يجب سحبها من إعدادات اللغة. 😖

jevansaks ، شكرا لك على البصيرة! سأضع علامة على

jevansaks هل يمكنك كتابة مثال xaml كيفية تنسيق DecimalFormatter لـ NumberBox؟ أريد تعريفه بتنسيق XAML وليس من الخلف. كما أن وجود خصائص 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 كيفية تنسيق DecimalFormatter ل NumberBox؟ أريد تعريفه بتنسيق XAML وليس من الخلف. كما أن وجود خصائص DecimalSymbol و GroupingSymbol يمكن أن يعمل أيضًا بالنسبة لي. قد يكون هذا سهلاً للغاية على الرغم من ذلك.

sonnemaf ، كل ما علينا العمل معه في WinRT هو DecimalFormatter وللأسف لا يسمح لك بتخصيص هذه الإعدادات. الطريقة الوحيدة لتخصيص الرمز العشري أو رمز التجميع هي من خلال إعدادات المستخدم في لوحة التحكم في منطقة نظام التشغيل (بقدر ما أستطيع أن أقول).

يبدو أن احترام منطقة المستخدم لهذه الإعدادات صحيحًا - هل لديك سيناريو تحتاج فيه إلى تجاوزها؟

تضمين التغريدة

هل لدى أي شخص أي سيناريوهات حقيقية للتطبيق تبرر الحاجة إلى دعم نظام سداسي عشري أو ثنائي؟

آسف لقد لاحظت هذا والرد بعد قليل. أعتقد أن الدعم السداسي / الثنائي سيكون مفيدًا للغاية. أنا منخرط بشدة في مشروع .NET IoT ونعمل في الغالب في العالم السداسي / الثنائي حيث نتعامل مع وحدات البت / البايت التي تقرأ / تكتب إلى السجلات والدبابيس للتحكم في الأشياء.

سيكون دعم النظام السداسي / الثنائي ممتنًا للغاية. ثكس 😄

لا أحتاج إلى سداسي عشري أو ثنائي. سيكون من "اللطيف أن يكون لديك" ، خاصةً نظام ثنائي.

تحديث Dev

مرحبا جميعا! لقد أصبحنا راضين عن مواصفات NumberBox ، وأريد فقط أن ألفت الانتباه إلى أنني أعمل بنشاط على التحكم ، ومن الناحية المثالية ، سيتم تقديم أول علاقات عامة مع أهم الوظائف قريبًا جدًا ، وربما الليلة.

بعض الملاحظات:

• لقد اخترنا عدم تصنيف TextBox إلى فئة فرعية خاصة بسبب بعض تعقيدات التصميم مع InputValidation ، سيكون NumberBox هو عنصر التحكم الخاص به الذي يحتوي على TextBox.
  
  
  
  • هذا يعني أن جميع خصائص TextBox لن يتم كشفها. أشعر بالفضول لمعرفة ما إذا كان أي منها مهمًا لإبرازه لـ NumberBox - يمكنني رؤية الرغبة في _Header و PlaceHolderText_ وربما أيضًا _Text_؟ أردت بالتأكيد فتح هذا قليلاً لأنه تغيير سهل للغاية من ناحيتي.
  
  
• لقد أجريت تعديلات صغيرة جدًا على المواصفات ، وهذه في الغالب مجرد تصحيحات صياغة في الوقت الحالي ، ولكن لا تزال هناك أسئلة مفتوحة مثل معاينة القيمة ، وبينما أكتب عنصر التحكم ، أقوم بإنشاء بعض أسئلة التصميم الخاصة بي. لا يزال هذا هو الوقت المناسب لإضافة المدخلات 😄

KevinTXY كان هناك اقتراح واحد

• نص العنصر النائب
• رأس
• نص
• أيقونة التحقق
• رسالة التحقق
• اختيارالمقدمة
• اختيار الخلفية
• التركيز على الدول / الموارد ، إلخ

هذه بعض الأشياء التي أعتقد أنها مطلوبة في TextBox. لست متأكدًا من زر "نص واضح" ، والذي يكون أكثر منطقية مع السلاسل النصية الطويلة.

معاينة القيمة التي اعتقدت أنها ميزة V2 ، ولكن هل تغير هذا؟ يحتوي عنصر التحكم في شريط التمرير على تلميح يعرض القيمة ، مثل شرائح الإبهام. لقد اقترحت هذا كطريقة للتعامل معه ، بالإضافة إلى استخدام رسالة التحقق للتعامل مع هذا الأمر ، أو عرضه بشكل مضمّن.

توجد مشكلة مضمنة في حقيقة أن Windows Insider يبني تجربة لإكمال النص التنبؤي ، إما بالظهور كتلميح أداة ، أو داخل حقول النص. مهما كانت طريقة المعاينة التي يتم اختيارها ، يجب ألا تتعارض مع تلك ، أو يتم إيقاف تشغيل الميزة التنبؤية لعنصر التحكم هذا.

KevinTXY كان هناك اقتراح واحد

يعتبر NumberBox حاليًا عنصر التحكم الخاص به (يمتد Windows.UI.Xaml.Controls.Control) الذي يحتوي على TextBox في ترميزه بدلاً من توسيع TextBox. يبدو شريط التمرير مثيرًا للاهتمام ، لكنني أعتقد أنه قد يتسبب في أن يكون التطبيق صعبًا بعض الشيء ، فهناك أيضًا الكثير من الخصائص في عناصر التحكم هذه التي لم نشعر بالانتماء إليها في NumberBox. أنا لست رئيسًا للوزراء ولكن من تجربتي في تطوير هذا أشعر أن هذا طريق جيد لتبسيط التطوير ولإمكانية التوسع في المستقبل.

هذه بعض الأشياء التي أعتقد أنها مطلوبة في TextBox. لست متأكدًا من زر "نص واضح" ، والذي يكون أكثر منطقية مع السلاسل النصية الطويلة.

هذا رائع - بالضبط ما كنت أبحث عنه! أوافق على أن هناك قيمة في كل هذه الأشياء. يوجد زر مسح الكل حاليًا لأنه ميزة افتراضية في TextBox - أفترض أنه يحتوي على قيمة للإدخالات الكبيرة أو مستخدمي الشاشة التي تعمل باللمس على الرغم من أنني لم أفكر في تعطيله حتى الآن. سأحاول بالتأكيد على الأقل إدخال العناصر الثلاثة التي ذكرتها (Header ، PlaceholderText ، Text) في المعاينة.

بالنسبة لمعاينة القيمة ، لم يتم الانتهاء من أي شيء هناك فقط في المواصفات كسؤال مفتوح. أفترض أن الحل المؤقت الأسهل هو ببساطة عرض قيمة المعاينة للمطورين لعرضها كما يحلو لهم - يمكن أن يكون ذلك في نطاق إصدار المعاينة بسهولة ، لكنني سأتركه لـ

KevinTXY من الناحية المثالية ، سيكون هناك تعاون مع فريق الحاسبة ، لإنشاء محرك حساب أساسي يمكن تضمينه - وكذلك للاستخدام في المستقبل مع فكرة CalculatorPicker التي تمت مناقشتها جنبًا إلى جنب مع عنصر التحكم هذا. (عنصر تحكم مع زر آلة حاسبة ، يعرض قائمة منبثقة بآلة حاسبة قياسية)

في الواقع ، يبدو التعاون مع المشرفين على الحاسبة فكرة رائعة. يمكنك الكشف عن خدمة التطبيق من الحاسبة التي من شأنها إجراء العمليات الحسابية ، لذلك لن تحتاج حتى إلى تنزيل ملف WinUI الثنائي - فقط تحدث إلى خدمة التطبيق إذا كان التطبيق مثبتًا وإلا - فقط تفشل بصمت.

بالنسبة للاشتقاق من Slider - لقد قلت بالفعل

آه نعم ، RangeBase ، كان هذا هو.

لقد أنجزت الآلة الحاسبة مؤخرًا العمل لدعم وضع CompactOverlay دائمًا في القمة - لذا فإن الحصول على لوحة مفاتيح أصغر في قائمة منبثقة مماثلة في الحجم لـ CalendarFlyout - يمكن تحقيقه بشكل أكبر. (إذا تمت الموافقة على عنصر تحكم CalculatorBox للتضمين.

لست متأكدًا مما إذا كانت خدمة التطبيق (التي من شأنها ربط تحديثات WinUI شبه معتمدة على تحديثات متجر الحاسبة - أو إذا كانت خدمة ثنائية يمكن إضافتها إلى WinUI ومشتقة من محرك الحاسبة.

تحديث: كود العلاقات العامة موجود الآن 🎆!

أتتبع بعض المشكلات هناك ، على الرغم من أن معظمها لا يتعلق بالتصميم.

شكرًا لك ، xyzzer وmdtauk! لقد قمنا بفحص RangeBase ويبدو أنه يحمل نفس القدر من الأمتعة كما هو الحال في فئة TextBox. اعتبارًا من الآن ، سنلتزم باحتواء TextBox في عنصر التحكم وإضافة الخصائص الضرورية وميزات إمكانية الوصول فقط. كان هذا لا يزال اعتبارًا جديرًا بالاهتمام وساعد في إعلام محادثة الوصول التي تحدث الآن.

mdtauk ، شكرًا لك على قائمة البداية! بدأ KevinTXY في كشف واجهات برمجة التطبيقات التي أدرجتها

معاينة والآلة الحاسبة المنبثقة ، مثل KevinTXY المذكورة ، في المحادثات (على الرغم من عدم وجود ضمان v1 هنا). نحن نتحدث بنشاط مع الآلة الحاسبة حول المحاذاة والعمل الذي يمكن الاستفادة منه. انتم رائعون أيها الشبان! شكرا لمواصلة دفع الابتكار في هذا التحكم. رهيبة. KevinTXY له كود العلاقات العامة المنشور أعلاه. سأقوم بربط جميع النهايات السائبة المتبقية على المواصفات بوقت قصير قبل الانتقال إلى صياغة التوجيه والتوثيق.

تسمية

كان هناك الكثير من التعليقات التي أفلتت مني المواصفات لذا بدأت للتو في إلقاء نظرة على الأمور المستقرة. أولاً ، لاحظت أن بعض الأسماء لا تتبع حقًا اصطلاح C # - نعم أعلم أن عناصر التحكم هذه مكتوبة بلغة C ++ لكنني ما زلت أعتقد أنها غير متوافقة مع التسمية الأخرى في النظام الأساسي.

| اكتب | الاسم الحالي | الاسم المقترح |
| ------- | ---------------- | ------------------- |
| منطقي | يقبل الحساب | تم قبول الحساب |
| منطقي | HyperDragEnabled | IsHyperDragEnabled |
| منطقي | HyperScrollEnabled | IsHyperScrollEnabled |

التردد

أيضا ، ما هو StepFrequency؟ لم يتم تحديد ذلك في المواصفات وليس لدي أي خبرة مع "NumericUpDown لمجموعة أدوات XAML". اعتمادًا على ما يفعله هذا ، قد لا تكون إضافة كلمة "تردد" منطقية. ربما تكون مجرد "خطوة"؟ في عنصر التحكم في شريط التمرير ، يكون تردد TickFrequency منطقيًا لأن العلامات تظهر على معامل النطاق الأقصى-min الكلي. ومع ذلك ، أعتقد أن هذا هو الحد الأدنى لحجم الزيادة / الخطوة في عنصر التحكم هذا. بشكل أساسي ، هل سيتمكن المستخدم من إدخال قيمة خارج الخطوة؟

على سبيل المثال MinValue = 0، MaxValue = 6، StepFrequency = 2. استخدام قيمة السهم لأعلى سيكون {2، 4، 6} عادلًا بدرجة كافية. هل يمكن للمستخدم كتابة 0.5 كقيمة صالحة؟ أم سيتم تقريب ذلك إلى 0 أو 2 حسب RoundingMode؟

Min / MaxValue

بالنسبة للخاصيتين أدناه ، أعتقد أنهما يجب أن يكونا الحد الأدنى والحد الأقصى كما هو الحال في عناصر التحكم الأخرى (Slider ، RangeBase). يجب أن تكون واجهة برمجة التطبيقات متسقة.
ضعف MinValue ؛
مضاعفة MaxValue ؛

أزرار التكرار UpDown

هناك ميزة أخرى لم تتم مناقشتها على حد علمي وهي ما إذا كان يجب إنشاء أزرار لأعلى / لأسفل فعلاً RepeatButtons (أعتقد أنهما يجب أن يكونا كذلك). إذا كانت أزرار التكرار ، فيجب إضافة خصائص Delay / Interval مثل عنصر التحكم في شريط التمرير: Slider.Interval Slider.Delay

أرقام

هل يمكنك إضافة وصف لما تمثله IntegerDigits و FractionDigits؟ أظن أنهم يحدون من عدد الأرقام لكل جزء من الرقم. IntegerDigits = 2 تعني أن الحد الأقصى للقيمة يمكن أن يكون 99. FractionDigits = 3 يعني أن MaxValue يمكن أن يكون 0.999. أيضًا ، كيف تتجاوز SignificantDigits هاتين الخاصيتين؟

سلبي صفر؟

لماذا هذه الخاصية مطلوبة؟ هل هذا شيء تعريب بحد ذاته؟ لم أر قط "-0.0" أو "-0". إنه دائمًا "0" فقط.
منطقية IsZeroSigned ؛

الموقع

أنا مصرة على أنني بحاجة إلى عنصر التحكم هذا لدعم تجاوز تنسيق الأرقام وترجمة واجهة المستخدم. لدي استخدامات متعددة (تطبيقات مالية) حيث أحتاج إلى مبالغ محلية وأجنبية يجب عرضها بشكل مختلف. لا أرى هذا في أي مكان في المواصفات.

يجب أن يكون التحويل من المضاعفة إلى النص قابلاً للتخصيص عبر ValueConverter ، بروح Slider.ThumbToolTipValueConverter. بهذه الطريقة يمكن تخصيص الجزء الأكثر تعقيدًا لأي احتياجات ، كما هو الحال في بعض الأمثلة الواقعية أدناه:

لاحظ أن الفاصل العشري للأرقام والأموال يمكن أن يكون مختلفًا ، بالإضافة إلى تعيين المبالغ السالبة ، لذلك من المحتمل أن يكون الأسلوب الأكثر أمانًا لـ NumericBox بدون ValueConverter هو العمل في وضع عدد صحيح. يمكن تطبيق الآلة الحاسبة على أنها ValueConverter أيضًا ، ليست هناك حاجة لزيادة تحميل عنصر التحكم بهذا العمل.

eugenegff لديك فكرة جيدة حقًا لجعل الرقم إلى سلسلة تحويل عام. سيسمح لي هذا بالتعامل مع الترجمة ولكن أيضًا يسمح للمطورين بفعل أي شيء آخر قد يرغبون فيه مثل إضافة الوحدات.

التعقيد الوحيد الذي أراه هو الاحتفاظ بثقافة / NumberFormatInfo مرتبطة بعنصر التحكم. أعتقد أن هذا يمكن أن يكون معلمة محول في XAML تذهب إلى IValueConverter المخصص ولكن ربما يجب أن تكون هناك طريقة أنظف للتعامل مع هذا في عنصر التحكم نفسه.

لماذا هذه الخاصية مطلوبة؟ هل هذا شيء تعريب بحد ذاته؟ لم أر قط "-0.0" أو "-0". إنه دائمًا "0" فقط.

إنها خاصية من فئة DecimalFormatter في النوافذ. هل هذا غريب؟ المحتمل. هناك بعض الخصائص مثل IsGrouped وخصائص الترجمة التي تركناها ، لذا ربما لا تكون هذه الخاصية ضرورية أيضًا. في الوقت نفسه ، تم تنفيذه بالفعل ، لذا لن يكون لإزالته أي غرض سوى فك ثلاثة أسطر من التعليمات البرمجية. ومن المثير للاهتمام أن هناك استخدامات ومتطلبات IEEE لتوقيع الأصفار .

أنا مصرة على أنني بحاجة إلى عنصر التحكم هذا لدعم تجاوز تنسيق الأرقام وترجمة واجهة المستخدم. لدي استخدامات متعددة (تطبيقات مالية) حيث أحتاج إلى مبالغ محلية وأجنبية يجب عرضها بشكل مختلف. لا أرى هذا في أي مكان في المواصفات.

SavoySchuler ربما يجب علينا النظر في دعم إعدادات اللغات في فئة DecimalFormatter؟ أنا لست على دراية كيف يتصرف بالرغم من ذلك.

حسنًا ، أعتقد أنني أفهم المشكلة الأساسية هنا. في عالم C ++ ، يمكنك الوصول إلى DecimalFormatter ولكن في عالم C # (هل كنت أستهلك WinUI) عادةً ما أستخدم IFormatProvider (NumberFormatInfo من ثقافة محددة). يحتوي NumberFormatInfo بالفعل على معظم الخصائص (يفتقد IsZeroSigned بالصدفة) لذلك كنت أفكر فقط السماح للمطورين بتحديد ذلك أو IFormatProvider. حسنًا ، هناك مشكلة ، لا يمكن لـ C ++ استخدام IFormatProvider لأنه من عالم .net.

إذن كيف يدعم عنصر التحكم هذا بشكل كامل الترجمة في C # و C ++ مع الأخذ في الاعتبار أن لديهم طريقتين مختلفتين للقيام بذلك؟ حسنًا ، ما لم يكن لدى Microsoft حلاً ذكيًا ، لا يمكنني التفكير إلا في احتمالين:

1. قم بإضافة كافة الخصائص لتنسيق الأرقام بالكامل (إعادة تنفيذ NumberFormatInfo و DecimalFormatter بشكل فعال). إن إضافة IsZeroSigned و IntegerDigits و FractionalDigits وما إلى ذلك فقط لن يغطيها. NumberNegativePattern ، NumberGroupSeparator ، NumberGroupSizes ، كلها مطلوبة أيضًا.
2. افعل كما اقترح eugenegff واسمح للمطورين بتجاوز التنسيق بنوع من إعادة الاتصال. بصراحة ، يبدو أن هذا هو النهج الأسهل.

أنا مهتم قليلاً بكيفية تشكل الأقلمة في هذا التحكم. لقد كنت أتحدث عن الترجمة منذ البداية (التعليق الثالث على هذا الموضوع!). يجب أن تكون هناك طريقة ما لتخصيص تنسيق الأرقام بالكامل عندما يتحول عنصر التحكم إلى سلسلة. بدون ذلك ، سيكون هذا التحكم محدودًا جدًا في استخدام العالم الحقيقي.

إذن كيف يدعم عنصر التحكم هذا بشكل كامل الترجمة في C # و C ++ مع الأخذ في الاعتبار أن لديهم طريقتين مختلفتين للقيام بذلك؟

لقد سمعناك! إنه شيء كنا نحقق فيه في وضع عدم الاتصال ، ولكن NET بشكل أساسي يقوم بعملية الترجمة الخاصة به بشكل منفصل عن النظام الأساسي. أعتقد أن رد الاتصال للتخطي هو فتحة هروب رائعة ، لكني آمل أن يكون خيارك الأول هو الطريق الذي يمكننا الذهاب إليه. في الوقت الحالي ، لا تحتوي واجهات برمجة تطبيقات WinRT للتنسيق والتحليل على جميع مقابض التخصيص التي نحتاجها. ما زلنا نحقق.

لم تتحقق مما إذا كان هذا قد تمت مناقشته بالفعل ، ولكنك أردت أن تسأل بسرعة عما إذا كان أي شخص يرى حاجة كبيرة أو الأهم من ذلك أي سابقة لدعم الوظائف للحسابات ، وهذا يعني أيًا مما يلي أو أكثر:
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

أنا أقوم بتجميع محللات الرياضيات معًا لتناسب احتياجاتنا ووظائفنا مما يعقد عملية التحويل إلى RPN (والذي قال إن لدي بالفعل إصدارًا يدعم هذه الأخطاء مع بعض الأخطاء) ، لذلك أنا مهتم بمعرفة ما إذا كان أي منها يستحق المتاعب أو إذا بدا الأمر وكأنه انتفاخ. أنا شخصياً لا أعتقد أنه يناسب بشكل جيد للغاية ، لكن إذا كان هناك الكثير من السوابق ، فليس الأمر مزعجًا للغاية.

أعتقد أن هذا لن يكون قابلاً للاكتشاف في معظم الحالات وإذا احتاج أي شخص إلى دعم لوظائف أكثر تعقيدًا - فمن الأفضل العمل على فتح التحليل لحدث رد الاتصال مما يسمح للمستخدمين بتنفيذ منطق التحليل أو المعالجة المسبقة الخاصة بهم.

ما قد يكون أكثر قيمة هو السماح ببدء كتابة النص باستخدام عامل تشغيل ، لذلك إذا قمت بالنقر فوق النص - فسيتم تحديد الكل افتراضيًا ويمكنك إما كتابة قيمة جديدة دون الحاجة إلى الضغط على حذف أولاً لحذف القيمة السابقة أو ما عليك سوى كتابة شيء مثل "* 1.2" أو "x1.2" [Enter] واضرب القيمة الحالية في 1.2 حتى في حالة عدم احتواء النص الذي تم إدخاله على القيمة التي تم إدخالها بعد الآن. يعمل نفس الشيء مع "+2" ، "-5" ، "/ 3" ، "٪ 120" ، إلخ.

يتم استخدامه في بعض التطبيقات المهنية.

نحن (BeLight Software ، Live Home 3D project) نحتاج إلى ValueConverter القابل للتوصيل من أجل تحويل نصي بقيمة <=> ، وإلا فإن NumberBox سيكون غير مناسب لنا.

أعتقد أن استخدام هذه الوظائف سيكون نادرًا جدًا ، لديّ مدخلات زاوية في تطبيقي لكنها مجرد قيمة درجة. أهم استخدام بالنسبة لي هو أن أكون قادرًا على إضافة قيمة إلى القائمة أو القسمة على رقم ، فقط لتوفير الوقت وتجنب القيام بهذا الحساب ذهنيًا. (بالمناسبة ، أعتقد أن هذا ما تمتلكه تطبيقات Adobe ، المشغلين الحسابيين الأربعة: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -مجالات)

تعمل أيضًا مثل cos () ربما لا تريدها حيث لا يكون لها معنى ، إلا إذا كنت تقوم بإنشاء نوع من تطبيقات Excel.

أهم استخدام بالنسبة لي هو أن أكون قادرًا على إضافة قيمة إلى القائمة أو القسمة على رقم ، فقط لتوفير الوقت وتجنب القيام بذلك الحساب ذهنيًا

حسنا عظيم! يبدو مشابهًا لما اقترحه xyzzer . سألقي نظرة على التطبيقات المماثلة وأرى ما إذا كان هناك مجال للقيام بذلك بطريقة تبدو طبيعية وبديهية.

نحن (BeLight Software ، Live Home 3D project) نحتاج إلى ValueConverter القابل للتوصيل من أجل تحويل نصي بقيمة <=> ، وإلا فإن NumberBox سيكون غير مناسب لنا.

لقد ألقيت نظرة على مثال Slider الذي قدمته ويبدو أنه معقول جدًا - يمكنني رؤية قيمة في IValueConverter لـ NumBox. سأبحث في الأمر قريبًا وسنحاول تحديد ما إذا كان يتناسب مع المواصفات بشكل مناسب. لا توجد وعود على أي شيء حتى الآن!

KevinTXY أظن أن إضافة الوظائف التي ذكرتها أعلاه ستفتح الباب أمام مشاكل أكثر من القيمة التي قد توفرها. هذا لأنه سيسمح بكتابة عدد أكبر من الأحرف (بشكل أساسي أي حرف) في عنصر التحكم. وهذا بدوره سيجعل من السهل كتابة شيء غير صالح عن طريق الخطأ وسيضيف أيضًا التحقق من الصحة والتحليل التعقيد.
سيؤدي أيضًا إلى كسر السطر الأول من الوصف في بداية المواصفات "مربع الرقم هو عنصر تحكم نصي رقمي فقط ...".

أنا مندهش من استمرار وجود أسئلة حول الأقلمة. نظرًا لأن عنصر التحكم سوف (يجب؟) أن يرث من FrameworkElement فإنه سيكون لديه حق الوصول إلى خاصية اللغة ، وبالتالي ، مثل كل FrameworkElement ، يدعم إعداد الإعدادات المحلية مباشرة ولا يعتمد على إعدادات واجهة المستخدم المحلية للنظام.
هذا يعني أنه يمكن تعيين أشياء مثل الأحرف العشرية والتجميع على أساس كل حالة.

أنا مندهش من استمرار وجود أسئلة حول الأقلمة.

المشكلة هي أن اللغة ليست هي الشيء الذي يتحكم في التنسيق ، إنها إعدادات المنطقة / الثقافة. تتعلق الترجمة بتحديث سلاسل واجهة المستخدم لعرضها باللغة الصحيحة بينما يتم التحكم في تنسيق الرقم / العملة / التاريخ والوقت حسب المنطقة. مزيد من المعلومات هنا: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. ولتعقيد الأمور ، يسمح لك Windows بتخصيص إعدادات الإعدادات المحلية في واجهة المستخدم عن طريق تجاوز الإعدادات الافتراضية - لذا يمكنك القول أنك تريد أن يكون الفاصل العشري أي حرف عشوائي بدلاً من الافتراضي. علاوة على ذلك ، يسمح .NET للتطبيقات بتخصيص ذلك أيضًا بحيث يتوقع المطورون هذا المستوى من التخصيص هنا.

المشكلة هي أن اللغة ليست هي الشيء الذي يتحكم في التنسيق ، إنها إعدادات المنطقة / الثقافة. تتعلق الترجمة بتحديث سلاسل واجهة المستخدم لعرضها باللغة الصحيحة بينما يتم التحكم في تنسيق الرقم / العملة / التاريخ والوقت حسب المنطقة. مزيد من المعلومات هنا: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. ولتعقيد الأمور ، يسمح لك Windows بتخصيص إعدادات الإعدادات المحلية في واجهة المستخدم عن طريق تجاوز الإعدادات الافتراضية - لذا يمكنك القول أنك تريد أن يكون الفاصل العشري أي حرف عشوائي بدلاً من الافتراضي. علاوة على ذلك ، يسمح .NET للتطبيقات بتخصيص ذلك أيضًا بحيث يتوقع المطورون هذا المستوى من التخصيص هنا.

يأخذ Language قيمة تترجم إلى CultureInfo لاحظ أن الثقافة تسمى لغة في تطوير التعليمات البرمجية غير المُدارة. يحتوي هذا على خاصية NumberFormat وهي من النوع NumberFormatInfo وتحتوي على خصائص الكسور العشرية والتجميع والعلامات السلبية والمزيد.

ما أفهمه هو أنك إذا كنت تريد فرض تنسيق معين أو غير ذلك من تفاصيل التوطين على عنصر تحكم ، بدلاً من الاعتماد على إعدادات النظام ، فإن طريقة القيام بذلك هي تحديد Language .

يوضح وصف الخاصية بوضوح أنه "يحدد معلومات لغة الترجمة / العولمة التي تنطبق على FrameworkElement"

أو ربما أسأت فهم المستندات التي أشير إليها ، لكن يبدو أنهم جميعًا يدعمون ما يتم تغطيته في الصفحة التي قمت بالربط بها.
ربما تكون مشكلة المصطلحات مع C ++ و C # باستخدام مصطلحات مختلفة.
ما أعرفه هو أن إعداد اللغة في XAML هو كيف يمكنني فرض ثقافة / لغة في أي تطبيق آخر ومع أي عنصر تحكم آخر.

كانت الأسئلة التي رأيتها حول الأقلمة تدور حول فرض تنسيقات أرقام محددة ، أو فواصل المجموعات والفواصل العشرية. أم أن المشكلة الحقيقية ، كيف تتحكم فيها دون التأثير على توطين الخصائص المستندة إلى النص (Header ، PlaceholderText ، إلخ) لعنصر التحكم؟

يأخذ Language قيمة تترجم إلى CultureInfo

ليس في برنامج WinRT الأصلي ، نحصل فقط على سلسلة BCP-47 langs. وهذه هي المشكلة. في. NET لكم حزمة حتى CultureInfo الذي يحتوي على إعدادات اللغة وإعدادات تنسيق. في WinRT يكون منفصلًا وليس هناك ما يعادل كائن CultureInfo.

سمعت أن واجهات برمجة تطبيقات وحدة العناية المركزة قد تمكن ما نبحث عنه ولكن لم تتح لنا الفرصة للتحقيق في ذلك حتى الآن.

أعتقد أن Microsoft ستضطر إلى التفكير في هذا الأمر والتنفيذ الكامل لآلية التحويل بين ثقافات الشبكة / التعريب (CultureInfo) والنسخة الأصلية / WinRT. من الناحية المثالية ، لن تفكر في طريقة جديدة للقيام بالأشياء:

أعتقد أن الكود المُدار هو ما تتم كتابة غالبية تطبيقات LOB فيه ويجب القيام بذلك بشكل صحيح من البداية. يحتاج WinRT إلى الحصول على نفس آليات / تقنيات الترجمة مثل .net ويجب أن تكون التحويلات تلقائية.

هل سيكون ذلك الكثير من العمل؟ المدى القصير: نعم ، المدى الطويل: لا. هل سيؤدي ذلك على الأرجح إلى تأخير إطلاق عنصر التحكم في NumberBox؟ ربما ، ما لم يتم استخدام عمليات الاسترجاعات على المدى القصير.

يجب القيام بذلك بشكل صحيح أو ستكون هناك مشاكل في مكان آخر. يمكنني بالفعل توقع بعض المشكلات المماثلة مع سيناريوهات أخرى مثل CalendarDatePicker القابل للتحرير ، وما إلى ذلك (# 735)

SavoySchulerjevansakschigymrlaceyKevinTXY
من الواضح أن فريق FastDNA يعمل أيضًا على التحكم في Spinner لتصميم حقل رقم الإدخال ، وقد توصلوا إلى اقتراح قد يستحق الدراسة.

كما سألوا لماذا نستخدم شركة Chevrons بدلاً من الأسهم.

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

حتى لو احتفظنا بالأزرار جنبًا إلى جنب ، فإن وجود التصميم الموسع المكدس كتمرير ، يمكن أن يكون فكرة عندما يكون عرض التحكم ضيقًا جدًا؟ ربما يمكن أن يكون هناك بعض الإجماع على التخطيط الذي يعمل عبر جميع أطر عمل Microsoft UI؟

mdtauk ، شكرًا لإعلامنا بذلك.
التحقق من مستخدمي FastDNA إذا كان هذا هو التصميم الذي يختبرونه ويتحققون من قابلية الاستخدام عليه.

مرة أخرى على NumberBox

فريق جيد ،

نعتذر عن الفاصل غير المتوقع. لقد عدت إلى NumberBox بكامل طاقته و teaP تنضم إلي بصفتي مطور الميزات لدينا! ما زلنا نستهدف نهاية شهر نوفمبر لمعاينة عنصر التحكم هذا ، والذي سيجعلنا نتطلع إلى إصدار مستقر مع WinUI 2.4.

هناك الكثير من الأمتعة في سير العمل القديم ، لذلك سأحتفظ بأي أسئلة مفتوحة أو تمت الإجابة عليها سننهيteaP وأنا من حل المواضيع المفتوحة المتبقية فيما يتعلق بما يلي:

• الموقع
• التصميم (خاصة فيما يتعلق بأزرار أعلى / أسفل)
• hyperscroll / hyperdrag

لاحظ أنه تم حل موضوع التحقق. مع جدولة عمل التحقق من صحة الإدخال LucasHaines لإصدار WinUI 3.0 و NumberBox التخطيط قبل ذلك ، قمنا بتقليل أوضاع التحقق من الصحة المعتمدة في NumberBox V1 إلى:

تعداد NumberBoxBasicValidationMode
{
معاق،
InvalidInputOverwritten ،
} ؛

تعال إلى WinUI 3.0 وأعمال التحقق من صحة الإدخال المطلوبة المشتركة ، سنبحث عن توسيع هذا التعداد باستخدام أوضاع التحقق من صحة IconMessage و TextBlockMessage المخطط لها أصلاً في NumberBox V2.

سأقوم الآن بإنهاء جميع تقدمنا ​​السابق احتياطيًا ، وسأنشر الأسئلة وأطلب التعليقات حسب الاقتضاء. شكرا لبقائك معنا. 😄

تفو. كان يقترب مني وأنا أحاول القيام بذلك بنفسي.

هههه كنت أرغب في مواصلة العمل على هذا بشكل سلبي ولكن هذا الفصل الدراسي دهسني. يسعدني أن أرى أنه يتم الانتهاء منه ، وسأراقب ذلك!

الالتزام الأولي لـ NumberBox مباشر الآن!

PLEASE - نضع في اعتبارنا هذا لا يزال العمل جاريا مع تتبع القضية النشطة على كل من ديف و PM الجانب من الأمور. إذا رأيت أخطاءً أو نهايات فضفاضة عامة على الميزات التي لم يتم تدوينها بالفعل في أي من الروابط المناسبة ، فلا تتردد في إخبارنا بذلك. 😊

SavoySchuler ، هل ستفتح هذا التعليق بشكل خاص حول عرض NaN؟ شكرا.

SavoySchuler بعض التعليقات على المواصفات / كود NumberBox حتى الآن. نأمل أن تنتهي التعليقات على هذا في المواصفات / الوثائق أيضًا. بشكل عام ، إنه لأمر رائع أن نرى هذا يجتمع معًا!

التردد

استخدام كلمة "تردد" هنا لا يناسبني تمامًا. في عنصر التحكم في شريط التمرير ، يكون تردد TickFrequency منطقيًا لأنه يتم حساب العلامات وعرضها على معامل النطاق الأقصى-min الكلي. ومع ذلك ، في عنصر التحكم هذا ، يكون حجم الزيادة / الخطوة فقط. إنها أكثر من "StepAmount" أو "StepValue" - أفضل من ذلك "خطوة" تشبه "Minimum" بدلاً من "MinimumValue".

أيضًا ، هل سيتمكن المستخدم من إدخال قيمة خارج الخطوة المحددة؟
على سبيل المثال الحد الأدنى = 0 ، الحد الأقصى = 6 ، التردد التدريجي = 2. استخدام قيمة السهم لأعلى سيكون {2 ، 4 ، 6} مقبولًا بدرجة كافية. هل يمكن للمستخدم كتابة 0.5 كقيمة صالحة؟ أم سيتم تقريب ذلك إلى 0 أو 2؟

التقريب

كيف يتم التعامل مع التقريب الرياضي؟ هذا مهم بشكل خاص عند إدخال قيم العملة باستخدام التعبيرات. يجب أن نكون قادرين على تحديد - أو توفير - التقريب المخصص بعد حساب التعبير. إن HalfAwayFromZero هو ما أبحث عنه للبدء ولكن يجب السماح أيضًا بأوضاع التقريب الأخرى.

الموقع

يرجى تأكيد أن NumberBox سيقبل أي تطبيق لـ INumberFormatter / INumberFormatter2 - وسيواصل القيام بذلك في المستقبل (هذه هي الطريقة التي يتم تنفيذها في الكود ، أريد فقط التأكد من أن المواصفات تستدعيها أيضًا). يجب أن يسمح ذلك بالتحكم الكامل في ترجمة النص مقارنة باستخدام CurrencyFormatter / DecimalFormatter الموجود. إنه لأمر رائع أن يكون لدينا حل لهذا!

التفاف النص

تحرير: يجب أن أقرأ المواصفات بأكملها في المرة القادمة.

لماذا أنشأت خاصية "IsWrapEnabled" جديدة؟ هل هذا لأنك تشعر أن مصطلح "نص" لا ينطبق جيدًا على NumberBox؟

أيضًا ، أفهم أنه ربما يتم تنفيذ كل من Wrap و WrapWithOverflow بنفس الطريقة ولكن بعد ذلك فقط السماح لقيمتي التعداد بأن تكون مكافئة ووصف الوظيفة في الوثائق.

التعامل بشكل صحيح مع مسرّعات لوحة المفاتيح

يرجى التأكد من أن عنصر التحكم هذا يدعم استخدام مسرع لوحة المفاتيح بشكل أفضل من TextBox. ربما لا يمكن القيام بذلك حتى / إذا تم إصلاح TextBox ، ولكن # 1435 يمثل مشكلة بالنسبة لي والتي تسبب الكثير من الأعمال القبيحة. سيتعامل TextBox مع لصق "Ctrl + V" نفسه ثم يتم رفع أي برنامج KeyboardAccelerator. ومع ذلك ، لا توجد طريقة داخل KeyboardAccelerator لمعرفة أن TextBox قام بعمله الخاص.

فكرة سريعة. هل يجب أن يكون هناك وضع Angle Mode الذي من شأنه إلحاق الحرف الرسومي بالقيمة (وأي منطق للالتفاف بزاوية 360 درجة)

°

أم أنه سيتم التعامل مع هذا الملحق بشكل أفضل في المستقبل من خلال اقتراح اللاحقة الخاصة بي لمربع النص # 784

mdtauk ، سيكون من الممكن إضافة رمز الدرجة باستخدام INumberFormatter2 - وهذا سبب وجيه آخر يجب أن يظل عامًا. يمكنك القيام بكل ما هو ضروري لتحويل رقم إلى سلسلة وإعادة السلسلة إلى عنصر التحكم.

للتغليف ، هذا في الواقع ما تستخدمه خاصية IsWrapEnabled ... أحتاج إلى قراءة نهاية التوثيق في المرة القادمة.

خلاصة القول ، أعتقد أنه يمكننا فعل كل ما تريده باستخدام واجهة برمجة التطبيقات الحالية.

mdtauk ، سيكون من الممكن إضافة رمز الدرجة باستخدام INumberFormatter2 - وهذا سبب وجيه آخر يجب أن يظل عامًا. يمكنك القيام بكل ما هو ضروري لتحويل رقم إلى سلسلة وإعادة السلسلة إلى عنصر التحكم.

للتغليف ، هذا في الواقع ما تستخدمه خاصية IsWrapEnabled ... أحتاج إلى قراءة نهاية التوثيق في المرة القادمة.

خلاصة القول ، أعتقد أنه يمكننا فعل كل ما تريده باستخدام واجهة برمجة التطبيقات الحالية.

أعرف أن Min ، Max ، Wrap ، يتعامل معها ، لكن هل الدرجات شائعة بما يكفي للحصول على وضع زاوية واضح للمربع؟ وينبغي أن يعرض الرمز في نص مربع النص ، بينما القيمة الداخلية هي الرقم فقط.

teaP بالنظر إلى SpinButtonMode المضغوط الجديد ، هل من الممكن إضافة عرض وإخفاء الرسوم المتحركة إلى أزرار Spin المتراكبة؟

هل فكرت أيضًا في إضافة أكريليك إلى هذا ، لمطابقة مربعات التحرير والسرد وحقول النموذج الأخرى بشكل أفضل مع عناصر منبثقة؟

تحرير: سيصلح هذا مشكلة الرؤية في Dark Theme. هل النية لمطابقة اللون المركز لمربع النص أم مطابقة ألوان النسق الحالية؟ في كلتا الحالتين ، أكريليك يحل هذا.

SavoySchuler ، هل ستفتح هذا التعليق بشكل خاص حول عرض NaN؟ شكرا.

adrientetar بالتأكيد. عندما يكون NumberBox فارغًا ، سيتم تعيين Value على NaN (كما طلبت) وسيظهر PlaceholderText .

SavoySchuler بعض التعليقات على المواصفات / كود NumberBox حتى الآن. نأمل أن تنتهي التعليقات على هذا في المواصفات / الوثائق أيضًا. بشكل عام ، إنه لأمر رائع أن نرى هذا يجتمع معًا!

التردد

استخدام كلمة "تردد" هنا لا يناسبني تمامًا. في عنصر التحكم في شريط التمرير ، يكون تردد TickFrequency منطقيًا لأنه يتم حساب العلامات وعرضها على معامل النطاق الأقصى-min الكلي. ومع ذلك ، في عنصر التحكم هذا ، يكون حجم الزيادة / الخطوة فقط. إنها أكثر من "StepAmount" أو "StepValue" - أفضل من ذلك "خطوة" تشبه "Minimum" بدلاً من "MinimumValue".

لقد شاركت هذه التعليقات مع MikeHillberg ونحن نتحدث عنها الآن. لكي نكون توثيقًا ذاتيًا من بين جميع الخصائص الأخرى هنا ، فإننا نفكر في شيء على غرار "SpinButtonStep" إذا كان هذا المنطق مبررًا كافيًا للانحراف. سأخبرك. شكرا لإثارة النقطة!

أيضًا ، هل سيتمكن المستخدم من إدخال قيمة خارج الخطوة المحددة؟
على سبيل المثال الحد الأدنى = 0 ، الحد الأقصى = 6 ، التردد التدريجي = 2. استخدام قيمة السهم لأعلى سيكون {2 ، 4 ، 6} مقبولًا بدرجة كافية. هل يمكن للمستخدم كتابة 0.5 كقيمة صالحة؟ أم سيتم تقريب ذلك إلى 0 أو 2؟

يمكن للمستخدم إدخال أي مدخلات ذات صيغة رقمية أو قانونية يحلو لها. راجع قسم التنسيق للحصول على مثال حول كيفية استخدام خاصية NumberFormatter ثم إجبار هذا الإدخال على التنسيق الذي تم تكوينه.

سيزيد SpinButton هذه القيمة أو ينقصها فقط من خلال حجم خطوة SpinButton المحدد (اسم API معلق الآن). لذا تأكد من تكوين التنسيق وحجم الخطوة اللذين يعملان معًا بشكل جيد.

يتم تحديد استراتيجية التقريب المستخدمة من خلال التنسيق الخاص بك. للشرح في مثال DecimalFormatter ، إليك مثال على خاصية التقريب التي يمكنك تكوينها.

التقريب

كيف يتم التعامل مع التقريب الرياضي؟ هذا مهم بشكل خاص عند إدخال قيم العملة باستخدام التعبيرات. يجب أن نكون قادرين على تحديد - أو توفير - التقريب المخصص بعد حساب التعبير. إن HalfAwayFromZero هو ما أبحث عنه للبدء ولكن يجب السماح أيضًا بأوضاع التقريب الأخرى.

تتم معالجة التقريب من خلال التنسيق . فيما يلي مثال على خاصية التقريب التي يمكن تعيينها لـ DecimalFormatter. سأضيف مثالًا في الإرشادات للمساعدة في توضيح ذلك بشكل أكبر. شكرا لك مرة أخرى. 😊

الموقع

يرجى تأكيد أن NumberBox سيقبل أي تطبيق لـ INumberFormatter / INumberFormatter2 - وسيواصل القيام بذلك في المستقبل (هذه هي الطريقة التي يتم تنفيذها في الكود ، أريد فقط التأكد من أن المواصفات تستدعيها أيضًا). يجب أن يسمح ذلك بالتحكم الكامل في ترجمة النص مقارنة باستخدام CurrencyFormatter / DecimalFormatter الموجود. إنه لأمر رائع أن يكون لدينا حل لهذا!

هذا هو القصد من التنفيذ الحالي. بالنسبة إلى ضمانات التدقيق المستقبلي ، سيستمر NumberBox في توفير حل لاحتياجات الترجمة والتنسيق. في الوقت الحالي وفي المستقبل المنظور ، قمنا بتنفيذ ذلك.

التفاف النص

تحرير: يجب أن أقرأ المواصفات بأكملها في المرة القادمة.

~ لماذا أنشأت خاصية "IsWrapEnabled" الجديدة؟ هذا يتعارض مع اصطلاح TextBox / XAML لاستخدام TextBlock.TextWrapping و TextWrapping Enum. هل هذا لأنك تشعر أن مصطلح "نص" لا ينطبق جيدًا على NumberBox؟

~ أيضًا ، أفهم أنه ربما يتم تنفيذ كل من Wrap و WrapWithOverflow بنفس الطريقة ولكن بعد ذلك فقط اسمح لقيمتي التعداد بأن تكون مكافئة ووصف الوظيفة في الوثائق. إنشاء خاصية جديدة هنا يعني فقط أننا بحاجة إلى محولات قيمة جديدة ، وما إلى ذلك ... لا يوجد سبب لكسر العرف الحالي على ما أعتقد.

التعامل بشكل صحيح مع مسرّعات لوحة المفاتيح

يرجى التأكد من أن عنصر التحكم هذا يدعم استخدام مسرع لوحة المفاتيح بشكل أفضل من TextBox. ربما لا يمكن القيام بذلك حتى / إذا تم إصلاح TextBox ، ولكن # 1435 يمثل مشكلة بالنسبة لي والتي تسبب الكثير من الأعمال القبيحة. سيتعامل TextBox مع لصق "Ctrl + V" نفسه ثم يتم رفع أي برنامج KeyboardAccelerator. ومع ذلك ، لا توجد طريقة داخل KeyboardAccelerator لمعرفة أن TextBox قام بعمله الخاص.

يحتوي NumberBox على TextBox ويضيف خصائص وتكوينات في الأعلى. سأضع علامة على الإصلاح على مستوى TextBox.

الكل في الكل ، ردود فعل رائعةrobloo! أقدر الوقت الذي استغرقته للمساعدة في التأكد من أننا شاملون وكاملون مع V1 NumberBox قدر الإمكان! يرجى إعلامي إذا كان لديك أي أسئلة أخرى. 😊

تضمين التغريدة

فكرة سريعة. هل يجب أن يكون هناك وضع Angle Mode الذي من شأنه إلحاق الحرف الرسومي بالقيمة (وأي منطق للالتفاف بزاوية 360 درجة)

°

أم أنه سيتم التعامل مع هذا الملحق بشكل أفضل في المستقبل من خلال اقتراح اللاحقة الخاصة بي لمربع النص # 784

حتى الآن ، لا يدعم NumberBox عرض أي أحرف غير رقمية (حيث تتم إزالة الأحرف الخاصة حتى عند تقييم التعبيرات).

أعتقد أن اقتراحك للرقم 784 هو الأكثر شمولاً لمنصتنا. إذا لم يتم اتخاذ إجراء بشأن هذا الاقتراح ، فإنه يبدو لي كميزة V2 مناسبة NumberBox كإجراء احتياطي.

نحن نخطط بالفعل لإصدار V2 جنبًا إلى جنب أو بعد فترة وجيزة من WinUI 3.0 حيث يتم حظر اثنين من أوضاع التحقق من صحة الإدخال المطلوبة بشدة لـ NumberBox عند الحاجة إلى WinUI 3.0. لذلك سأفتح مشكلة V2 بعد تشغيل V1 وسأحاول التأكد من ملاحظة ذلك هناك أيضًا.

لكي نكون توثيقًا ذاتيًا من بين جميع الخصائص الأخرى هنا ، فإننا نفكر في شيء ما على غرار "SpinButtonStep" إذا كان هذا المنطق مبررًا كافيًا للانحراف

أرى أن StepFrequency هو ما يستخدمه Slider ، لذلك أعتقد أننا كنا نحاول أن نكون متسقين مع هذا المصطلح. لا تنس أنه ليس فقط لأزرار الدوران ولكن أيضًا لقيم السحب ومزود UIAutomation.

robloo و mdtauk ، كان يجب أن أقرأ المزيد في الموضوع قبل الرد حول °. لا أعتقد أنه مدعوم حاليًا لعرض هذا الرمز داخل Text حيث يحتفظ NumberBox بـ Text و Value متزامنة بإحكام ، وذلك بغرض السماح لك كمطورين بالإمساك بهم أي نوع تحتاجه دون تكاليف التحويل. لم أجد طريقة لتحقيق ذلك من خلال خصائص التنسيق المتاحة ، ولكن إذا كنت تعرف طريقة ، فيرجى إبلاغي بذلك!

نحن الآن في مواجهة إصدار V1 ، ولكن بالنسبة لـ V2 ، سنلقي نظرة مرة أخرى على البادئة / suffic / special الأحرف. في الوقت الحالي ، أعتقد أن اقتراح mdtauk للرقم 784 هو الحل الأكثر شمولاً الذي تم طرحه للمنصة حتى الآن. يرجى إعطاء هذا الاقتراح إبهامًا وتعليقًا إذا كانت هذه ميزة تحتاجها.

adrientetar ، انتقل التمرير إلى التغيير لـ V1 ولكن تم تأخير السحب للتغيير إلى V2. نظرًا لأننا ما زلنا نتطلع إلى إكمال هذه الميزات ، فإننا لم نقم بعد بمناقشة طلبك بأن يتحول Shift + Up / Down إلى وحدات من 10 و Ctrl + Shift + Up / Down في وحدات من 100.

هل يمكن أن تعطيني مزيدًا من السياق حول السيناريوهات التي قد تستخدم هذه الميزة فيها؟ كيف يعرف مستخدموك أن هذا متاح؟ هل يمكنك مساعدتي في فهم سبب وجوب أن يكون هذا افتراضيًا (أو على الأقل متاحًا) في جميع NumberBoxes مقارنةً بالتطبيق محليًا في الحل الخاص بك؟

تضمين التغريدة

شكرا لكم على تعليقاتكم.

لكي نكون توثيقًا ذاتيًا من بين جميع الخصائص الأخرى هنا ، فإننا نفكر في شيء ما على غرار "SpinButtonStep" إذا كان هذا المنطق مبررًا كافيًا للانحراف

أحب هذه المصطلحات كثيرًا ، فاتني أن Slider لديه خاصية StepFrequency بالفعل. نظرًا لأن هذا هو الحال ، فليس من المنطقي الانحراف عن الاتفاقية كما ذكر jevansaks .

تتم معالجة التقريب من خلال التنسيق. فيما يلي مثال على خاصية التقريب التي يمكن تعيينها لـ DecimalFormatter.

لنفترض أن المستخدم أدخل "1/3" في NumberBox. هل التسلسل التالي صحيح إذن:

• عند فقد التركيز / أدخل التعبير سيتم تقييمه وسيتم احتساب القيمة المزدوجة 0.33333333 ... 34
• 0.33333333 ... 34 سيتم تمريرها إلى DecimalFormatter
• 0.33333333 ... 34 ، بناءً على الإعدادات الخاصة بك ، يمكن تقريبه إلى "0.30" (فقط لتكون صعبة)
• سيتم بعد ذلك وضع هذه القيمة "0.30" في TextBox لعرضها على المستخدم
• مضاعفة Value الآن هي {0.33333333 ... 34} وقيمة Text هي الآن "0.30"
• لن تؤدي قراءة المضاعف Value إلى إرجاع الرقم المقرّب المعروض في Text
  (أو هل القيمة المنسقة العشرية يتم تحليلها بطريقة ما مرة أخرى بعد التحويل إلى سلسلة؟ ثم إعادة تقييم الأمر برمته؟)

أنا قلق أيضًا من أن خصائص القيمة والنص مرتبطة بإحكام داخليًا. لا تحدد الوثائق هذا الاقتران وإذا لم تكن التبعيات ثنائية الاتجاه شديدة التنظيم فلن تكون ممتعة أبدًا.

لست متأكدًا حتى الآن من كيفية تنفيذ ذلك داخليًا تمامًا ، ولكن يبدو أن الطريقة الصحيحة للقيام بذلك هي التعامل مع القيمة المزدوجة باعتبارها الخاصية الحقيقية الوحيدة. النص هو مجرد نسخة منسقة من القيمة. بعد ذلك ، سيكون المطور قادرًا على تنسيق القيمة كما يريدون لعرضها في TextBox وخاصية Text (سنحصل على رمز الدرجة أو رموز القدم / البوصات المطلوبة مسبقًا). لن يكون من الصعب القيام بذلك على الإطلاق إذا كان كل شيء مدفوعًا داخليًا بالفعل بخاصية القيمة. لا يتم الاحتفاظ بالإدخال النصي من المستخدم على أي حال وسيتم استخدامه فقط لإعادة حساب القيمة التي يتم تنسيقها بعد ذلك مرة أخرى للعرض.

يجب أن يكون التسلسل:

• إدخال المستخدم النصي -> المحلل اللغوي -> قيمة مزدوجة -> تنسيق -> نص

سيكون تغيير قيمة النص من الرمز كما لو أن المستخدم أدخل بعض النص. سيؤدي تغيير القيمة مباشرةً إلى الانتقال من خلال خطوة التنسيق والنص.

للحفاظ على دقة التقريب بين القيمة وتسلسل النص سيكون مثل:

• الإدخال النصي للمستخدم -> المحلل اللغوي -> القيمة -> التقريب -> القيمة -> التنسيق -> النص

تحرير: لتنفيذ التقريب في محلل التعبير / الإدخال ومحرك التقييم (مهما كان يطلق عليه) ، ربما تحتاج إلى إضافة خاصية جديدة لتحديد الخوارزمية مثل RoundingAlgorithm . تم تعريف هذا التعداد بالفعل في Windows.Globalization.NumberFormatting كما أشرت. يجب استخدام INumberFormatter2 للتنسيق ولا شيء آخر - مرة أخرى حافظ على فصل المراحل بين الحساب والنص المعروض أخيرًا.

adrientetar ، انتقل التمرير إلى التغيير لـ V1 ولكن تم تأخير السحب للتغيير إلى V2. نظرًا لأننا ما زلنا نتطلع إلى إكمال هذه الميزات ، فإننا لم نقم بعد بمناقشة طلبك بأن يتحول Shift + Up / Down إلى وحدات من 10 و Ctrl + Shift + Up / Down في وحدات من 100.

هل يمكن أن تعطيني مزيدًا من السياق حول السيناريوهات التي قد تستخدم هذه الميزة فيها؟ كيف يعرف مستخدموك أن هذا متاح؟ هل يمكنك مساعدتي في فهم سبب وجوب أن يكون هذا افتراضيًا (أو على الأقل متاحًا) في جميع NumberBoxes مقارنةً بالتطبيق محليًا في الحل الخاص بك؟

يجب أن يكون أحدهما زيادة أكبر والآخر أصغر - على غرار دفع مناطق / كائنات محددة في تطبيقات Adobe

هل يمكن أن تعطيني مزيدًا من السياق حول السيناريوهات التي قد تستخدم هذه الميزة فيها؟

إنه لأمر رائع عندما تريد تغيير قيمة ذات تأثيرات بصرية (على سبيل المثال دوران كائن ما) ولكنك لست متأكدًا من المدى الذي تريد الذهاب إليه. لذلك فهو جيد للتصميم المرئي.

كيف يعرف مستخدموك أن هذا متاح؟

إنها مجرد ميزة تمتلكها الأدوات الحديثة ، مثل Adobe XD و Framer ...

هل يمكنك مساعدتي في فهم سبب وجوب أن يكون هذا افتراضيًا (أو على الأقل متاحًا) في جميع NumberBoxes مقارنةً بالتطبيق محليًا في الحل الخاص بك؟

أعتقد أنه من الجيد أن يكون لديك هذا عندما تكون على جهاز يعمل باللمس ، فهذه طريقة مريحة ، انقر فوق السحب ، لتعديل قيمة معينة (مثل أداة اختيار وقت الهاتف حيث يمكنك النقر فوق السحب لتمرير القيم).

يجب أن يكون أحدهما زيادة أكبر والآخر أصغر - على غرار دفع مناطق / كائنات محددة في تطبيقات Adobe

RangeBase له خصائص SmallChange و LargeChange. نحن في BeLight Software في نسختنا من NumericUpDown مشتق من RangeBase وقمنا بتغيير القيمة عن طريق SmallChange باستخدام اختصارات ArrowUp و ArrowDown ، ومن خلال LargeChange باستخدام اختصارات PageUp و PageDown

ولسنا وحدنا هنا ،
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

مجرد ملاحظة واحدة بخصوص لوحة المفاتيح الرقمية للوحة المفاتيح التي خطرت ببالي أثناء مكالمة المجتمع ...

في معظم التطبيقات ، يتم عرض "." زر لوحة المفاتيح لا يزال معينًا إلى "." ، والذي يختلف عن الفاصل العشري عند استخدام لغة غير إنجليزية (على سبيل المثال "،" باللغة الفرنسية). لذلك عندما تضغط على "." مفتاح في المفكرة ، يكتب "." اكرهشر.

بعض التطبيقات (Excel هو الأكثر شهرة حول ذلك) تغير سلوك المفتاح هذا لإعادة تفسير أي ضغط على لوحة المفاتيح "." كمدخل فاصل عشري. إنه أكثر توافقًا مع تصميم "الآلة الحاسبة" للوحة المفاتيح.

يقوم تطبيق الحاسبة أيضًا بإعادة كتابة "." اضغط لتفسيرها على أنها حرف فاصل عشري.

نظرًا لأنه سيسمح لصندوق الأرقام بالعمل أكثر كـ "آلة حاسبة" ، فهل يمكن أن يسمح عنصر التحكم باستخدام "." مفتاح في لوحة المفاتيح كفاصل عشري؟ أو على الأقل توفير وسيلة للمطور لإضافة هذه الميزة دون الاضطرار إلى القتال باستخدام عوامل التصفية والأحداث الرئيسية؟

ربما تسمح الخاصية بتمكين (في حالة الاشتراك) أو تعطيل (في حالة إلغاء الاشتراك) الميزة. مثل KeyPadDotAsDecimalSeparator="false" ؟

اقتراح V2 NumberBox: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

مرحبًا مجتمع WinUI الرائع! شكرًا جزيلاً على مساعدتنا في العودة إلى المنزل ، حيث اقترح مجتمعنا التحكم الأول لمعرفة الإصدار. نحن نعلم أن هذا كان مهمة ضخمة وأنكم جميعًا استثمرتم قدرًا كبيرًا من الوقت في صياغة أفضل مجموعة من ميزات V1 التي يمكننا تصميمها معًا.

نعلم أيضًا أنه لم يتم إدخال كل شيء في إصدار V1. تعتمد بعض تكوينات التحقق من صحة الإدخال المرغوبة بشدة على عمل ميزة WinUI 3.0 ، وظهرت بعض احتياجات الميزات المرغوبة في وقت متأخر من التحقق من الصحة / التطبيق ، وبعض الميزات التي عرفناها سيكون من الأفضل استكشافها بعد إصدار V1.

نتطلع إلى إنهاء عمل ميزة NumberBox المقصودة مع إصدار WinUI 3. لقد فتحت مشكلة لجمع التعليقات حول الميزات المطلوبة المفقودة من V1. إذا كان NumberBox يفتقد شيئًا ما تحتاجه ، فيرجى التأكد من ترك تعليق هنا: https://github.com/microsoft/microsoft-ui-xaml/issues/1736