Sebagai titik awal, Telerik memiliki satu https://www.telerik.com/universal-windows-platform-ui/numericbox. Ini juga tersedia di Open Source: https://github.com/telerik/UI-For-UWP/blob/master/Controls/Input/Input.UWP/NumericBox/RadNumericBox.cs.

Apa yang saya suka dari mereka adalah pendekatan mereka untuk pemformatan dengan properti ValueFormat.

Contoh: ValueFormat="{}{0,0:C2}"

Harap pastikan juga ini dilokalkan dengan benar. Implementasi Windows Community Toolkit memiliki beberapa kekurangan:

Ekstensi TextBoxRegex dengan ValidationType="Decimal" tidak mendukung semua budaya UI. Sebaliknya itu diperbaiki ke InvariantCulture. Dalam bahasa Inggris nilai desimal adalah "10.1234" dengan titik. Dalam nilai desimal Spanyol atau Jerman ditulis "10.1234". Parsing bahasa Inggris akan benar; namun, masukan pengguna Spanyol atau Jerman hanya akan menjadi "101234" dengan bagian pecahan yang hilang.

Lihat: https://github.com/windows-toolkit/WindowsCommunityToolkit/issues/2700

Panah Atas dan Bawah harus menambah atau mengurangi nilai dengan nilai yang dapat disetel oleh dev, tetapi defaultnya harus berupa int 1

• nilai min/max sampul baik misalnya jika memilih sudut
• kemampuan untuk menambahkan sufiks
• klik kotak teks dan seret ke atas/bawah untuk mengubah nilainya, Adobe XD memiliki ini di input angka.

Implementasi saya di WinRT XAML Toolkit juga mendukung drag up/down untuk mengubah nilai dan membuatnya jauh lebih bermanfaat saat digunakan dengan mouse daripada mengklik tombol dalam skenario tertentu.
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

Halo, @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , dan @xyzzer! Saya telah ditugaskan untuk proposal ini.

Pertama, terima kasih @sonnemaf , untuk mengirimkan ini. Saya menunjukkannya di Microsoft Build 2019 minggu lalu dan mendapat sorakan dari penonton! Tanggapan komunitas di sini di komentar juga mencerminkan kegembiraan yang kita miliki untuk melihat NumberBox terjadi.

Saya telah membaca komentar semua orang dan memperbarui bagian ruang lingkup untuk mencerminkan masukan yang diterima. Saya akan sangat menghargai jika semua orang dapat mengambil kesempatan untuk memeriksa pembaruan kecil ini dan memberi tahu saya jika saya telah _not_ secara akurat menangkap permintaan Anda , mencatat bahwa beberapa detail (seperti pemformatan pelokalan) akan ditangani pada tingkat spesifikasi.

Hai @SavoySchuler ,

Minggu ini, saya sedang mengerjakan fitur aksesibilitas di aplikasi saya. Ini akan menjadi nilai tambah jika aksesibilitas akan ditangani dengan benar dengan kontrol baru misalnya, kenaikan dapat dikatakan dengan lantang alih-alih "plus", "minus". Sisanya tampaknya baik-baik saja bagi saya.

Memastikan narator mampu membacakan nilai-nilai dengan benar sehingga jelas apa yang terjadi adalah penting.

Tidak yakin apakah pengontrol Xbox akan memerlukan penyadapan fokus untuk memastikan stik analog dan D-Pad akan berfungsi dengan benar

Koreksi kecil - seret untuk menambah/mengurangi harus bekerja pada bidang teks itu sendiri hingga diaktifkan. IIRC dalam implementasi saya, saya harus meletakkan beberapa overlay transparan di atas bidang teks untuk mengaktifkannya dan juga menyembunyikan kursor mouse saat menyeret sehingga batas kontrol atau layar tidak akan membatasi jarak seret dan ketika Anda selesai menyeret dan saya menunjukkan kursor lagi - itu muncul di tempat pertama kali menghilang.

@SavoySchuler Anda mendapat tugas yang bagus. Saya bisa hidup dengan ruang lingkup Anda. Kalkulator bagus untuk dimiliki (WinUI 3.0 atau 3.1). Saya telah mengembangkan di banyak lingkungan desktop (VB6, WinForms, WPF dan UWP) dan selalu melewatkan NumberBox. Akhirnya kita akan mendapatkannya.

Mungkin Anda juga dapat menambahkan roda gulir mouse untuk Atas/Bawah. Blend untuk Visual Studio mendukung ini.

Saya juga suka Drag-to-change, sesuatu yang sering saya gunakan di Expression Blend.

Saya tidak yakin validasi input apa yang akan dilakukan dan tidak dilakukan. Apakah hanya min/max atau juga membatasi keyboard (huruf az, dll)? Apakah ini akan menangani Menempelkan nomor yang tidak valid?

Saya ingin membaca spesifikasi lengkapnya.

@ArchieCoder , saya mendengar Anda dengan keras dan jelas. Aksesibilitas adalah prioritas dan penanganan terbaik di muka. Saya telah memulai bagian Aksesibilitas dan Masukan pada proposal ini di mana saya telah menambahkan catatan Anda.

@mdtauk , pertanyaan bagus seperti biasa. Saya telah menambahkan ini ke bagian Aksesibilitas dan Input sebagai catatan untuk melihatnya.

@xyzzer , Anda benar. Saat mengatur ulang, daftar cakupan, saya mengelompokkan tombol Atas/Bawah dan seret untuk mengubah sebagai fungsionalitas terkait. Setelah membaca ulang, sepertinya saya menyarankan drag-to-change menjadi fitur pada tombol. Saya telah memindahkan drag-to-change ke bagiannya sendiri untuk memberikan kejelasan.

@sonnemaf , luar biasa. Saya akan memposting tautan ke spesifikasi segera setelah dibuka, yang kemungkinan akan hari ini atau minggu depan. Silakan merasa terdorong untuk bergabung dengan saya dalam menulis itu! Sampai saat itu, saya telah menambahkan scroll-to-change ke ruang lingkup di sini.

Semua , Dengan catatan tentang dukungan kalkulator - Saya percaya pada nilainya. Saya bekerja dengan tim saya untuk mencari tahu apakah itu adalah sesuatu yang harus kami modulasi jika fungsionalitas dapat dimanfaatkan lebih lanjut di platform. Selain itu, ada pertanyaan seberapa jauh kita pergi dengan dukungan kalkulator? Apakah urutan operasi sederhana pada +-/* dapat dilakukan? Atau sesuatu yang lebih komprehensif seperti menghubungkan ke beberapa jenis layanan alfa wolfram? Menjelajahi rute modular mungkin memungkinkan kita untuk memulai dengan kasus yang lebih mendasar tanpa menghalangi peluang untuk bentuk dukungan kalkulator yang lebih komprehensif. Saya akan tertarik untuk mengetahui kebutuhan semua orang di sini.

Untuk validasi input, saya memiliki pertanyaan yang sama. Apakah min, max, tidak ada huruf, dan tidak ada tempel yang tidak valid menutupinya?

Saya menemukan fitur kalkulator lucu, tetapi bagaimana fitur ini ditemukan oleh pengguna? Apakah akan ada sedikit petunjuk tentang widget ini?

@ArchieCoder , menurut Anda teks placeholder khusus yang pudar di NumberBox dapat dengan tepat meminta pengguna? Jika demikian, saya membayangkan string seperti "a + b - c" atau "masukkan persamaan" bisa menjadi cara ringkas untuk menyampaikan informasi itu. Excel juga telah membuat standar dengan "=" muncul di awal persamaan. Mungkin begitu pengguna mengklik NumberBox, "=" yang tidak berubah muncul di depan yang kemudian diketik pengguna di belakang?

Kami memiliki ToolTip atau TeachingTip yang lebih berat untuk panduan di tingkat aplikasi yang dapat kami minta kepada pengembang untuk diandalkan, tetapi preferensi kuat saya adalah menyelesaikan ini di dalam NumberBox itu sendiri.

Saya tertarik untuk mendengar pendapat Anda di sini!

Placeholder memang merupakan cara yang baik selama konteks lain tidak diperlukan karena keterbatasan ruang. Saya akan berpikir lebar NumberBox akan lebih kecil dari kotak teks misalnya.

Kecuali jika kontrol mendukung angka yang dapat dibatalkan - itu akan selalu menunjukkan nilai,
jadi tidak akan ada ruang untuk string placeholder di dalamnya.

Pada Jumat, 17 Mei 2019 pukul 10:14 ArchieCoder [email protected]
menulis:

Placeholder memang merupakan cara yang baik selama konteks lain tidak
diperlukan karena keterbatasan tempat. Saya akan berpikir lebar NumberBox akan
lebih kecil dari kotak teks misalnya.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTNO99
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder , melihat sebagai contoh @sonnemaf (terima kasih sekali lagi untuk ini), NumberBox apa pun yang tidak cukup lebar untuk menampilkan teks placeholder untuk "a + b - c" juga tidak akan cukup lebar untuk membuat pengalaman pengguna yang direkomendasikan untuk memasukkan persamaan ke dalam. Dalam hal itu, saya akan membayangkan opsi solusi ini masih layak untuk tujuan ini. Namun, saya pikir Anda memasuki area yang belum kami tangani - skenario di mana kami ingin NumberBox yang ringkas/hanya nomor sederhana yang dimasukkan. Saya membayangkan dukungan Kalkulator akan membutuhkan API untuk menonaktifkannya, dalam hal ini kita tidak perlu khawatir dengan teks placeholder yang panjang atau melanggar batasan ruang minimum yang dibutuhkan oleh bentuk persamaan NumberBox - meskipun beberapa opsi teks placeholder untuk mode ringkas mungkin masih bagus , meskipun itu hanya untuk sesuatu seperti "#" atau "misalnya 2".

@xyzzer , terima kasih telah mengemukakan ini. Mari kita pastikan ini bahkan pengalaman pengguna yang tepat terlebih dahulu dan kita dapat mengetahui implementasinya dari sana! Pencarian kami untuk pengalaman pengguna _right_ belum perlu dibatasi karena keterbatasan teknis yang mungkin dapat kami kurangi. :santai:

Saya memiliki pertanyaan prioritas yang lebih tinggi untuk semua orang:

Apakah Anda lebih suka memiliki kontrol NumberBox yang menggabungkan fitur-fitur ini secara independen dari TextBox standar atau Anda lebih suka fitur ini dimasukkan ke dalam TextBox sebagai kemampuan asli yang dapat diaktifkan melalui API atau InputScope?

( @sonnemaf , @ArchieCoder , @robloo , @mdtauk , @adrientetar , dan @xyzzer)

Ini adalah perubahan yang signifikan untuk menempatkan semua ini ke dalam kontrol TextBox.

Validasi untuk karakter yang dimasukkan.

Menggunakan tata letak keyboard yang benar dengan InputScope

Perilaku tikus yang berbeda.

Kemampuan untuk menampilkan tombol pemintal seperti pada versi FabricWeb.

Jika semua hal ini dapat ditambahkan, dengan enum perilaku untuk menentukan jenis TextBox, tanpa berdampak pada orang lain yang saat ini menggunakan TextBox di aplikasi mereka, maka bagus.

Dan Anda bahkan dapat mempertimbangkan untuk menggabungkan perilaku TextBox lain seperti ikon yang dapat mewakili penelusuran atau kalender yang berfungsi seperti tombol. Masker untuk hal-hal seperti alamat IP atau URL yang menampilkan "http://" dalam gaya teks placeholder saat Anda memasukkan teks di sebelahnya.

FabricWeb memiliki variasi yang luas dengan TextFields mereka.

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

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

Saya pasti akan menggunakan kontrol NumberBox sendiri alih-alih memanggang semua fitur ini ke dalam kontrol TextBox (mirip dengan bagaimana ada juga kontrol PasswordBox dan bukan TextBox dengan "kata sandi" mode input).

Kontrol NumberBox akan lebih dari sekadar bidang input sederhana untuk alamat IP, misalnya. Itu akan datang dengan fitur aksesibilty/scroll & drag yang unik, dukungan kalkulator, ... semua yang akan membedakannya cukup banyak dari bagaimana saya biasanya menggunakan TextBox sejauh ini (kasus sesederhana menentukan nama representasi untuk grup dari data). Dan karena lebih banyak fitur/persyaratan khusus akan diusulkan untuk kontrol NumberBox, kami dapat menjaga pemisahan yang baik dan bersih antara NumberBox dan TextBox.

Spearasi itu juga akan muncul dalam dokumentasi dan tata letak aplikasi xaml (NumberBox lebih mudah dideteksi daripada, katakanlah, TextBox dengan sekumpulan properti dengan salah satunya menentukan mode input). Alih-alih membaca dokumentasi TextBox tentang kemampuan input numeriknya, bagian itu akan lebih bagus dan rapi dalam dokumentasi kontrol NumberBox tertentu (seperti halnya dengan PasswordBox hari ini).

Sehubungan dengan tampilan kontrol, saya pikir unit/akhiran dapat ditampilkan selain dengan ukuran yang lebih kecil/warna desaturasi sehingga membedakan dari nilainya itu sendiri:

Saat mouse melayang di atas kontrol, panah atas/bawah bisa memudar di tempat unit:

Alternatifnya adalah kontrol angka dari figma.com, saat Anda mengarahkan kursor ke unit, Anda dapat mengklik+seret ke kiri/kanan untuk mengubah nilainya.

Kiri/kanan menarik karena lebih mudah menggerakkan mouse ke kiri/kanan daripada ke atas/bawah (Anda tidak perlu mengangkat pergelangan tangan).

Hal-hal lain:

• Saat mengklik area teks yang tidak fokus, itu harus memilih semua konten. sehingga klik + ketik nilai + masukkan mengubah nilainya
• Shift+Klik panah atau Shift+Atas/Bawah saat fokus bertambah atau berkurang 10 (nilai itu juga harus dapat disesuaikan menurut saya).
• Saya tidak berpikir panah atas/bawah sangat berguna bagi pengguna. Jika pengguna menginginkan nilai yang tepat, mereka cukup mengetiknya, jika tidak yakin nilai yang diinginkan, mereka dapat memvisualisasikan spektrum perubahan nilai dengan mengeklik+menyeret. Jadi panah atas/bawah mungkin setidaknya opsional.

@adrientetar menempatkan indikasi unit di dalam kontrol menciptakan banyak masalah tambahan:

• lokalisasi
• aksesibilitas
• memilih
• menempelkan
• konversi

Ini semua akan dihindari dengan meletakkan ini di header, deskripsi, atau TextBlock terpisah.

Saya akan menggunakan kontrol NumberBox terpisah dengan properti Nilai dan mungkin bukan Properti Teks. Nilainya harus Double sehingga kita bisa databind (x:Bind) itu. Saya tidak yakin apakah kita juga harus mendukung tipe data Desimal, dan bagaimana caranya.

Dukungan untuk nomor yang dapat dibatalkan menurut saya HARUS (terima kasih @xyzzer). Properti Value harus Nullabletipe data. Saya tidak yakin apakah ini akan menyebabkan masalah pengikatan saat mengikatnya ke nilai yang tidak dapat dibatalkan.

Sedangkan komposisi memiliki manfaat dan perilaku yang melekat pada bilangan
mode dapat diimplementasikan dan dilampirkan ke TextBox - saya pikir itu akan membuat
itu tidak perlu rumit dan terbatas.
Beberapa masalah terbesar yang mungkin Anda hadapi dengan implementasi terkait dengan
aksesibilitas. Saya percaya untuk mendukung beberapa pola aksesibilitas -
Anda harus memanggang implementasi antarmuka tertentu ke dalam TextBox
itu akan membingungkan jika TextBox tidak dalam mode kotak angka.

Pada Senin, 20 Mei 2019 pukul 02.33 Fons Sonnemans [email protected]
menulis:

Dukungan untuk nomor yang dapat dibatalkan menurut saya HARUS (terima kasih @xyzzer
https://github.com/xyzzer ). Properti Value harus Nullable
tipe data. Saya tidak yakin apakah ini akan menyebabkan masalah pengikatan saat mengikatnya
nilai yang tidak dapat dibatalkan.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/microsoft/Microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBWZ40VORYment
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

Saya punya satu pertanyaan lagi untuk semua orang. Apakah Anda perlu/lebih suka validasi input atau penyembunyian?

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

Validasi sangat penting, karena Anda tidak dapat menambahkan nomor ke string. Dan operator matematika perlu dinilai dan diproses.

Apakah perlu pesan kesalahan ditampilkan jika tidak dapat menghitung, yang saya tidak terlalu yakin.

Masking akan berguna, tetapi mungkin harus dibangun ke dalam Textbox itu sendiri, sehingga URL dan entri email dapat ditangani. NumberBox adalah Nomor Telepon, IP, dll

Saya tidak berpikir NumberBox harus digunakan untuk nomor telepon atau IP. Ini tampak lebih seperti ekstensi masking/filtering sederhana untuk TextBox. NumberBox adalah sesuatu yang ingin Anda gunakan untuk memasukkan satu nilai.
Mungkin ada potensi untuk memiliki kontrol kotak mata uang, tetapi saya juga merasa itu harus menjadi kontrol terpisah yang berbeda dari TB atau NB.

@xyzzer Membuat NumberBox lebih fleksibel untuk semua jenis input numerik sepertinya ide yang bagus untuk saya. Itu bisa diturunkan dari kontrol TextBox, dan kontrol itu bisa memiliki properti Mask, serta properti perilaku lainnya.

Beberapa properti di NumberBox dapat berupa:

• Tampilkan/Sembunyikan Tombol Spinner
• Izinkan kenaikan dan penurunan nilai
• Izinkan perhitungan nilai
• Izinkan Masukan Bertopeng
• Masker Lokal seperti nomor telepon, atau alamat IP

Properti yang dapat ditambahkan ke TextBox dapat berupa:

• Properti Mask - String XAML untuk menentukan format khusus ([email protected]) serta mask yang dilokalkan seperti kode pos/zip
• Tampilan Teks Awalan/Akhir (_http://_ sebagai awalan misalnya)
• Tombol Tindakan tampilkan/sembunyikan - dengan ikon dan klik properti acara
• Ikon (Kotak Pencarian UI Fabric menampilkan ikonnya di sebelah kiri dan mati ketika kotak mendapat fokus)

Gambar-gambar ini adalah dari Fabric UI TextField - dan mendukung semua status yang berbeda ini - kita harus bertujuan untuk membawa kontrol Fluent WinUI 3.0 ke paritas jika memungkinkan

Tombol Fabric UI Spinner terlalu kecil untuk disentuh, jadi saya akan memformatnya secara berbeda sehingga tombol atas dan bawah berdampingan, tidak bertumpuk satu sama lain

Bagi saya Validasi adalah HARUS MEMILIKI dan Masking adalah HARUS DIMILIKI. Saya tidak pernah suka menutupi; itu terlalu kaku.

@rudyhuyn mengusulkan pada repositori Windows Calculator fitur yang bagus. @mdtauk mengomentarinya .

Anda dapat membuka Popup Kalkulator dari NumberBox yang mirip dengan Pemilih Tanggal/Waktu/Kalender.

Mirip dengan apa yang dikatakan @xyzzer di atas. Ada perbedaan mendasar antara angka dan string yang berisi urutan angka.
Cara terbaik yang pernah saya dengar tentang perbedaan yang dijelaskan adalah Anda dapat melakukan operasi perkalian dan pembagian pada suatu bilangan. Anda dapat meminta setengah dari angka dan membaginya dengan dua. Anda tidak dapat meminta setengah kode pos atau "nomor telepon" dan mendapatkan sesuatu yang berarti.

Mencampur NumberBox yang memiliki kemampuan matematika dengan fungsionalitas untuk menangkap nilai lain yang terdiri dari digit dapat menyebabkan masalah lain juga.
"Nomor telepon" dapat dimulai dengan angka nol di depan (atau tanda tambah) dan di sana mereka memiliki arti. Untuk _number_ mereka tidak dan akan dilucuti.
"nomor telepon" sering juga diformat dengan tanda kurung dan tanda hubung. Ketika diproses sebagai operasi matematika, ini dapat dengan mudah ditafsirkan sebagai membutuhkan perkalian dan pengurangan.

Membiarkan penyembunyian dengan cara yang sama seperti TextBox dan sebagai cara memformat input berisiko membingungkan perbedaan antara NumberBox dan TextBox dan kapan masing-masing harus digunakan.

Validasi sederhana ketika validasi datang ke platform , ini tidak mengakibatkan cara memiliki metode validasi yang bertentangan atau sesuatu yang dapat dengan mudah mendorong pengembang untuk menyebarkan validasi mereka ke beberapa lokasi .

Saya akan menjaga validasi agar hanya didasarkan pada properti ini:

• Nilai maksimum
• Nilai Minimum
• IzinkanTempat Desimal

Secara terpisah, perlu ada indikasi

• keluaran tidak valid dari perhitungan
• bagaimana menangani nilai yang dimasukkan/ditempel/dihitung dan apa yang digunakan dalam penjilidan. Ada kebutuhan untuk menampilkan perhitungan atau nilai yang tidak valid untuk menunjukkan bahwa itu tidak valid tetapi ini tidak dapat diteruskan ke properti pendukung mana pun,

Masker akan membutuhkan keterjangkauan visual untuk memperjelas apa yang diperlukan, sedangkan input perhitungan dasar tidak akan digunakan bersama input yang ditutupi.

Kontrol teks Fabric Web tampaknya menangani ini dengan baik - tetapi tentu saja ruang lingkup untuk NumberBox terpisah untuk penyesuaian umum dan penyempurnaan akhir pada kontrol TextBox default.

Tombol pemintal (dan flyout Kalkulator opsional mungkin) adalah satu-satunya hal visual yang tampaknya khusus untuk NumberBox.

Adapun properti, mungkin jika tombol naik dan turun keyboard diaktifkan untuk mengubah nilai - nilai Langkah dapat disertakan sehingga Anda dapat memilih berapa banyak untuk menambah atau mengurangi pada penekanan tombol.

@mdtauk , saya suka nilai Langkah , tetapi tidak hanya pada penekanan tombol. Juga pada tombol gulir dan Atas/Bawah.

@sonnemaf Tentu, Langkahnya bagus untuk sesuatu yang biner seperti centang roda mouse, tekan tombol atau tombol ke bawah. Mungkin jarak yang diseret dari kotak dapat meningkatkan jumlah langkah?

Jadi StepMinimum dan StepMaximum mungkin?

Jadi StepMinimum dan StepMaximum mungkin?

Saya tidak tahu apa nilai-nilai itu mungkin berhubungan atau apa yang diharapkan dari mereka.
Jika tujuan "Langkah" adalah untuk mendefinisikan kenaikan, maka sebut saja "Peningkatan".

Ini akan memungkinkan Max:100 Min:0 Increment:10 hanya mengizinkan nilai 0, 10, 20, 30, 40, 50, 60, 70, 80, 90, & 100 untuk ditentukan.

Memiliki jumlah langkah/kenaikan yang bervariasi berdasarkan jarak yang diseret dapat menyebabkan perubahan nilai yang tidak terduga. Jika tujuan dari kontrol ini adalah untuk membuatnya lebih mudah untuk menentukan nilai numerik maka jika nilai mulai berubah dalam jumlah yang bervariasi maka saya mungkin akan menemukan ini sangat frustasi yang akan mengalahkan tujuan yang mendasari memiliki kontrol khusus untuk membuatnya mudah.

@mrlacey Saya menggunakan Langkah karena ini adalah properti yang dinamai untuk bilah geser dan bilah kemajuan, tetapi kenaikan dapat digunakan jika diinginkan. Nilai memang naik dan turun sehingga selama kenaikan tidak dikacaukan hanya dengan peningkatan nilai.

Ada proposal untuk mengklik dan menyeret ke atas atau ke bawah untuk menambah atau mengurangi nilainya. Jika pengguna mengharapkan nilai berubah lebih cepat, semakin jauh ke atas atau ke bawah yang Anda seret, maka memiliki nilai Stap Min dan Max akan memungkinkan pengembang untuk mengontrol ini saat delta berubah. Jadi jarak seret kecil bisa selangkah 0,1 atau 1 - tapi menyeret lebih jauh bisa berubah dengan langkah 5 atau 10 misalnya.

Saya tidak mengatakan jarak seret harus mengubah kecepatan perubahan nilai - hanya itu ide yang mungkin membantu, jika terasa alami dan memberi pengguna rasa percaya diri dan kontrol.

Umpan balik yang luar biasa, semuanya! Saya telah membuka spesifikasi & PR untuk mulai menjelaskan detailnya.

@KevinTXY akan bergabung dengan saya sebagai pengembang untuk kontrol ini. Kami akan terus melanjutkan percakapan persyaratan di sini dan memulai API/contoh percakapan khusus di PR.

Silakan merasa terdorong untuk bergabung dengan saya dalam menulis spesifikasi.

Spesifikasi TeachingTip adalah contoh fitur lengkap tentang seperti apa spesifikasi yang sudah jadi. Garis besar utama akan menjadi:

• Keterangan
• Contoh untuk setiap API/fitur
• Pedoman
• API (IDL)

Ide bagus, saya suka kemana semua ini pergi. Menambahkan dua sen saya:

• Tanpa pertanyaan saya pikir ini harus menjadi NumberBox yang terpisah alih-alih terintegrasi dengan TextBox. Selain itu, ada banyak fitur bagus yang dibahas di sini, tetapi kita juga harus menjaga agar NumberBox tetap ringan. Oleh karena itu, saya mengusulkan untuk menurunkan CalculatorBox atau sesuatu yang serupa dari NumberBox dan yang dapat memiliki input "2+3" tingkat lanjut atau tombol untuk membuka kalkulator.
• Lokalisasi perlu dipikirkan dengan baik dalam spesifikasi sebelumnya. Selain itu ada kasus di mana Anda ingin mengganti UI lokal. Oleh karena itu menyetel properti NumberformatInfo atau CultureInfo mungkin sangat berguna. Misalnya, dalam beberapa aplikasi, nilai asing dan lokal dilacak. Masing-masing berpotensi menjadi format yang berbeda.
• Kontrol perlu mendukung pemindahan tempat desimal. Ini lebih rumit daripada sekadar memvalidasi format pada setiap teks yang diubah. Setiap input karakter perlu dilacak dan tempat desimal sebelumnya diganti sesuai kebutuhan.
• Setiap panah kenaikan/penurunan harus dapat dikonfigurasi untuk dimatikan agar hanya memiliki kotak input biasa -- sekali lagi kita memerlukan kontrol ringan di sini untuk kasus yang diperlukan sebagai bagian dari kontrol lain.
• Hal lain yang belum dibahas adalah kita perlu mendukung banyak jenis secara ideal -- Desimal, Integer dan berpotensi Long, Double, dll... Ini secara fundamental dapat mengubah banyak hal dan saya sendiri belum sepenuhnya memikirkannya .
• Nilainya pasti harus nullable. Nilai yang tidak disetel berbeda dari nol.
• Ide lain yang tidak kritis adalah membiarkan presisi desimal ditentukan untuk tipe desimal, ganda atau float.

Saya yakin lebih banyak ide akan menyusul. Saya berharap untuk membaca spesifikasi!

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

Saya memiliki spesifikasi / PR yang diisi dengan API dan contoh untuk masing-masing. Saya pikir saya telah membahas pemformatan dengan spesifikasi Anda dengan enum untuk tipe dasar yang telah ditentukan sebelumnya (masih dalam proses) serta properti pemformatan khusus yang akan menimpa tipe yang telah ditentukan sebelumnya jika disetel.

Silakan periksa dan beri tahu saya jika itu tidak menyelesaikan masalah Anda atau jika itu dapat ditambahkan atau ditingkatkan. Saya akan menerima permintaan tarik yang berkontribusi pada spesifikasi yang diminta di sini.

• Validasi dicatat sebagai suatu keharusan. Saya telah meresepkan kontrol ini untuk diturunkan dari TextBox untuk mendapatkan masking dan properti pendukung lainnya secara gratis.

• Untuk kekhawatiran @mrlacey , saya menambahkan API untuk mengaktifkan/menonaktifkan pengupasan nol di depan yang dapat digunakan bersama dengan string format khusus untuk mengaktifkan skenario untuk input string numerik khusus (mencatat bahwa nomor telepon internasional dan alamat IP sudah pada daftar kemungkinan tipe format dasar).

• Ini dipasangkan dengan kemampuan untuk mengaktifkan/menonaktifkan dukungan kalkulator, bagi saya, mendaratkan persimpangan untuk kontrol yang bisa ringan untuk nilai numerik/string tetapi juga menawarkan dukungan perhitungan dan penyesuaian yang memadai. Saya percaya ringkasan contoh menyoroti hal ini tetapi saya tertarik untuk mendengar dari siapa saja yang berpikir ini akan membuat kontrol calon lebih rumit untuk digunakan.

• @sonnemaf Saya menghargai kebaruan dan intuitif ikon > contoh kalkulator popup. Bagi saya, ini berasal dari contoh konsep CalendarDatePicker dan bisa menjadi pertimbangan yang sangat baik untuk fitur V2 kecuali ada dorongan kuat dari semua orang di sini yang harus dipertimbangkan untuk V1?

Kalkulator popup mungkin masuk akal jika ada koordinasi dengan upaya sumber terbuka Kalkulator. Baik untuk konsistensi tampilan Kalkulator Flyout, tetapi juga pada mesin di belakangnya.

Tidak yakin apakah ini adalah tempat untuk memposting gambar ini, tetapi berikut adalah desain untuk berbagai negara bagian yang sesuai dengan spesifikasi.

Gambar dalam skala 200%

@mdtauk apa tujuan maket Anda?

Status apa yang coba ditampilkan oleh setiap gambar? Tanpa Anda mengklarifikasi hal ini, kami mungkin membuat asumsi yang berbeda dengan Anda.

Apakah ini dimaksudkan sebagai referensi sempurna piksel?

Bisakah Anda menyebutkan di mana sesuatu dalam gambar Anda berbeda dari default platform atau kontrol dasar sehingga jelas apa (jika ada) yang Anda tambahkan atau ubah.

@mrlacey saya bisa melakukan perincian yang lebih lengkap jika itu akan membantu? Saya hanya mencoba mengilustrasikan beberapa contoh yang disebutkan dalam spesifikasi.

Tujuannya adalah untuk mencoba menggambarkan bagaimana kontrol ini dapat terlihat dengan berbagai elemen kontrol yang diusulkan seperti awalan, akhiran, topeng, tombol atas dan bawah. Mereka diekstrapolasi dari desain kontrol FabricWeb, tetapi menggunakan elemen XAML seperti FocusReveal dan ukuran kontrol untuk tombol.

Contoh menunjukkan Rest - Focus - Disabled state

Kalkulator popup akan menjadi fitur yang bagus untuk V2.

Saya tidak yakin di mana harus meletakkan komentar saya. Haruskah saya membuat PR sesuai spesifikasi atau dapatkah saya terus menulis pemikiran saya dalam masalah ini?

Bilangan bulat

Apakah nilai Integer untuk NumberBoxFormatType berguna?

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

Bahasa

Apakah Anda akan menggunakan bahasa untuk menentukan Mata Uang, simbol pengelompokan digit desimal?

Dalam contoh berikutnya Bahasa diatur ke nl-NL. Apakah ini berarti Awalan adalah tanda Euro, simbol desimal adalah koma dengan 2 desimal setelahnya dan pengelompokan digit adalah titik? Mata uang negatif memiliki tanda minus di depan dan tidak ada tanda kurung seperti di AS.

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

Apakah ini cukup karena ada banyak opsi format angka & mata uang di Windows.

Nilai properti atau properti

Apakah kita memerlukan properti Value dan tipe (numerik) apa itu. Saya akan menggunakannya untuk databind itu. Haruskah itu menjadi ganda, desimal atau int. Apakah kita memerlukan dukungan Nullable (ganda?, desimal?, int?). Saya tidak ingin menggunakan properti Text dari kontrol TextBox yang diwarisi untuk penyatuan data. Kami membutuhkan dukungan untuk Desimal juga, dobel saja tidak cukup.

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

Bagaimana jika properti Gaji Karyawan adalah Nullable?(desimal?). Apakah kita memerlukan properti ketergantungan ValueNullableDecimal. SelectedDate dari kontrol DatePicker adalah Nullable. Nullable adalah masalah, terutama dengan penyatuan data.

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

Hal yang sama dengan MinValue dan MaxValue. Mereka sekarang Integer dalam Spec tetapi bukankah ini seharusnya Double?.

@sonnemaf karena spesifikasi mengatakan bahwa kontrolnya adalah untuk apa pun di mana angka dapat dimasukkan, saya pikir itu berarti ia memperlakukan "Nilai" sebagai teks dan bergantung pada kode yang dikonsumsi untuk mengonversi seperlunya. Ini tidak ideal tetapi bahkan jika ada properti Value yang long atau float, masih akan ada banyak kesempatan di mana konversi akan diperlukan.
Ini lebih baik daripada kelebihan beban untuk setiap tipe numerik.
Lalu ada hal-hal yang kontrolnya dirancang yang tidak dapat dikonversi ke tipe "numerik", seperti Kode Pos AS, Nomor telepon, atau alamat IP. Untuk nilai-nilai semacam ini, mendapatkan teks sepertinya merupakan opsi (hanya) terbaik.
Saya pikir ini lebih sederhana (setidaknya dalam versi awal untuk memiliki satu cara mengakses nilai yang dimasukkan dan mengandalkan konverter jika diperlukan. Saya dapat melihat tempat untuk kumpulan pembantu (atau subkelas) yang datang ke toolkit pada awalnya dan kemudian beberapa mereka dimasukkan ke dalam kontrol utama berdasarkan umpan balik.

Apakah properti Language diperlukan? Mengapa ini tidak sama dengan UILocale? Mungkin ada alasan bagus, tetapi sepertinya ini harus dapat dikonfigurasi pengguna (pada level OS) dan memberikan kemampuan untuk menentukan format tertentu dapat menyebabkan lebih banyak masalah bagi pengembang ketika format tidak cocok di tempat lain atau apa yang pengguna aplikasi ingin. Dari atas kepala saya: bagaimana jika seseorang menempelkan nilai dalam format yang berbeda?

@mdtauk apa tujuan maket Anda?

Status apa yang coba ditampilkan oleh setiap gambar? Tanpa Anda mengklarifikasi hal ini, kami mungkin membuat asumsi yang berbeda dengan Anda.

Apakah ini dimaksudkan sebagai referensi sempurna piksel?

Bisakah Anda menyebutkan di mana sesuatu dalam gambar Anda berbeda dari default platform atau kontrol dasar sehingga jelas apa (jika ada) yang Anda tambahkan atau ubah.

@mrlacey Apakah ini yang Anda inginkan?

@mdtauk itu sedikit lebih baik karena menjelaskan beberapa dari apa yang Anda coba tunjukkan.

Pertanyaan mendasar masih tetap ada: Apa tujuan Anda menunjukkan ini? Apakah itu hanya sebuah ide? Apakah ini versi pilihan Anda setelah menjelajahi berbagai ide? Jika demikian, mengapa ini yang terbaik/disukai?

Membandingkan kontrol saat ini dengan bagaimana Anda ingin kontrol baru ditampilkan dalam gaya lebar sistem baru pilihan Anda berarti bahwa tidak mungkin untuk memisahkan apa yang spesifik untuk kontrol dengan apa yang ada dalam gaya lebar sistem baru pilihan Anda.

Misalnya, Anda menyebutkan mengubah transparansi di perbatasan. Apakah perubahan ini ditujukan untuk semua kontrol atau hanya yang ini? Dan di negara bagian mana?

Memberikan ukuran eksplisit (untuk tombol) dapat menjadi masalah dalam desain comps karena mereka tidak selalu diterjemahkan secara merata berdasarkan wadahnya yang diubah ukurannya. Haruskah mereka selalu persegi? atau apakah lebarnya tetap berdasarkan ketinggian kontrol default?

Bagaimana Anda mengusulkan sikat latar belakang untuk awalan dan akhiran ditentukan? Saya menganggap sikat sistem yang ada, tetapi yang mana?

Masking tidak tercakup dalam spesifikasi ini. Apakah contoh "Masked" Anda dimaksudkan untuk berhubungan dengan string format?
Bagaimana Anda bertopeng contoh sesuai dengan format?
Saya berasumsi bahwa contoh Anda menunjukkan entri alamat IP versi 4 tetapi sepertinya ada banyak asumsi di sana berdasarkan seberapa rapi semuanya tampak cocok. Haruskah semua nilai yang tidak dapat dimasukkan memiliki latar belakang dan margin? Bagaimana jika mereka tidak selalu ditampilkan? Haruskah konten diregangkan agar sesuai dengan semua ruang yang tersedia, seperti yang terlihat pada contoh Anda? Bagaimana ruang yang dialokasikan untuk nilai yang tidak dapat dimasukkan akan diperlakukan saat menggeser konten yang lebih lebar dari ruang yang tersedia?

@mdtauk itu sedikit lebih baik karena menjelaskan beberapa dari apa yang Anda coba tunjukkan.

Pertanyaan mendasar masih tetap ada: Apa tujuan Anda menunjukkan ini? Apakah itu hanya sebuah ide? Apakah ini versi pilihan Anda setelah menjelajahi berbagai ide? Jika demikian, mengapa ini yang terbaik/disukai?

Membandingkan kontrol saat ini dengan bagaimana Anda ingin kontrol baru ditampilkan dalam gaya lebar sistem baru pilihan Anda berarti bahwa tidak mungkin untuk memisahkan apa yang spesifik untuk kontrol dengan apa yang ada dalam gaya lebar sistem baru pilihan Anda.

Misalnya, Anda menyebutkan mengubah transparansi di perbatasan. Apakah perubahan ini ditujukan untuk semua kontrol atau hanya yang ini? Dan di negara bagian mana?

Spec NumberBox tidak menyertakan contoh visual apa pun, dan gambar dalam Proposal Asli adalah contoh kasar untuk fungsionalitas. Ada PR #524 lain di mana template kontrol diperbarui dengan nilai CornerRadius di 2epx, yang juga merupakan pembulatan yang sama yang digunakan oleh Fabric Web.

Jadi dengan asumsi bahwa kontrol turunan TextBox juga akan diperbarui secara serupa, saya menggunakannya sebagai panduan untuk menunjukkan bagaimana fungsionalitas yang diusulkan dari NumberBox dapat masuk ke dalamnya. Bidang teks Fabric Web sudah memiliki dukungan untuk nilai Prefix dan Suffix, jadi saya hanya mengambil desain itu, dan menggunakan metrik XAML.

Memberikan ukuran eksplisit (untuk tombol) dapat menjadi masalah dalam desain comps karena mereka tidak selalu diterjemahkan secara merata berdasarkan wadahnya yang diubah ukurannya. Haruskah mereka selalu persegi? atau apakah lebarnya tetap berdasarkan ketinggian kontrol default?

TextBox saat ini memiliki beberapa tombol terintegrasi, seperti SearchBox, tombol Password Reveal, dan tombol Clear Text. Target Sentuh untuk XAML menyarankan tombol menjadi 32 x 32 epx - Saya hanya membuatnya tetap persegi dan menggunakan panduan itu.

Bagaimana Anda mengusulkan sikat latar belakang untuk awalan dan akhiran ditentukan? Saya menganggap sikat sistem yang ada, tetapi yang mana?

Dalam contoh saya, saya menggunakan Theme Foreground Color tetapi menggunakan Opacity 15%. FabricWeb menggunakan hampir 10%, dan Tombol XAML menggunakan 20%.
Ada nilai kuas serupa seperti ListLowBrush tetapi mungkin memerlukan kuas TextBoxAppendixBackground baru. Text Foreground akan menggunakan sikat PlaceholderTextForeground yang sama.

Masking tidak tercakup dalam spesifikasi ini. Apakah contoh "Masked" Anda dimaksudkan untuk berhubungan dengan string format?
Bagaimana Anda bertopeng contoh sesuai dengan format?
Saya berasumsi bahwa contoh Anda menunjukkan entri alamat IP versi 4 tetapi sepertinya ada banyak asumsi di sana berdasarkan seberapa rapi semuanya tampak cocok. Haruskah semua nilai yang tidak dapat dimasukkan memiliki latar belakang dan margin? Bagaimana jika mereka tidak selalu ditampilkan? Haruskah konten diregangkan agar sesuai dengan semua ruang yang tersedia, seperti yang terlihat pada contoh Anda? Bagaimana ruang yang dialokasikan untuk nilai yang tidak dapat dimasukkan akan diperlakukan saat menggeser konten yang lebih lebar dari ruang yang tersedia?

Saya tidak akan berpura-pura memiliki semua jawaban untuk ini, dan bagaimana hal itu ditampilkan pada kontrol akan turun ke bagaimana pemformatan topeng diimplementasikan dalam kontrol.

Saya menggunakan alamat IP v4 karena ini adalah contoh yang ditampilkan dalam spesifikasi, dan tujuan awal saya adalah untuk mengilustrasikan apa yang diusulkan (walaupun contoh awalan dan akhiran kurang, jadi saya memilih nilai lain)

Saya melihat bagaimana kontrol lain menangani masking, dan beberapa menggunakan teks sebaris yang memindahkan Caret saat nilai dimasukkan. Orang lain akan memasukkan hal-hal seperti tanda kurung dan tanda hubung saat memasukkan nomor telepon. Beberapa menggunakan tombol tab atau panah untuk berpindah antar segmen. Contoh terdekat dari Microsoft yang terlintas dalam pikiran adalah memasukkan Product Keys selama Windows Install.

Saya pikir menggunakan gaya yang sama dengan elemen yang ditambahkan, akan sesuai dengan estetika, tetapi saya sadar ini menambah panjang kontrol untuk menyesuaikan semuanya, dan inline dapat memanfaatkan ruang dengan lebih baik.

Sekedar catatan karena saya sedang bekerja dengan TextBox sekarang, dengan itu tidak ada satu peristiwa pun untuk menandakan nilai yang diubah oleh pengguna (yaitu penyatuan fokus yang hilang dan tombol kembali ditekan), mirip dengan https://doc.qt.io /qt-5/qlineedit.html#textEdited Akan sangat bagus untuk memilikinya di NumberBox seperti yang dimaksudkan untuk pengeditan semacam ini. Omong-omong, jika itu akan menangani semua jenis nilai seperti alamat IP mungkin "Nomor"Kotak terlalu sempit untuk sebuah nama? Itu bisa ValueBox atau lebih

@adrientetar NumberBox tampaknya baik-baik saja sebagai nama, karena semua input dihitung sebagai angka. Alamat IP memiliki 4 nomor, nomor Telepon, Mata Uang, Pengukuran, dll.

DigitBox, NumeralBox, dll adalah semua varian yang tidak sesuai dengan gaya penamaan Microsoft.

Nilai juga tidak harus bersifat numerik, jadi ValueBox juga bisa sedikit menyesatkan.

@sonnemaf dan @mdtauk , saya berbicara dengan tim saya tentang ide kalkulator yang disematkan dan singkatnya kami MENYUKAINYA - tidak berlebihan. Kami sangat senang dengan bagaimana Anda semua telah meningkatkan kualitas dan kreativitas kontrol yang kami berikan.

Saya membutuhkan bantuan dari Anda untuk mewujudkannya. Cara kami tetap berada di puncak ide-ide luar biasa yang datang melalui repo kami adalah tidak hanya didorong oleh ide tetapi juga didorong oleh skenario. (Saya membagikan ini karena berbicara bahasa ini akan memberikan permintaan fitur Anda kekuatan nyata di seluruh repo kami.)

Bisakah salah satu dari Anda mengaktifkan saya dengan skenario nyata untuk kalkulator tertanam di salah satu aplikasi yang Anda kembangkan? Konteks, tangkapan layar, profil pengguna semuanya membantu. (Email saya juga ada di profil GitHub saya jika Anda lebih suka merahasiakan detailnya.) @xyzzer , @mrlacey , @robloo , @Felix-Dev, @adrientetar , dan @ArchieCoder , silakan bagikan skenario penggunaan Anda jika fitur ini menarik bagi Anda juga.

Di luar langkah ini, satu-satunya hal yang dapat menghambat fitur ini adalah risiko menggembungkan ukuran DLL WinUI dengan mesin aplikasi kalkulator. Saya akan melihat ini secara paralel untuk melihat kelayakannya.

Saya sebelumnya mengangkat masalah memperlakukan kontrol ini lebih dari sekadar tipe numerik.

Ada perbedaan mendasar antara angka dan string yang berisi urutan angka.

Ini sebelum draf pertama spesifikasi diterbitkan, jadi saya berasumsi ini telah dipertimbangkan dan keputusan dibuat untuk membuat kontrol ini menangani "nilai numerik tradisional" dan juga "string yang berisi angka angka."

Saya tidak berpikir siapa pun akan benar-benar mencoba dan berargumen bahwa alamat IPv4 adalah "angka" dengan definisi lain selain yang biasanya tidak direpresentasikan daripada sebagai urutan digit yang diformat. Pada kenyataannya itu hanya nilai 4 byte.

@SavoySchuler

• Memasukkan Pengeluaran mungkin - memasukkan barang-barang itu dari tanda terima di mana beberapa barang bersifat pribadi, dan yang lain bagian dari pekerjaan.
• Aplikasi restoran saat membagi tagihan, atau mungkin perhitungan tip?
• Aplikasi pengeditan hex, untuk menghitung nilai offset untuk memindahkan pilihan?

Memiliki kontrol yang mendukung alamat IP akan menjadi tambahan yang bagus untuk platform, tetapi saya tidak berpikir NumberBox adalah kontrol yang tepat untuk skenario ini.

Seperti disebutkan sebelumnya, kontrol NumberBox akan:

• gunakan keyboard virtual Number saat digunakan pada perangkat tanpa keyboard fisik
• memiliki 2 tombol -/+
• tampilkan pop-up dengan kalkulator atau izinkan pengguna mengetik operasi aritmatika dasar

Tak satu pun dari fitur ini masuk akal dengan alamat IP. Bahkan desain kontrolnya sangat berbeda.

Selain itu, kita harus ingat bahwa jika kita mendukung alamat IPv4, kita juga harus mendukung alamat IPv6, tidak menggunakan angka tetapi heksadesimal.

Saya pikir akan lebih masuk akal untuk tidak menyertakan dukungan alamat IP dalam kontrol ini tetapi alih-alih bekerja pada kontrol MaskedTextBox untuk UWP (mendukung IPv4, IPv6, nomor telepon, kode pos, SSN, dll ...) dengan UI yang kaya (seperti yang didemonstrasikan oleh @mdtauk) untuk mengganti/meningkatkan TextBoxMask dari Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

Memiliki kontrol yang mendukung alamat IP akan menjadi tambahan yang bagus untuk platform, tetapi saya tidak berpikir NumberBox adalah kontrol yang tepat untuk skenario ini.

Seperti disebutkan sebelumnya, kontrol NumberBox akan:

• gunakan keyboard virtual Number saat digunakan pada perangkat tanpa keyboard fisik
• memiliki 2 tombol -/+
• tampilkan pop-up dengan kalkulator atau izinkan pengguna mengetik operasi aritmatika dasar

Tak satu pun dari fitur ini masuk akal dengan alamat IP. Bahkan desain kontrolnya sangat berbeda.

Selain itu, kita harus ingat bahwa jika kita mendukung alamat IPv4, kita juga harus mendukung alamat IPv6, tidak menggunakan angka tetapi heksadesimal.

pikir akan lebih masuk akal untuk tidak menyertakan dukungan alamat IP dalam kontrol ini tetapi sebaliknya bekerja pada kontrol MaskedTextBox untuk UWP (mendukung IPv4, IPv6, nomor telepon, kode pos, SSN, dll ...) dengan UI yang kaya (seperti yang didemonstrasikan oleh @mdtauk) dan mengganti/meningkatkan TextBoxMask dari Community Toolkit (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn Saya sebagian besar setuju dengan apa yang baru saja Anda katakan di sini, dan ilustrasi saya adalah untuk Spec yang diusulkan.

Tetapi seperti yang telah disebutkan oleh orang lain, Kotak Teks Bertopeng tidak perlu dibatasi hanya pada angka, dan juga dapat menyertakan String. Kotak Kunci Produk Microsoft adalah contoh yang baik, di mana ada 5 set karakter 0-9 AZ yang diterima.

Bahkan jika Masking dipisahkan, saya masih berpikir ada kasus penggunaan yang baik untuk memasukkan properti PrefixText dan SuffixText ke kontrol NumberBox. Mata Uang, Pengukuran, semuanya memerlukan semacam konteks.

Spin Buttons murni untuk menambah dan mengurangi nilai, jadi itu juga dalam lingkup kontrol NumberBox.

Prefix dan Suffix bisa menjadi properti dari kontrol TextBox itu sendiri, dan dengan demikian diwarisi oleh kontrol lainnya. (Mungkin perlu ada pengecualian untuk PasswordBox jika membuka kerentanan)

Masker untuk nilai umum dapat berupa enum (bersama dengan CustomFormatMask) untuk kontrol terpisah ini. Beberapa topeng ini mungkin melibatkan konteks Budaya, seperti Kode Pos Inggris menjadi alfanumerik, dan nomor Asuransi Nasional Inggris mengikuti format khusus, dll.

SW1A 2AA

Contoh kode pos UK (untuk Downing Street No. 10)

Tampaknya saya tidak berhasil menyegarkan halaman pagi ini sebelum mengirim balasan saya... Terima kasih kepada semua bintang rock karena telah membawa proposal ini ke tingkat yang sama sekali baru! Saya tahu bahwa kata-kata terlalu sering digunakan di GitHub, tetapi saya sungguh-sungguh!

@mdtauk - tiruan Anda luar biasa. Saya belum merancang desain prototipe untuk kontrol ini. Bolehkah saya memecah tiruan Anda dan menambahkannya ke spesifikasi sebagai prototipe untuk desainer kami untuk memulai palet mereka? Saya akan menghubungi dan meminta desainer hari ini dan melihat apakah saya bisa membuat mereka membalas utas Anda dengan @mrlacey di sini. Saya akan membaca utas Anda dan membalas dengan detail yang lebih halus segera.

@sonnemaf , sekali lagi terima kasih! Saya mendorong Anda untuk menyalin komentar Anda dan memposting ulang di sini di tab percakapan Permintaan Tarik . Di sinilah tim teknik kami akan mulai terlibat pada API dan tingkat implementasi. Demi memberikan jawaban yang komprehensif, di sinilah saya mulai menyusun pedoman dan dokumentasi. Saya akan mengawali commit dengan [DEV] untuk yang pertama dan [PM] untuk yang terakhir. Jika tidak, ini masih merupakan forum yang tepat untuk diskusi persyaratan tingkat tinggi (seperti kalkulator tersemat dan tiruan @mdtauk ).

@mdtauk : Saya setuju dengan Anda, Prefix/Suffix akan menjadi tambahan yang bagus untuk TextBox dan tidak terbatas pada angka, beberapa contoh:

• minta karyawan untuk memasukkan alamat email mereka ketika domain selalu sama (@microsoft.com misalnya).
• masukkan nama formulir yang selalu diawali dengan W-

dll...

Anda harus membuka tiket lain sehingga kami dapat memulai diskusi tentang itu!

@rudyhuyn apakah Anda melihat kemampuan untuk tidak mendukung sesuatu seperti alamat IP tetapi kemampuan untuk mendukung nomor telepon atau kode pos bisa diterapkan?
Pikiran saya adalah jika Anda mulai membatasi beberapa hal tetapi tidak yang lain, aturan untuk apa yang tercakup perlu didefinisikan dengan sangat jelas.
Hanya mendukung nilai yang dapat muncul sebagai bilangan bulat, float, dll. membuat semuanya menjadi sangat jelas dan masih menciptakan kontrol yang memberikan banyak nilai.

@SavoySchuler Desain saya sepenuhnya siap membantu Anda, saya mempostingnya untuk mencoba membantu memvisualisasikan kontrol untuk semua orang yang berkontribusi.

@rudyhuyn Jika Anda memposting proposal untuk MaskedTextBox atau FormattedTextBox, itu mungkin lebih berat! Seperti halnya NumberBox, saya senang jika salah satu desain saya disertakan dalam proposal semacam itu, dan dapat membuat lebih banyak contoh sesuai kebutuhan Anda.

@mrlacey Nomor telepon (terlepas dari karakter pemformatan) adalah angka murni - tetapi mereka tidak termasuk dalam kasus penggunaan perhitungan apa pun, jadi apakah lebih cocok dengan Kotak Teks bertopeng, atau adakah nilai dalam memberikan dukungan untuk ini di Kotak Nomor?

Saat membuat kontrol dan dokumentasi, berikan kasus penggunaan yang jelas dan contoh kontrol mana yang akan digunakan dalam konteks apa yang penting.

@mrlacey : Saya tidak.

Seperti yang Anda katakan sebelumnya, kita harus memisahkan bilangan real, tidak hanya sesuatu yang menggunakan 0-9 karakter tetapi juga terkait dengan nilai aritmatika.

Alamat IP, nomor telepon, SSN, kode pos menggunakan 0-9 karakter tetapi tidak memiliki nilai aritmatika (Anda dapat menambahkan 2 di antaranya, jika Anda menambahkan ".00" di akhir, Anda mengubah arti nilainya, dll.) . Dalam kasus ini, nilainya adalah string, bukan int/double, MaskedTextBox akan lebih masuk akal.

Selain itu, kode pos hanya menggunakan angka di AS, tetapi tidak di Kanada misalnya, alamat IPv6 dapat berisi karakter AF, nomor telepon dapat berisi tanda + (555-123-4567 dan +555-123-4567 adalah 2 yang berbeda nomor telepon), dll...

Untuk meringkas pendapat saya, NumberBox.Value harus ganda, bukan string.

@mrlacey Nomor telepon (terlepas dari karakter pemformatan) adalah angka murni - tetapi mereka tidak termasuk dalam kasus penggunaan perhitungan apa pun, jadi apakah lebih cocok dengan Kotak Teks bertopeng, atau adakah nilai dalam memberikan dukungan untuk ini di Kotak Nomor?

Nomor telepon mungkin seluruhnya terdiri dari angka (ditambah pemformatan) tetapi itu tidak menjadikannya angka. Anda tidak dapat melakukan operasi aritmatika apa pun pada mereka dan mendapatkan sesuatu yang berarti.
Juga, beberapa dapat memulai dengan tanda plus.
Juga, jumlah nol di depan nomor telepon bermakna. Untuk nilai numerik tidak.
Fungsionalitas lain di kontrol, seperti kalkulasi atau tombol naik&turun, tidak masuk akal untuk "nomor telepon".

Kontrol ini harus dibatasi pada nilai yang dapat dikonversi ke int/uint atau desimal tanpa risiko kehilangan informasi.

Untuk memastikan saya mensintesis umpan balik ini dengan tepat, tolong beri saya jempol pada komentar ini jika Anda yakin ini adalah tempat terbaik untuk semua jenis input string numerik (seperti nomor telepon dan IPv4) melalui jenis format dan jempol- turun jika fungsionalitas itu harus ditangguhkan ke kontrol lain atau baru sehingga NumberBox berfokus secara eksklusif pada matematika dan penangkapan nilai matematika. (Memperhatikan fitur yang mendukung operasi matematika seperti mode kalkulator dan tombol Atas/Bawah memerlukan pengaktifan melalui API masing-masing.)

Saya tidak dapat menjamin bahwa ini akan diputuskan secara demokratis karena saya akan membuat keputusan yang menghasilkan pengembalian investasi terbaik bagi pelanggan kami secara global - tetapi ini akan membantu memvalidasi apa yang saya pikir saya lihat di sini: tidak ada yang meminta ini untuk mendukung numerik string dan akan lebih memilih kontrol khusus untuk itu.

@SavoySchuler Angka yang dapat dioperasikan, ditambah dan dikurangi, serta awalan dan akhiran yang menambah konteks dan makna pada nilai.

Saya baru saja menyinkronkan dengan tim di sini dan ingin berbagi pembaruan tentang beberapa pertanyaan terbuka kami:

• Kami mendengarkan tanggapan Anda dan kami setuju NumberBox bukanlah tempat yang tepat untuk string numerik. Properti FormatKinds dan CustomFormat telah diganti dengan API yang lebih spesifik untuk mengontrol format angka dengan cara yang lebih intuitif.
• Prefix dan Suffix benar-benar termasuk dalam TextBox (dari mana NumberBox akan mewarisinya). Saya akan memberi @mdtauk , @mrlacey , atau siapa pun beberapa hari untuk mulai mengajukan permintaan fitur jika tidak, saya akan memulainya dan menautkannya di sini. Untuk saat ini, itu akan menghindari NumberBox diblokir pada output lokalisasi/otomatisasi.
• Umpan terakhir di NumberBox (setelah perhitungan, pembulatan, dll.) akan dipertahankan sebagai String di properti Text yang berasal dari TextBox DAN sebagai Double di properti Value baru. Kami bermaksud untuk memiliki umpan balik ini satu sama lain sehingga perubahan pada yang satu akan tercermin di yang lain. Tujuannya adalah untuk mengambil sebanyak mungkin pekerjaan dari tangan Anda dan memiliki nilai yang siap untuk diakses saat Anda membutuhkannya.
• StepSize tidak ada sebagai properti pada spesifikasi.
• Jenis bilangan bulat akan diubah menjadi Ganda.
• Kami masih bersemangat untuk ide kalkulator tertanam dan mencari lebih banyak skenario untuk membantu kami memperbaikinya. @mdtauk , terima kasih telah menanggapi poin umpan balik ini!
• Mengenai validasi input, idenya adalah untuk terlebih dahulu mengirim jenis acara ValueChanged yang akan memberi pengembang kesempatan untuk memanipulasi input atau menanganinya pada pengiriman formulir akhir/blok mereka sesuai kebutuhan. Jika tidak ada tindakan korektif yang diambil (seperti memaksanya dalam min/max, menghapus karakter yang tidak valid, dll.), NumberBox akan menampilkan indikasi kesalahan kepada pengguna tentang input mereka. Pendekatan dua kali lipat ini memberi pengembang untuk merespons jika mereka mau, tetapi juga memungkinkan koreksi ditangguhkan kepada pengguna.

Ada banyak sekali masukan yang masih saya tanggapi. Terima kasih atas kesabaran Anda, saya akan membalas semua orang di sini dan di repo spesifikasi juga!

"Konsep seni NumberBox dengan kalkulator tertanam." Komunitas WinUI, Mei 2019. (berwarna)

(Pujian dari @ryandemopoulos )

@SavoySchuler Anda meminta beberapa contoh skenario di mana jenis kontrol yang kita diskusikan dapat digunakan. Saya memiliki dua di aplikasi saya yang mungkin merupakan contoh yang baik.

Kasus 1: Ada editor pengaturan untuk grafik 2D di mana Anda dapat menyesuaikan sumbu.

• Ini hanya membutuhkan input numerik sederhana. Tombol kenaikan +/- akan berguna di sini.
• Nilai ganda akan baik-baik saja tetapi input perlu divalidasi pada pers karakter. Pengguna seharusnya tidak pernah bisa menekan 'a' dan membuatnya muncul di kotak input. Validasi input tidak boleh membuat batas merah dan memberi peringatan kepada pengguna -- seharusnya tidak mungkin memasukkan nilai yang tidak valid.
• Lokalisasi harus didukung oleh kontrol dan pemindahan tempat desimal (apakah koma, titik, dll.) ditangani sebagai kasus khusus (saya terus membahas ini karena mudah dilewatkan)

Kasus 2: Ada bidang input untuk nilai mata uang seperti yang ditunjukkan di bawah ini. Ini adalah kontrol khusus "CurrencyBox"

• Ini bisa menggunakan tombol kalkulator dan kemampuan untuk memasukkan persamaan 2+3 akan memiliki nilai di sini (saya masih merasa ini harus menjadi kontrol yang terpisah)
• Nilai ganda TIDAK ideal untuk ini. Saya akan menyarankan mengubah spesifikasi untuk Nilai dari ganda ke desimal untuk mendukung jenis kasus penggunaan . Jika tidak, terserah pengembang untuk mengurai teks string.
• Ada kasus khusus di sini di mana tanda negatif ditangani secara terpisah. Itu membuatnya lebih mudah bagi pengguna untuk tidak membuat kesalahan saat masuk. Saya sebenarnya tidak mengharapkan NumberBox untuk mendukung itu di luar kotak.
• Perataan teks penting untuk disetel dan awalan/akhiran akan sangat berguna untuk menampilkan simbol mata uang (Lokalisasi masih berpotensi menjadi masalah mengetahui apakah akan menampilkan simbol di kanan atau kiri; namun, aplikasi itu sendiri dapat memiliki logika itu)
• Pengguna dapat memasukkan nilai asing atau lokal. NumberFormatInfo dan CultureInfo untuk kedua nilai tersebut BISA berbeda dari budaya UI. Oleh karena itu, untuk pelokalan, kontrol harus mendukung penggantian ke NumberFormatInfo kustom.

Saat ini di aplikasi Windows Community Toolkit digunakan untuk kedua kasus dengan properti terlampir ke TextBox seperti di bawah ini:
TextBoxRegex.ValidationMode="Dinamis"
TextBoxRegex.ValidationType="Desimal"

Beberapa komentar terakhir (maaf ini sangat panjang!)

• Saya pikir kita sedang mendiskusikan kemungkinan 3 kontrol yang berbeda di sini. NumberBox tulang-tulang, CalculatorBox yang dapat memiliki persamaan dan input numerik tingkat lanjut (tombol Kalkulator!), dan terakhir MaskedTextBox untuk input non-numerik seperti nomor telepon dan alamat IP. Kita seharusnya tidak membuat mereka bingung dan menyetujui bagaimana memisahkan konsep-konsep ini adalah kunci untuk bergerak maju dengan spesifikasi.
• Kami tidak dapat kehilangan fokus dari kasus penggunaan yang paling mendasar dan bisa dibilang paling berguna: Kotak teks yang tampak normal dengan tidak lebih dari pemfilteran input sehingga hanya nomor yang valid yang dapat dimasukkan. Semua opsi lain harus dapat dimatikan (saya sedang memikirkan tombol kenaikan +/-)
• Saya masih menyarankan untuk mengubah dari ganda ke desimal dalam spesifikasi untuk menangkap presisi desimal secara akurat dalam Nilai yang diuraikan. Selain itu, kita mungkin harus mempertimbangkan masukan bilangan bulat berbeda dari masukan bilangan rasional. Itu mungkin properti baru di API "IsInteger = true" untuk diubah dari default desimal.

Sunting: Gagasan yang dihapus untuk beralih dari ganda ke desimal untuk tipe NumberBox.Value. Saya salah dalam mengasumsikan ini ada di dunia C++ WinRT. Tidak, dan sebaliknya hanya di .net core/framework.

@robloo , tentang komentar terakhir itu, tidak ada tipe Desimal di WinRT.

Debugger Visual Tree XAML Toolkit adalah alat yang sangat bergantung pada kontrol NumericUpDown toolkit di mana penambahan/pengurangan dengan drag mouse, tombol, keyboard semuanya penting. Masukan kalkulator mungkin juga membantu:

@robloo dan @xyzzer, ini adalah persis jenis info yang saya cari!

Validasi/Penutupan

@robloo , saya sangat tertarik dengan Kasus 1: Bullet 2 - validasi vs masking. Mari kita bicara melalui skenario "input buruk" mulai sekarang:

• Pengguna baru mengetik "dua" di NumberBox Anda.
• NumberBox memunculkan acara "ValueChanged" yang memberi Anda kesempatan untuk mengembalikan input non-numerik ke "0" - atau sebaliknya - jika Anda mau. Jika tidak ada tindakan yang diambil, maka ...
• Tendangan validasi di NumberBox bersinar merah dan memunculkan pesan kesalahan kepada pengguna yang memberi tahu mereka bahwa hanya input numerik yang diizinkan (bagian ini sebenarnya belum sepenuhnya dirasionalisasi, jadi ini hanya hipotetis).

Apakah rangkaian acara ini memberi Anda kemampuan untuk menciptakan pengalaman yang Anda butuhkan untuk menciptakan?

Saya mengerti bahwa masking bisa menjadi default yang diinginkan, tetapi izinkan saya membagikan apa yang didiskusikan tim saya minggu lalu - kami mendarat di arah bahwa validasi (indikator kesalahan/pesan) lebih disukai dalam kontrol Lancar sebagai alternatif, masking, dapat membuat frustasi dan membingungkan bagi pengguna akhir ketika mereka tidak mengalami output dari entri keyboard mereka. Cara lain untuk memikirkannya adalah bahwa validasi menawarkan tingkat transparansi dan informasi kepada pengguna yang membuat mereka lebih sadar akan pengalaman daripada dipaksa diam-diam. Jadi, tindakan kami saat ini adalah membangun validasi dasar tanpa menghalangi kesempatan bagi pengembang untuk menambahkan validasi lanjutan (segera hadir ke TextBox) atau menutupi melalui acara ValueChanged sesuai kebutuhan. Untuk memahami, ini cukup fleksibel untuk memungkinkan semua kebutuhan terpenuhi sambil memberikan pengalaman yang direkomendasikan sebagai default.

Apa yang Anda pikirkan di sini? Saya akan tertarik dengan ide apa pun yang Anda miliki untuk menyusun konsep-konsep ini lebih lanjut atau membangun pengalaman yang lebih baik jika kita bisa.

Pemformatan Nilai

Untuk poin Anda yang lain, @robloo , saya telah menambahkan properti presisi DecimalPrecision ke Spec . Menyetel ini ="0" akan menghasilkan bilangan bulat. Selain itu, menyetel MinValue="0" dapat membantu menjaga angka tetap non-negatif (atau peristiwa ValueChanged adalah kesempatan lain untuk memaksa input ke nilai absolut).

Apakah Anda melihat melalui Spec belum? Saya yakin saya telah menyertakan semua properti yang diperlukan untuk mengaktifkan pengalaman Anda sepenuhnya (menunggu validasi vs. diskusi penyembunyian) tetapi saya ingin tahu apakah menurut Anda saya melewatkan sesuatu.

masking, dapat membuat frustasi dan membingungkan pengguna akhir ketika mereka tidak mengalami output dari entri keyboard mereka.

100% setuju ya. Hal yang lebih baik untuk dilakukan adalah memvalidasi pada LosingFocus/EnterPressed dan mengembalikan oldValue jika nilai yang diketik tidak memvalidasi, itulah sebabnya sinyal yang dipicu pada LosingFocus/EnterPressed dan berisi oldValue/newValue akan sempurna untuk dimiliki.

@adrientetar , poin bagus! Apakah itu pengalaman yang perlu Anda ciptakan? Jika demikian, saya akan melihat apa yang perlu kita lakukan agar acara ValueChanged mengirimkan nilai lama dan nilai baru.

@SavoySchuler Ini adalah sesuatu yang ingin saya lakukan di aplikasi saya, saya akan membangun perilaku itu sendiri kecuali kontrol melakukannya secara default.

Hal lain yang saya inginkan adalah Shift+↑/↓ untuk kenaikan 10 dan Ctrl+Shift+/↓ untuk kenaikan 100, meskipun menurut saya kenaikan 100 tidak selalu masuk akal untuk dimiliki.

Poin yang bagus! Kita harus memastikan kontrol berasal dari RangeBase yang
mendefinisikan SmallChange dan LargeChange dan kami menggunakan keduanya di
paling tidak.
Apakah ada contoh kombinasi keyboard standar yang digunakan untuk memanggil
perubahan besar pada RangeBase UWP atau WinForms/ComCtl(?) NumericUpDown?

Pada Mon, Jun 3, 2019 at 3:50 Adrien Tetar [email protected]
menulis:

@SavoySchuler https://github.com/SavoySchuler Ini adalah sesuatu yang saya inginkan
lakukan di aplikasi saya memang, saya akan membangun perilaku itu sendiri kecuali kontrolnya melakukannya
secara default.

Hal lain yang saya inginkan adalah Shift+↑/↓ untuk kenaikan 10 dan
Ctrl+Shift+↑/↓ untuk penambahan 100, meskipun menurut saya penambahan 100
tidak selalu masuk akal untuk dimiliki.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTLOment
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

Saya akan memeriksa untuk memverifikasi, tetapi saya cukup yakin bahwa pintasan keyboard harus diserahkan kepada aplikasi untuk diterapkan. Saya mencoba ini dengan pembenaran Aksesibilitas untuk # 21 dan memperkenalkan pintasan keyboard baru adalah permainan yang berisiko untuk dimainkan karena hampir semua dari mereka yang tidak diklaim oleh Windows kini telah diambil di tingkat aplikasi (yang dikatakan TeachingTip dapat melompat kereta musik F6) - tetapi saya akan memeriksa untuk melihat apakah fokus kontrol memungkinkan pengecualian apa pun di sini!

Build 2018 adalah saat status validasi untuk kontrol TextBox diumumkan, menggunakan INotifyDataErrorInfo.
Ini akan baik digunakan dengan masking untuk memvalidasi atau membatalkan string Teks saat ini.

EDIT: Penggunaan Ikon dan warna batas bawah yang lebih tebal, adalah untuk membantu pengenalan dalam situasi buta warna, dan ketika dilihat dalam Hitam Putih. Teks kesalahan bawah dapat dilakukan sebagai tooltip pada ikon jika ruang pada premium.

@mdtauk Anda sangat fenomenal di mark up ini. Saya akan menjalankan ini oleh desainer kami, mereka tampak hebat bagi saya!

@SavoySchuler Ekstrapolasi mudah berdasarkan contoh yang ditunjukkan di Build 2018

Dan masih banyak contohnya :)

Maaf, ini satu lagi yang panjang!

@SavoySchuler @adrientetar Saya pasti melihat dari mana Anda berasal dengan pernyataan Anda di bawah ini. Saya tidak akan berargumen bahwa dalam sebagian besar kasus, ini adalah cara terbaik untuk menangani validasi. Namun, saya harus berpikir bahwa ada beberapa kasus khusus di mana itu jelas merupakan input numerik saja sehingga Anda benar-benar membantu pengguna dengan tidak mengizinkan mereka untuk menggemukkan karakter yang salah.

masking, dapat membuat frustasi dan membingungkan pengguna akhir ketika mereka tidak mengalami output dari entri keyboard mereka.

100% setuju ya. Hal yang lebih baik untuk dilakukan adalah memvalidasi pada LosingFocus/EnterPressed dan mengembalikan oldValue jika nilai yang diketik tidak memvalidasi, itulah sebabnya sinyal yang dipicu pada LosingFocus/EnterPressed dan berisi oldValue/newValue akan sempurna untuk dimiliki.

Namun demikian, saya memutuskan untuk melihat-lihat aplikasi lain untuk melihat bagaimana penanganannya. Saya tidak berpikir ada orang yang melakukan lebih banyak penelitian daripada Microsoft tentang interaksi pengguna, jadi saya mengambil Word versi 64-bit Desktop dan kemudian OneNote versi UWP untuk referensi. Itu kurang lebih sepenuhnya setuju dengan apa yang kalian katakan. Saya dapat mengetikkan teks apa pun ke dalam kotak input ukuran font atau ukuran bentuk yang jelas-jelas hanya input numerik. Ini sebagian besar memvalidasi kehilangan fokus dan kembali ke input valid terakhir.

| Judul | foto | Komentar |
|------|-----|------------|
| Entri Ukuran Font UWP OneNote | | Nilai apa pun dapat dimasukkan dari keyboard, secara otomatis divalidasi dan disetel ulang ke nilai valid terakhir saat kehilangan fokus |
| Entri Ukuran Font Word Desktop | | Nilai apa pun dapat dimasukkan dari keyboard, secara otomatis divalidasi pada kehilangan fokus dan pesan kesalahan muncul jika tidak valid. Pada klik [OK] reset ke nilai valid terakhir. |
| Grafik UWP OneNote 2D | | Nilai apa pun dapat dimasukkan dari keyboard. Nilai yang tidak valid akan diabaikan begitu saja dan input valid terakhir yang digunakan dalam perhitungan (tidak memvalidasi fokus yang hilang). Menekan tombol kenaikan +/- akan bertambah menggunakan input valid terakhir. |
| Entri Ukuran Bentuk Kata Desktop | | Nilai apa pun dapat dimasukkan dari keyboard, secara otomatis divalidasi pada kehilangan fokus dan diatur ulang ke nilai valid terakhir pada kehilangan fokus. |

Jadi saya kira saya baru saja membuktikan diri saya salah yang berarti saya harus setuju dengan Anda!

Komentar sampingan:

• Seperti yang disebutkan sebelumnya oleh orang lain, ketika NumberBox memiliki fokus keyboard dengan keyboard sentuh/virtual hanya keyboard numerik yang akan ditampilkan.
• Kenaikan ke bawah di sebelah kiri dan kenaikan di sebelah kanan adalah ide yang menarik untuk dibahas di sini dalam hal gaya. Saya suka itu!
  

• Pengguna baru mengetik "dua" di NumberBox Anda.
• NumberBox memunculkan acara "ValueChanged" yang memberi Anda kesempatan untuk mengembalikan input non-numerik ke "0" - atau sebaliknya - jika Anda mau. Jika tidak ada tindakan yang diambil, maka ...
• Tendangan validasi di NumberBox bersinar merah dan memunculkan pesan kesalahan kepada pengguna yang memberi tahu mereka bahwa hanya input numerik yang diizinkan (bagian ini sebenarnya belum sepenuhnya dirasionalisasi, jadi ini hanya hipotetis).
  Apakah rangkaian acara ini memberi Anda kemampuan untuk menciptakan pengalaman yang Anda butuhkan untuk menciptakan?
  Apa yang Anda pikirkan di sini? Saya akan tertarik dengan ide apa pun yang Anda miliki untuk menyusun konsep-konsep ini lebih lanjut atau membangun pengalaman yang lebih baik jika kita bisa.

Saya benar-benar mengerti dan setuju bahwa menambahkan validasi input sangat bagus untuk keseluruhan platform. Namun, pada dasarnya Anda baru saja menjelaskan validasi input tanpa penanganan khusus untuk suatu angka. Oleh karena itu, apa gunanya NumberBox selain mem-parsing nilai secara otomatis? Sebagai pengembang tampaknya TextBox dengan validasi data kurang lebih sama.

Saya pikir berdasarkan contoh saya di atas, fungsionalitas di luar kotak harus merupakan campuran dari kedua ide kami dan itulah yang dikatakan @adrientetar . Pengguna dapat mengetikkan nilai apa pun sehingga mereka mendapatkan umpan balik visual. Namun, pada kehilangan fokus, nilai divalidasi secara otomatis dan nomor valid sebelumnya (atau kosong) secara otomatis dikembalikan ke. Ini menghemat kerumitan pengembang karena harus menangani validasi input sendiri (kita sudah tahu itu harus berupa Angka di NumberBox). Ini juga jelas membedakan dari hanya TextBox dengan validasi data.

Dalam hal acara, saya masih ingin memiliki kesempatan untuk membatalkan perubahan teks jika kasus penggunaan itu menjadi lebih jelas. Oleh karena itu, selain ValueChanged, saya akan merekomendasikan acara ValueChanging dan TextChanging untuk memungkinkan input dibandingkan dan dibatalkan. Tentu saja OldValue dan NewValue diperlukan, setidaknya ini akan memungkinkan kami untuk dengan cepat mengubahnya kembali ke OldValue jika diperlukan (Meskipun UWP suka macet ketika Anda memodifikasi TextValue dalam suatu acara).

Mengenai spesifikasi: Ide bagus dengan DecimalPrecision, saya perlu lebih banyak waktu untuk membahasnya dan menambahkan komentar saya. Ada banyak nuansa kecil seperti nilai defaultnya adalah String=Empty, Value=Null dan ketika tombol kenaikan +/- ditekan, nilainya harus diperlakukan sebagai nol, bukan kosong.

@mdtauk Seharusnya tidak mungkin secara manusiawi membuat ilustrasi yang bagus begitu cepat :)

@robloo Terima kasih atas komentar
Mungkin lebih baik untuk tetap menggunakan simbol Atas dan Bawah yang digunakan dalam tombol putar saat ini, untuk menghindari kebingungan dengan operasi matematika yang dapat dilakukan NumberBox ini.

iOS menggunakan kontrol "stepper", tetapi entri teks terpisah, dan tidak ada penghitungan sebaris.

Berikut adalah beberapa desain lagi yang saya temukan

Desain yang saya pilih tampaknya sesuai dengan gaya khas Microsoft untuk kontrol ini, tetapi apakah ini pilihan terbaik, atau pilihan yang tepat. Saya akan tertarik untuk mendengar apa yang orang lain pikirkan tentangnya.

EDIT: Menambahkan beberapa tiruan bentuk alternatif (tapi saya pikir ide pertama adalah yang terbaik ...)

Saya setuju dengan @mdtauk di lokasi +/-, yang pertama adalah yang terbaik.

Ada XAML ControlTemplate sehingga pengguna (pengembang) selalu dapat membuat template khusus untuk dua tata letak lainnya.

@robloo , Anda tidak perlu meminta maaf atas tanggapan terperinci - terutama ketika mereka tertawa Pertanyaan Terbuka pada spesifikasi untuk dijalankan oleh devs/tim dan memastikan tidak ada overhead kinerja yang tidak dapat diterima dalam melakukannya. Saya pikir itu akan menjadi kenyamanan yang luar biasa bagi pengguna jika kita bisa mewujudkannya.

Anda mengemukakan poin bagus tentang validasi ...

[1] Waktu pertanyaan: Apakah ada yang menentang sistem validasi yang secara otomatis mengembalikan input yang tidak dapat diterima kembali ke nilai sebelumnya sambil mengekspos peristiwa yang memungkinkan pengembang untuk membatalkan perilaku ini dan sebagai gantinya memutuskan apa yang harus dilakukan/meningkatkan indikator atau pesan kesalahan?

Secara visual, saya melihat manfaat dari UpDownButtons yang terputus-putus dalam contoh yang Anda posting. Saya percaya @mdtauk dan @sonnemaf berada di jalur yang benar untuk default. Kedekatan UpDownButtons adalah kenyamanan mereka yang sebenarnya, apakah seseorang menguji hasil bolak-balik dari input yang berbeda (tetapi tidak jauh) atau mengoreksi input yang terlampaui. Jarak, kecuali sesuai dengan peningkatan desain atau fungsionalitas, akan tampak menambah tenaga kerja yang dapat dihindari pada pengalaman dan juga dapat mengganggu kejelasan dengan properti Prefix/Suffix/pelabelan yang bertentangan dengan pengelompokan ini secara jelas sebagai bagian fungsional dari kontrol, misalnya: $ [ - ] 192 [+]

Saya percaya ada skenario untuk UpDownButtons yang terputus-putus. Pikiran saya tertuju pada tugas-tugas yang mengharapkan masukan minimal dan satu arah atau tugas-tugas di mana pengembang berusaha membuat kesalahan masukan lebih sulit dilakukan. Saya percaya ini adalah pengalaman yang diberikan beberapa aplikasi dan situs web ketika, misalnya, seseorang membeli tiket film atau konser.

Pertanyaan saya kemudian adalah...

[2] Waktu pertanyaan: Haruskah kita mengandalkan Xaml ControlTemplate untuk membuat NumberBox dengan UpDownButtons yang terputus-putus (yaitu, ini tidak cukup umum untuk membenarkan dukungan di luar kotak) atau haruskah kita menyertakan properti untuk mengatur apakah UpDownButtons tampak bersebelahan vs terputus-putus?

Saya akan melakukan ping ke @chigy untuk pertanyaan ini karena pedoman Sistem Desain Lancar dapat menimpa pertanyaan kedua ini.

Saya harus menyertakan pertimbangan Aksesibilitas untuk percakapan UpDownButtons: kedekatan UpDownButtons satu sama lain memungkinkan kejelasan konseptual untuk pengguna Narator/pembaca layar sambil juga mempertahankan efisiensi navigasi untuk pengguna navigasi papan ketik dan juga penting untuk tidak mengkompromikan hal ini.

Jika kontrolnya tidak terlalu lebar, Anda ingin panah menumpuk secara vertikal (saya tahu saya membutuhkannya di aplikasi saya). Mungkin kontrol dapat dibuat responsif terhadap lebar yang ditetapkan? Terserah pedoman desain yang fasih untuk menentukannya seperti itu jika mereka pikir itu masuk akal.

Saya telah memperbarui proposal dengan 3 pertanyaan terbuka kami.

Terima kasih @mdtauk untuk desain konsepnya!

@adrientetar Saya senang Anda menunjukkan itu sebagai kebutuhan. Kedengarannya seperti mungkin kita memerlukan enum untuk ketiga konfigurasi ini?

Jika kontrolnya tidak terlalu lebar, Anda ingin panah menumpuk secara vertikal (saya tahu saya membutuhkannya di aplikasi saya). Mungkin kontrol dapat dibuat responsif terhadap lebar yang ditetapkan? Terserah pedoman desain yang fasih untuk menentukannya seperti itu jika mereka pikir itu masuk akal.

Ada proposal untuk mengizinkan kontrol agar sadar dan responsif terhadap jumlah ruang yang mereka miliki untuk mereka #677 Ini dapat digunakan untuk memposisikan ulang Tombol Putar saat kontrol menjadi lebih sempit. Mungkin perlu ada properti untuk NarrowWidth yang mirip dengan MinWidth, atau mungkin bahkan NumberOfDigits untuk bertindak sebagai petunjuk?

Mengenai contoh teks yang berwarna abu-abu - Saya khawatir ini dapat mendorong pengguna untuk mengisi nilai yang muncul, daripada bertindak sebagai petunjuk tentang hasil akhirnya. Itu terlihat seperti PlaceholderText.

Bagaimana dengan menggunakan AccentColor dan bobot font yang berbeda untuk membuatnya menonjol?

Tautan yang bagus, @mdtauk. Saya membayangkan bahwa jika ini adalah jalan yang kita lalui, kita dapat menanganinya dengan enum yang memiliki nilai seperti [Auto, Vertical, Horizontal, Detached] di mana Auto akan lebih memilih Horizontal hingga kekompakan mewajibkan Vertikal. Pikiran?

Juga, saya telah memperbarui gambar! Saya pikir Anda benar bahwa teks yang berwarna abu-abu dapat terlihat seperti prompt, yang jika diikuti, akan menghasilkan kesalahan karena "=".

Tautan yang bagus, @mdtauk. Saya membayangkan bahwa jika ini adalah jalan yang kita lalui, kita dapat menanganinya dengan enum yang memiliki nilai seperti [Auto, Vertical, Horizontal, Detached] di mana Auto akan lebih memilih Horizontal hingga kekompakan mewajibkan Vertikal. Pikiran?

Pikiran awal adalah, apakah jumlah dalam wadah akan cukup besar di mana orientasi vertikal diperlukan? AutoCompleteBox tidak memindahkan tombol Cari, dan string biasanya lebih panjang dari angka.

Jika itu adalah sesuatu yang murni tergantung pada ruang yang tersedia, perilaku responsif otomatis (jika proposal itu disetujui) akan lebih baik daripada enum. Memberi pengembang opsi dalam kontrol itu sendiri dapat menyebabkan penggunaan kontrol yang kurang konsisten, tetapi saya pikir ini perlu menjadi sesuatu yang menurut penelitian pengguna harus dilihat, daripada ditentukan oleh kami sendiri di github.

Pengembang selalu memiliki opsi untuk membuat template ulang kontrol jika mereka _benar-benar_ membutuhkan tata letak yang berbeda untuk kontrol, dan dimungkinkan untuk menyertakan Gaya alternatif untuk itu jika Anda ingin A) lakukan upaya membuat default dan Gaya dan template vertikal - dan B) memastikan kedua gaya diuji dengan benar

@mdtauk Saya setuju simbol atas/bawah adalah yang terbaik. Saya hanya ingin menunjukkan contoh dengan panah di sisi berlawanan dari input. Seperti yang disebutkan sebelumnya yang membantu memastikan pengguna tidak menekan yang salah yang hampir wajib di UI berbasis sentuhan. Contoh yang saya berikan dari OneNote kebetulan memiliki simbol +/- tetapi saya harus menambahkan untuk mengabaikan simbol itu sendiri.

@SavoySchuler

[2] Waktu pertanyaan: Haruskah kita mengandalkan Xaml ControlTemplate untuk membuat NumberBox dengan UpDownButtons yang terputus-putus (yaitu, ini tidak cukup umum untuk membenarkan dukungan di luar kotak) atau haruskah kita menyertakan properti untuk mengatur apakah UpDownButtons tampak bersebelahan vs terputus-putus?

Saya tahu ketika UWP pertama kali dibuat, itu adalah sentuhan pertama - oleh karena itu UpDownButtons yang terputus-putus bisa dibilang lebih baik. Sejak itu persyaratan sentuh-pertama telah dilonggarkan dan pasti tombol-tombol yang bersebelahan lebih baik bila pengguna memiliki metode input yang tepat seperti mouse (jarak tempuh lebih sedikit). Karena ini bergantung pada kasus penggunaan, saya setuju bahwa enum berguna untuk menentukan bagaimana UpDownButtons akan muncul.

Untuk nilai enum, kami telah membahas beberapa status dan menggeneralisasi kami dapat menambahkan beberapa lagi:

• TerpisahHorizontal : Panah bawah di sebelah kiri, Panah atas di sebelah kanan
• Terpisah Vertikal : Panah bawah di bawah, Panah atas di atas
• Kiri : Panah Bawah dan Atas di samping satu sama lain di sebelah kiri (dalam orientasi horizontal)
• Kanan : Panah Bawah dan Atas di samping satu sama lain di sebelah kanan (dalam orientasi horizontal)
• Atas : Panah Bawah dan Atas di samping satu sama lain di atas (dalam orientasi vertikal)
• Bawah : Panah Bawah dan Atas di samping satu sama lain di bagian bawah (dalam orientasi vertikal)

Jika semua ini menjadi terlalu rumit (secepatnya) saya dengan senang hati membuat template ulang kontrol untuk kasus penggunaan saya sendiri di XAML.

Hanya untuk membuang ide lain: mengubah orientasi simbol untuk UpDownButtons yang terputus-putus mungkin masuk akal juga [<] 123 [>] . Jangan ragu untuk mengabaikan kerumitan tambahan ini karena hal itu tentu saja dapat dibenahi kembali berdasarkan aplikasi per aplikasi.

Juga, beberapa masalah aksesibilitas mungkin telah diatasi di OneNote dari mana saya mengambil contoh.

@robloo Saya pikir penempatan kiri dan kanan yang Anda sebutkan, harus disimpan untuk pelokalan RtL dan LtR - daripada pengaturan rahasia.

Di bawah ini adalah pendapat saya

Saya juga tidak yakin menempatkan tombol di atas bidang teks masuk akal secara semantik, apalagi ketika Anda meletakkan jari Anda di tombol, mungkin membuat sulit untuk melihat nomor yang berubah.

Memiliki setiap kombinasi yang dibangun ke dalam kontrol akan menyebabkan penggunaan yang kacau, dan semua hal itu dapat dilakukan dengan re-templating jika ada kebutuhan yang mendesak.

Tombol di bawah bidang teks mungkin digunakan di area terbatas ruang, dan sebagai opsi pada kontrol itu sendiri, karena membuat tombol jauh lebih besar untuk diketuk. Apakah itu sebagai gaya yang dibundel dengan kontrol, atau enum antara:

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

Hanya pertanyaan singkat yang mungkin merupakan saran: Secara teori, dalam kotak angka, seseorang seharusnya hanya dapat memasukkan angka ke dalam kotak angka. Seberapa sulitkah untuk mengurai angka tertulis dan menerjemahkannya menjadi angka sebenarnya untuk bidang ini?

Sebagai contoh:
satu + dua = 3
menerjemahkan
1 + 2 = 3

Atau
satu tambah dua sama dengan tiga
diterjemahkan menjadi
1 + 2 = 3

Ini hanya sebuah ide.

Hanya pertanyaan singkat yang mungkin merupakan saran: Secara teori, dalam kotak angka, seseorang seharusnya hanya dapat memasukkan angka ke dalam kotak angka. Seberapa sulitkah untuk mengurai angka tertulis dan menerjemahkannya menjadi angka sebenarnya untuk bidang ini?

Sebagai contoh:
satu + dua = 3
menerjemahkan
1 + 2 = 3

Atau
satu tambah dua sama dengan tiga
diterjemahkan menjadi
1 + 2 = 3

Ini hanya sebuah ide.

Itu masuk akal, untuk bahasa Inggris. Ini menjadi masalah ketika Anda perlu menerjemahkan dan mengurai string tersebut untuk bahasa lain. Dan bagaimana dengan pengguna bahasa Polandia, mengetik dalam kata-kata bahasa Inggris?

Seperti sekarang, hanya bentuk angka 0-9, desimal, pemisah angka dan operator matematika - telah dibahas. Tetapi sistem nomor lain mungkin perlu dipenuhi.

Menambahkan terjemahan bahasa akan menjadi upaya besar, dan tidak jelas apa manfaatnya.

Sekarang jika kontrol ini dimanipulasi oleh input audio, maka ucapkan nomor atau operasinya - yang mungkin melibatkan penafsiran bahasa yang diucapkan.

Narator:
"Piksel NumberBox tanpa nilai"

PENGGUNA:
"Seratus Dua Puluh Delapan piksel"

[ 128 _________ | px ]

PENGGUNA:
"Tambahkan Enam Puluh Empat piksel"

[ 192 _________ | px ]

Narator:
"Seratus Sembilan Puluh Dua piksel"

[1] Waktu pertanyaan: Apakah ada yang menentang sistem validasi yang secara otomatis mengembalikan input yang tidak dapat diterima kembali ke nilai sebelumnya sambil mengekspos peristiwa yang memungkinkan pengembang untuk membatalkan perilaku ini dan sebagai gantinya memutuskan apa yang harus dilakukan/meningkatkan indikator atau pesan kesalahan?

Jika Teks yang dimasukkan menjadi tidak valid, mengapa Nilai diubah menjadi sesuatu yang lebih lama? Saya tidak berpikir mencoba mempertahankan "pengetahuan terakhir yang baik Value " adalah sesuatu yang harus menjadi tanggung jawab kontrol. Biarkan kontrol menangani satu nilai saat ini (atau status kesalahan) dan biarkan aplikasi menangani pemrosesan historis tambahan apa pun yang diperlukan melalui peristiwa ValueChanged .

Untuk versi awal saya pikir akan baik-baik saja dengan hanya mendukung satu posisi tombol Atas/Bawah karena dapat diatur ulang jika perlu.
Jika kemampuan untuk menentukan posisi tombol Atas/Bawah dianggap suatu keharusan maka enum apa pun yang ditambahkan harus menghilangkan kebutuhan untuk memiliki properti UpDownButtonsEnabled dan nilai enum Hidden dapat menjadi ditambahkan sebagai gantinya.
Perhatikan juga bahwa memiliki dukungan bawaan untuk memanipulasi posisi tombol Atas/Bawah akan menambah kerumitan bagi siapa pun yang perlu menyesuaikan templat untuk apa pun selain opsi yang disediakan.

@shaheedmalik , dan ide yang luar biasa dan intuitif. Sudah cek speknya? Kami memiliki acara ValueChanged yang akan memungkinkan Anda untuk mencegat input itu dan secara manual mengurai angka yang diketik menjadi nilai numerik - sehingga akan menjadi pengalaman yang mungkin untuk dibuat, terutama jika Anda memiliki bahasa tertentu dalam pikiran. Adapun untuk memanggang parser bahasa global dalam V1 default dari kontrol - @mdtauk benar, itu akan menambah kompleksitas dan overhead yang akan membutuhkan pembenaran yang signifikan. Manfaat dari open source kontrol ini adalah bahwa mereka dapat bercabang oleh komunitas. Dalam hal ini di sini, Anda atau anggota komunitas lainnya dapat membuat varian khusus bahasa dari kontrol ini. Saya percaya itu akan menjadi jalur paling realistis untuk mendemokratisasi versi penguraian bahasa NumberBox.

@mrlacey, apakah Anda memiliki kesempatan ulasan @robloo 's analisis komparatif NumberBox kontrol yang sama yang digunakan di seluruh Windows ? Perilaku menyetel ulang bidang ini ke input terakhir yang valid dan hanya angka sebenarnya memiliki preseden di seluruh sistem - yang berarti kontrol itu sendiri atau pedoman pengembang akan ditekan untuk menyelaraskan dengan pola ini. Kecenderungan saya adalah menyelaraskan kontrol ini dalam konsistensi dengan pengalaman Windows standar dan menciptakan jalan untuk penyimpangan yang diperlukan sebagai lawan dari menstandarisasi perilaku yang menyimpang dari ekosistem lainnya dan menegaskan pedoman untuk membuat perilaku default sistem ini seperti yang akan dibuat oleh yang terakhir. mudah dan efisiensi untuk kasus umum. Saya mendorong ketidaksepakatan, jadi beri tahu saya jika menurut Anda ini menambah kerumitan yang tidak perlu pada kontrol atau, mungkin, mungkin kita harus mengevaluasi kembali preseden ini?

| Judul | foto | Komentar |
|------|-----|------------|
| Entri Ukuran Font UWP OneNote | | Nilai apa pun dapat dimasukkan dari keyboard, secara otomatis divalidasi dan disetel ulang ke nilai valid terakhir saat kehilangan fokus |
| Entri Ukuran Font Word Desktop | | Nilai apa pun dapat dimasukkan dari keyboard, secara otomatis divalidasi pada kehilangan fokus dan pesan kesalahan muncul jika tidak valid. Pada klik [OK] reset ke nilai valid terakhir. |
| Grafik UWP OneNote 2D | | Nilai apa pun dapat dimasukkan dari keyboard. Nilai yang tidak valid akan diabaikan begitu saja dan input valid terakhir yang digunakan dalam perhitungan (tidak memvalidasi fokus yang hilang). Menekan tombol kenaikan +/- akan bertambah menggunakan input valid terakhir. |
| Entri Ukuran Bentuk Kata Desktop | | Nilai apa pun dapat dimasukkan dari keyboard, secara otomatis divalidasi pada kehilangan fokus dan diatur ulang ke nilai valid terakhir pada kehilangan fokus. |

@mdtauk , perhatikan komentar Anda tentang bahasa LTR dan RTL dan sisi kontrol tempat UpDownButtons muncul. Saya akan menjalankan ini oleh para ahli pelokalan untuk memastikan ini adalah pertimbangan yang perlu diperhitungkan.

@mrlacey Anda juga benar bahwa boolean akan berlebihan untuk enum. Saya akan segera mencoba memverifikasi jika ada konfigurasi alternatif yang diperlukan.

@adrientetar , Anda adalah pelanggan utama kami untuk tombol vertikal. Apakah Anda memiliki cuplikan layar atau konteks yang dapat membantu saya lebih memahami batasan ruang Anda? @mdtauk membuat saya berpikir dengan balasan ini sebelumnya:

Pikiran awal adalah, apakah jumlah dalam wadah akan cukup besar di mana orientasi vertikal diperlukan? AutoCompleteBox tidak memindahkan tombol Cari, dan string biasanya lebih panjang dari angka.

@SavoySchuler (mengenai @robloo , saya ingin membuat lebih banyak kemampuan itu.

Pertimbangkan ini:

1. NumberBox dengan AllowsCalculations=True
2. masukkan 1100 secara manual dan tab ke kontrol berikutnya
3. menyadari ini bukan yang ingin masuk
4. kembali ke kontrol dan masukkan "99 x 12"
5. tab ke kontrol berikutnya dan nilainya kembali ke tampilan "1100" ('x' tidak sama dengan '*' sehingga akan gagal dalam langkah perhitungan. Atau pertimbangkan perhitungan tidak valid lainnya yang gagal jika 'x' tidak' t ditampilkan jika ditekan.)
6. Sekarang menunjukkan nilai yang bukan hasil perhitungan, tidak ada pesan kesalahan yang ditampilkan, dan jumlah yang dimasukkan hilang sehingga tidak ada catatan tentang apa yang terjadi.

Apa yang saya inginkan terjadi ketika tab ke kontrol berikutnya pada langkah 5 adalah

• "99 x 12" tetap menjadi nilai Text
• Status kesalahan ditampilkan.
• ValueChanged acara dipicu dan diteruskan (Teks='99 x 12', OldValue=1100, NewValue=Double.NaN)
• Pengguna kemudian dapat melihat bahwa ada sesuatu yang salah
• Pengguna dapat memperbaiki masalah tanpa harus memasukkan kembali seluruh jumlah.
• Logika Kode/Aplikasi dapat melakukan sesuatu yang sesuai jika perlu.

Jika akan secara otomatis kembali ke nilai baik terakhir yang diketahui saat masuk:

• Kapan selain saat tidak ada nilai yang dimasukkan pada bidang wajib, apakah status kesalahan akan ditunjukkan?
• Bukankah nilai memiliki acara ValueChanged sangat berkurang karena tidak akan pernah melaporkan keadaan yang tidak valid?

@SavoySchuler @mrlacey Melihat contoh-contoh itu di aplikasi Microsoft lainnya...

Setiap pop-up modal harus dikesampingkan. Sebaliknya ini harus ditangani oleh status validasi pada kontrol itu sendiri.

GAMBAR

Jika ada Nilai yang tidak valid, maka mungkin konten harus tetap dalam status tidak valid itu, tetapi hanya saat kontrol dalam fokus. Jika fokus hilang, nilai Bidang Teks akan kembali, tetapi pemberitahuan validasi menampilkan apa yang telah dimasukkan pengguna?

InputScope: Angka atau FormulaNumber?

Seperti yang disebutkan sebelumnya (dalam komentar PR), FormulaNumber tidak menyertakan 'spasi' yang termasuk dalam semua contoh perhitungan di sini dan dalam spesifikasi. FormulaNumber juga menyertakan simbol matematika yang tidak didukung oleh kontrol ini

Saya memilih 'Nomor'

Nomor

RumusNomor

@SavoySchuler Maksud saya, saya hanya membuat aplikasi desktop (tidak mencoba membuat versi Excel saya sendiri atau apa pun). Saya pikir saya hanya akan menonaktifkan panah sama sekali, seret mouse sudah cukup saya pikir. Jika seret mouse direncanakan maka mungkin perubahan nilai harus diaktifkan pada setiap perubahan, karena pengguna ingin melihat pratinjau berbagai kemungkinan perubahan dalam kasus itu. Bilah samping:

Btw konten TextBox tidak akan terpusat secara vertikal, dan ini dengan VerticalContentAlignment="Center".

Itu terlihat mirip dengan jenis bilah sisi properti yang digunakan Paint 3D (yang juga menggunakan gaya kontrolnya sendiri dengan batas yang lebih tipis, dan yang tampak seperti properti sufiks)

Jika Menyeret tidak diterapkan, maka Anda selalu dapat melakukan apa yang dilakukan Paint 3D, dan memiliki penggeser yang terikat ke NumberBox.

Ini juga mirip dengan apa yang dilakukan Adobe dengan memiliki slider drop-down di kontrol mereka.

@adrientetar Anda tampaknya melakukan NumberBox versi Anda sendiri di sana. Teks di TextBox Anda akan memiliki perataan garis dasar, karena font akan memiliki turunan yang perlu diperhitungkan.

Untuk NumberBox mungkin ada kasus untuk memiliki karakter yang terpusat secara visual, tetapi NumberBox ini tidak akan sejajar ketika ditempatkan di samping kontrol turunan TextBox atau TextBox standar seperti ComboBox.

Saat membuat Template dan Gaya default, Anda harus mempertimbangkan berbagai properti Windows.UI.Xaml.Documents.Typography ...

• Tipografi.CaseSensitiveForms
• Tipografi.NumeralAlignment + Tipografi.NumeralStyle (Tabular mungkin lebih disukai daripada Proporsional)

@mrlacey , Anda membuat argumen yang valid. Berdasarkan tanggapan dari @adrientetar , bagaimana dengan skenario berikut:

Peristiwa yang diubah Nilai/Teks dipicu pada _setiap_ perubahan (untuk kasus di mana pengguna seret/gulir menguji rentang) dan, oleh karena itu, validasi dapat terjadi terus-menerus di mana pesan kesalahan dan indikator ditampilkan hingga "Enter" ditekan/fokus hilang, di dalam hal ini, nilai validasi yang ditimpa akan muncul dan menimpa nilai baik terakhir (kecuali jika perilaku tersebut dinonaktifkan oleh propertinya masing-masing).

Saya akan mengobrol dengan tim sore ini untuk memvalidasi apakah penembakan/validasi peristiwa yang konstan itu adalah ide yang realistis - jika tidak, kita dapat membangun dalam jangkauan yang membatasi dengan cara lain.

@mdtauk , tapi saya yakin Anda benar dengan pernyataan Anda tentang representasi visual validasi. @LucasHaines , dapatkah Anda memeriksa saya?

@jevansaks , apakah Anda dapat mempertimbangkan pertimbangan InputScope di bawah ini?

Seperti yang disebutkan sebelumnya (dalam komentar PR), FormulaNumber tidak menyertakan 'spasi' yang termasuk dalam semua contoh perhitungan di sini dan dalam spesifikasi. FormulaNumber juga menyertakan simbol matematika yang tidak didukung oleh kontrol ini

Saya memilih 'Nomor'

Nomor

RumusNomor

@SavoySchuler tentang ini

Peristiwa yang diubah Nilai/Teks dipicu pada setiap perubahan (untuk kasus di mana pengguna seret/gulir menguji rentang) dan, oleh karena itu, validasi dapat terjadi terus menerus di mana pesan kesalahan dan indikator ditampilkan hingga "Enter" ditekan/fokus hilang, di dalam hal ini, nilai validasi yang ditimpa akan muncul dan menimpa nilai baik terakhir (kecuali jika perilaku tersebut dinonaktifkan oleh propertinya masing-masing).

ValueChanged acara hanya akan diaktifkan ketika Value berubah, bukan setiap kali Text berubah.

kecuali jika perilaku itu dinonaktifkan oleh propertinya masing-masing

Apa properti baru ini?

Saya tidak tahu seberapa sering peristiwa mengatasi masalah nilai yang salah dan status kesalahan hilang saat kembali ke nilai bagus terakhir yang diketahui.
Saya merasa beberapa eksperimen diperlukan di sini untuk memahami seperti apa sebenarnya ini. (Kalau saja saya bisa menemukan waktu ...)

Pada catatan terkait.

Saya berasumsi bahwa acara TextChanged yang ada yang diwarisi dari TextBox tidak akan dimodifikasi untuk konsumen. Tapi bagaimana dengan acara TextChanging ? Apakah ini akan menjadi tempat pemrosesan khusus kontrol baru dilakukan? Akankah konsumen kontrol dapat menangani acara ini juga?

Setuju - layak dijelajahi tetapi sebaiknya dihindari. Saya telah merevisi bagian Validasi dan menambahkan properti IsInvalidInputOverwritten yang dinonaktifkan secara default. Apa yang semua orang pikirkan tentang hal berikut:

• Input yang bersifat formal non-numerik atau melebihi nilai min/max akan memicu peringatan Validasi Input .
• Pengembang dapat mencegat peristiwa ValueChanged atau TextChanged (yang memperlihatkan properti yang diubah dan yang akan diperbarui) dan memanipulasi input yang tidak valid secara manual sebelum peringatan Validasi Input ditampilkan.
• Mengaktifkan properti IsInvalidInputOverwrite akan mengembalikan input yang tidak valid ke status valid terakhir tanpa menampilkan peringatan Input Validation . Misalnya, jika IsInvalidInputOverwrite diaktifkan, StepSize=0.2, MaxValue=3.0, dan nilai 2.9 bertambah, 3.1 akan terdaftar sebagai tidak valid dan akan ditimpa kembali ke 2.9.

Banyak dari ini dapat diringkas dengan pertanyaan apakah validasi harus terjadi selama input atau setelahnya. Saya bersandar demi kinerja dan karena pengalaman menerima validasi saat Anda mengetik dapat menggelegar dan tidak dapat diakses dengan baik - yang menjadikan hal di atas sebagai implementasi pilihan saya saat ini.

FWIW, Adobe Photoshop, dan Illustrator kembali ke nilai sebelumnya saat Anda mencoba memasukkan nilai yang tidak valid. Ini memiliki perilaku perhitungan, tetapi akhiran unit pengukuran adalah bagian dari teks, yang dengan sendirinya dapat menyebabkan masalah validasi :)

Ingin melontarkan ide yang membuat saya berkonflik dengan diri saya sendiri - saya dapat mengingat dalam banyak pengalaman masa lalu di mana saya memiliki semacam kotak nomor dengan fungsionalitas kenaikan/penurunan, turun di bawah nilai minimum akan membungkus saya kembali ke nilai teratas, dan sebaliknya. Saya ingin melihat apakah sesuatu seperti properti _ValuesWrap_ masuk akal di sini.

Ini jelas tidak masuk akal dalam setiap kasus, tetapi dalam kasus rentang numerik terbatas, sudah intuitif bagi saya di masa lalu untuk mengasumsikan angka dibungkus dalam kasus seperti pada entri Age atau DateOfBirth atau untuk kasus rentang kecil lainnya. Di sisi lain, ini kadang-kadang hanya terjadi karena dalam kasus ini kotak pilihan pilihan ganda digunakan, dan itu biasanya membungkus nilai alih-alih berhenti. Hanya ingin memeriksa apakah ada pembenaran atau kebutuhan untuk itu - itu tentu saja mungkin dapat diimplementasikan di pihak pengembang juga melalui acara onValueChanged apa pun dengan kerja ekstra.

cc @SavoySchuler

Ide yang luar biasa, @KevinTXY. Jika salah satu pengembang kami di sini membutuhkan sesuatu seperti itu, kami dapat melihat untuk menambahkannya!

Waktu pertanyaan: Apakah ada yang punya skenario aplikasi nyata yang membenarkan memerlukan dukungan untuk heksadesimal atau biner? Membungkus nilai maks/min?

Saya ingin melihat apakah sesuatu seperti properti ValuesWrap masuk akal di sini.

ya, jika Anda memiliki properti sudut yang ingin Anda gunakan 359 → 0, pada dasarnya mod 360. Yang menyenangkan adalah saya masih harus mensubklasifikasikan kontrol (berada di Qt) karena MaxValue hanya bisa inklusif, jadi saya bisa menentukan 359 atau 360, tetapi saya sangat ingin dapat menulis 359,99 tetapi tidak 360 (yaitu saya ingin <, bukan ).

QSpinBox memang memiliki properti pembungkus untuk tujuan itu https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler Sehubungan dengan heksadesimal, saya menduga editor hex menginginkan itu tetapi sepertinya kasus penggunaan yang sangat khusus, Anda tidak harus mendukung setiap hal yang mungkin, pastikan kontrolnya mudah untuk disubkelaskan. Di Qt, kontrol memiliki metode yang mengubah dari string kotak teks ke nilai numerik (baik int atau double) yang dapat ditimpa.

Misalnya, jika IsInvalidInputOverwrite diaktifkan, StepSize=0.2, MaxValue=3.0, dan nilai 2.9 bertambah, 3.1 akan terdaftar sebagai tidak valid dan akan ditimpa kembali ke 2.9.

Anda mungkin bisa menjepit ke MaxValue dalam kasus itu.

@SavoySchler @xyzzer @mrlacey Saya melihat di twitter bahwa ada sesuatu yang datang di 20H1 yang menyediakan input teks prediktif.

Ini dapat mengganggu fitur penyelesaian Pratinjau yang kita bicarakan, dan mungkin perlu sesuatu yang ditekan dalam kontrol NumberBox. Datang ke kontrol Win32 dan XAML sepertinya ...

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

Saya akan berasumsi bahwa menangani hex atau biner adalah skenario yang bahkan lebih khusus daripada menangani "string yang terlihat seperti angka" seperti nomor telepon dan kode pos. (dan membawa kompleksitas mereka sendiri)
Karena itu saya pikir mereka harus berada di luar cakupan kontrol NumberBox.

Berbicara tentang fitur perhitungan pratinjau, jika terlewatkan, saya akan mengusulkan untuk memberi pengguna pilihan untuk mengaktifkan/menonaktifkannya. Jadi mungkin menambahkan properti seperti

public bool ShowPreviewResult { get; set; }

Mengapa Anda menampilkan hasil pratinjau? Tidak seperti pengguna akan mengubah apa rumus mereka tergantung pada hasilnya, jika mereka tahu hasil yang mereka inginkan, mereka akan langsung mengetiknya

Mengapa Anda menampilkan hasil pratinjau? Tidak seperti pengguna akan apa yang mereka ketik tergantung pada hasilnya, jika mereka tahu apa yang mereka inginkan, mereka akan langsung mengetiknya

Salah satu fitur kontrol adalah untuk dapat masuk dalam perhitungan, seperti 32 * 4 yang akan diselesaikan sebagai 128 - fitur pratinjau akan menunjukkan apa hasilnya ketika kontrol kehilangan fokus atau Enter ditekan.

@adrientetar Pratinjau adalah fitur sementara sampai sekarang. Saya percaya nilainya akan sebagian dalam validasi berorientasi pengguna sebelum validasi kontrol dimulai, misalnya, itu hanya menunjukkan jika apa yang dimasukkan dapat dihitung/dalam batas; misalnya, memverifikasi ekspektasi ("Apakah saya menekan waktu alih-alih plus?"). Ada bunga dan pengembalian investasi di sini belum jelas.

Terima kasih atas umpan baliknya lagi, semuanya! Sepertinya tidak ada kebutuhan mendesak atau minat yang menjamin dalam dukungan biner atau heksadesimal untuk saat ini. Itu juga dapat disubklasifikasikan, diusulkan sebagai kontrol baru, atau diusulkan untuk V2 sesuai kebutuhan.

@SavoySchuler sehubungan dengan "Apakah ada yang punya skenario aplikasi nyata yang membenarkan memerlukan dukungan untuk heksadesimal atau biner?", Salah satu contohnya adalah kontrol ColorPicker WinUI sendiri. Ini termasuk kotak input heksadesimal. Ini juga mencakup sejumlah Kotak Teks entri nomor lainnya. Mungkin ada baiknya melihat kemungkinan memperbarui ColorPicker untuk menggunakan kontrol NumberBox baru sebagai cara memvalidasi kontrol baru. Jika NumberBox dapat menyederhanakan implementasi ColorPicker saat ini, itu akan menjadi kemenangan.

Jika penataan batas yang lebih tipis untuk Kotak Teks tidak melewati @chigy dan pengambilan keputusan tim desain WinUI - saya pikir saya harus menyiapkan tiruan desain yang cocok dengan proposal saat ini untuk desain Kotak Teks.

@kmahone - setuju. Seperti yang Anda sebutkan di pendingin air pagi ini, dapat menghapus banyak kode di belakang dari ColorPicker dengan mengganti instance TextBox + logika validasi lokal dengan NumberBox bisa menjadi kemenangan tersendiri.

@mdtauk -

@SavoySchuler Jika tim Desain Windows memutuskan untuk berpihak pada tim Fabric Web, dan berpindah dari batas tebal 2 epx, ke batas 1epx - saya pikir itu akan bekerja paling baik dengan NumberBox - tetapi karena praktis, tim Desain Windows dapat menggali tumit mereka dan pertahankan batas yang lebih tebal.

Tentu saja, @mdtauk! Saya berharap untuk mengunci persyaratan fungsional untuk @KevinTXY di sini dalam waktu dekat dan saya akan beralih ke percakapan konvergensi desain dengan @chigy (yang telah sibuk melakukan pekerjaan luar biasa di #524) lalu!

Terima kasih untuk semua diskusi semuanya, saya senang bisa mengerjakan fitur ini musim panas ini sebagai pekerja magang!

Jika relevan bagi siapa saja, saya telah memulai prototipe kontrol C# di repositori berikut.
https://github.com/KevinTXY/NumberBox

Ini pada dasarnya adalah pertama kalinya saya belajar C#/UWP sehingga akan berjalan lambat dan jika ada yang melihatnya, saya senang mendapatkan umpan balik tentang apa yang bisa dilakukan dengan lebih baik!

Fitur-fitur berikut secara kasar diterapkan:

• Validasi input numerik (belum mengikuti spesifikasi proposal validasi , akan menunggu kode untuk itu)
• Penyimpanan/pengikatan nilai
• Pemangkasan nol
• Dukungan penuh Kalkulator/formula entri

Saat ini sedang mengerjakan tombol pemintal dan menguji hal-hal aplikasi serta Validasi Min/Maks.

Bersulang!

Pembaruan Garis Waktu!

Saya telah mengintegrasikan beberapa pembaruan, saran, dan masukan ke dalam spesifikasi yang akan saya validasi dengan tim WinUI hari ini (Kamis). Saya berharap untuk lebih atau kurang menyelesaikan API dan Komponen Perilaku untuk V1 dalam melakukannya.

Sekarang, saya akan pindah ke Input dan Aksesibilitas, Data & Intelijen, dan Komponen Visual.

Langkah terakhir adalah merapikan dokumentasi dan membentuk pedoman.

Saya pikir opsi yang terputus-putus dan bersebelahan sangat khusus tanpa kasus penggunaan yang harus dilakukan oleh aplikasi pihak pertama / UI shell Microsoft baik di WPF atau Win32.

Jika Anda ingin memasukkannya, saya lebih suka itu menjadi Gaya yang disertakan yang dapat Anda terapkan ke kontrol, daripada opsi. Bagaimana kontrol NumberBox yang ditempa ulang menangani properti itu, di templat baru mereka?

Jika konsensusnya adalah bahwa mode ini harus dimasukkan, mungkin saya menyarankannya menjadi nilai enum sebagai bagian dari SpinButtonPlacementMode . Tidak yakin apa nama opsi ini. _Straddled_ mungkin tidak cukup profesional lol, dan saya tidak yakin _Bookended_ lebih baik.

Saya baru saja melihat versi terbaru Canary dari Edge, dan melihat desain <input type="number"/> yang paling dekat dengan kontrol NumberBox.

Hanya berpikir saya akan membagikan gambar ini.

@mdtauk - setuju, SpinButtonPlacementMode akan menjadi tempat yang tepat untuk menambahkan opsi penempatan SpinButton alternatif.

Pada topik nama, @Felix-Dev dengan tepat muncul pada spesifikasi bahwa SpinButton mungkin bukan nama yang paling intuitif atau terkenal. SpinBox dan UpDownButtons juga memiliki prioritas di ekosistem Windows. Saya akan membahas ini lebih cepat, tetapi beri tahu saya jika ada yang memiliki alasan untuk menentang salah satu opsi ini.

@mdtauk - Terima kasih telah berbagi! Saya juga menjalankan Canary, jadi saya akan melihat dan melihat apakah ada yang bisa kita pelajari atau apakah ada ruang untuk menyarankan menyelaraskan perkembangan!

@SavoySchuler Saya menggunakan bendera Kontrol Lancar Diaktifkan (termasuk kontrol eksperimental)

Saya pikir implementasi WinUI akan menjadi desain yang lebih matang yang harus dilihat oleh Fabric Web dan Edge, tetapi penyelarasan adalah hal yang baik untuk dilakukan.

Nomor Jenis Masukan w3schools

Juga penggeser itu dekat, tetapi tidak persis sama dengan apa yang direncanakan WinUI (diuraikan ibu jari lingkaran, dibandingkan dengan ibu jari lingkaran yang diisi)

Saya masih tidak yakin bagaimana cara mengatur fitur Lokalisasi. Di AS, Dot digunakan untuk pemisah desimal. Di Belanda (tempat saya tinggal) kami menggunakan koma. Pemisah Pengelompokan di AS adalah Koma tetapi di Belanda itu adalah Dot.

Contoh:

Haruskah saya menggunakan properti Bahasa dari elemen Kerangka untuk menentukan pemisah Digit dan Pengelompokan?

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

Saya baru saja melihat versi terbaru Canary dari Edge, dan melihat desain <input type="number"/> yang paling dekat dengan kontrol NumberBox.

Hanya berpikir saya akan membagikan gambar ini.

@mdtauk , @SavoySchuler ,
Saya tidak tahu dari mana kontrol ini berasal. Menurut kontak saya di tim Edge, berikut adalah kontrol yang akan mereka gunakan.

Penggeser: https://explore.fastdna.net/components/slider/
Kotak nomor: https://explore.fastdna.net/components/number-field/

Saya tidak yakin apakah mereka akan memperbarui visual dan hasil akhirnya mungkin tidak terlihat persis seperti ini (saya kira begitu, tapi itu tebakan liar saya).

@chigy Gambar itu berasal dari Canary build of Edge saat ini, tetapi seperti yang saya catat, ini adalah WIP dan merupakan flag opsional yang Anda aktifkan.

Saya kira itu menjelaskan untuk apa proyek fastdna itu, yang saya bahas di edisi sebelumnya. 🙂

Haruskah saya menggunakan properti Bahasa dari elemen Kerangka untuk menentukan pemisah Digit dan Pengelompokan?

Pengaturan tersebut biasanya berasal dari "wilayah", jadi saya pikir kita hanya akan meneruskan HomeGeographicRegion ke konstruktor DecimalFormatter. Saya tidak melihat tempat lain di API tempat kami mengizinkan pengguna untuk menyesuaikan wilayah (pemformat tanggal/waktu kami tampaknya tidak dapat disesuaikan?), tetapi pemilih mengizinkan untuk menyesuaikan string format jadi mungkin kami dapat mengizinkan bahwa di sini juga.

Saya tidak melihat cara untuk menyesuaikan karakter pemisah di DecimalFormatter API sehingga harus ditarik dari pengaturan bahasa. 😖

@jevansaks , terima kasih atas wawasannya! Saya akan menandai @sonnemaf untuk memastikan dia melihat balasannya.

@jevansaks dapatkah Anda menulis contoh xaml bagaimana DecimalFormatter untuk NumberBox? Saya ingin mendefinisikannya dalam XAML dan bukan dari codebehind. Memiliki properti DecimalSymbol dan GroupingSymbol juga akan berfungsi untuk saya. Ini mungkin terlalu mudah.

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

Maaf membobol saya baru menemukan topik ini, tapi YA YA YA. Keduanya sering hilang dalam kontrol numerik dan saya dan banyak pengembang lain di github harus membangun solusi untuk itu. Apalagi dengan contoh kalkulator seharusnya tidak hanya memformat angka dalam hex tetapi sepenuhnya mendukung input.

Saat ini saya ingin menyarankan agar Anda membuat awalan heksadesimal dapat disesuaikan. Pada titik tertentu lebih baik tidak memiliki awalan sama sekali dan pada titik lain tidak selalu 0x

dapatkah Anda menulis contoh xaml bagaimana DecimalFormatter untuk NumberBox? Saya ingin mendefinisikannya dalam XAML dan bukan dari codebehind. Memiliki properti DecimalSymbol dan GroupingSymbol juga akan berfungsi untuk saya. Ini mungkin terlalu mudah.

@sonnemaf yang harus kita kerjakan di WinRT adalah DecimalFormatter dan sayangnya itu tidak memungkinkan Anda untuk menyesuaikan pengaturan itu. Satu-satunya cara untuk menyesuaikan simbol desimal atau simbol pengelompokan adalah melalui pengaturan pengguna di panel kontrol wilayah OS (sejauh yang saya tahu).

Menghormati wilayah pengguna untuk pengaturan itu tampaknya benar -- apakah Anda memiliki skenario di mana Anda perlu menimpanya?

@sonnemaf

Adakah yang punya skenario aplikasi nyata yang membenarkan memerlukan dukungan untuk heksadesimal atau biner?

Maaf saya memperhatikan ini dan membalas sedikit terlambat. Saya percaya dukungan hex/biner akan sangat membantu. Saya sangat terlibat dengan proyek .NET IoT dan kami sebagian besar bekerja di dunia hex/biner karena kami memanipulasi bit/byte yang membaca/menulis ke register dan pin untuk mengontrol berbagai hal.

Mendukung hex/binary akan sangat menghargai. Terima kasih

Saya tidak perlu hex atau biner. Ini akan menjadi 'menyenangkan untuk dimiliki', terutama biner.

Pembaruan Pengembang

Halo semuanya! Kami menjadi puas dengan spesifikasi NumberBox, dan saya hanya ingin memberi perhatian bahwa saya secara aktif mengerjakan kontrol , idealnya PR pertama dengan fungsi terpenting akan dibuat segera, mungkin malam ini.

Beberapa catatan:

• Kami memilih untuk tidak mensubklasifikasikan TextBox terutama karena beberapa komplikasi desain dengan InputValidation, NumberBox akan menjadi kontrolnya sendiri yang berisi TextBox.
  
  
  
  • Ini berarti bahwa semua properti TextBox tidak akan diekspos. Saya ingin tahu apakah ada yang penting untuk dibawa ke NumberBox - saya bisa melihat keinginan untuk _Header, PlaceHolderText_, dan mungkin juga _Text_? Pasti ingin membuka yang ini sedikit karena ini adalah perubahan yang sangat mudah dilakukan di pihak saya.
  
  
• Saya telah melakukan pengeditan yang sangat kecil pada spesifikasi, ini sebagian besar hanya koreksi kata-kata untuk saat ini, tetapi masih ada pertanyaan terbuka seperti pratinjau nilai, dan saat saya menulis kontrol, saya menghasilkan beberapa pertanyaan desain saya sendiri. Ini masih waktu yang tepat untuk menambahkan masukan

@KevinTXY Ada satu saran untuk diturunkan dari basis Slider daripada TextBox - apakah ini yang telah dipilih?

• PlaceHolderTeks
• tajuk
• Teks
• Ikon Validasi
• Pesan Validasi
• Pilihan Latar Depan
• Latar Belakang Pilihan
• Fokus Negara/Sumber Daya, dll

Ini adalah beberapa hal TextBox yang menurut saya diperlukan. Tidak yakin tentang tombol "hapus teks", yang lebih masuk akal dengan string teks yang panjang.

Pratinjau nilai Saya pikir adalah fitur V2, tetapi apakah ini berubah? Kontrol Slider memiliki tooltip yang menunjukkan nilai, saat ibu jari digeser. Saya menyarankan ini sebagai salah satu cara untuk menanganinya, serta menggunakan pesan validasi untuk menangani ini, atau menampilkannya sebaris.

Inline memiliki masalah dengan fakta bahwa Windows Insider membangun bereksperimen dengan penyelesaian teks prediktif, baik muncul sebagai tooltip, atau di dalam bidang teks. Metode pratinjau apa pun yang dipilih, tidak boleh bertentangan dengan metode tersebut, atau fitur prediktif dinonaktifkan untuk kontrol ini.

@KevinTXY Ada satu saran untuk diturunkan dari basis Slider daripada TextBox - apakah ini yang telah dipilih?

NumberBox saat ini adalah kontrolnya sendiri (memperluas Windows.UI.Xaml.Controls.Control) yang berisi TextBox di dalam markupnya daripada memperluas TextBox. Slider terdengar menarik tetapi saya pikir itu akan menyebabkan implementasinya menjadi sedikit kacau, ada juga banyak properti dalam kontrol ini yang kami rasa tidak termasuk dalam NumberBox. Saya bukan seorang PM tetapi dari pengalaman saya mengembangkan ini, saya merasa bahwa ini adalah rute yang baik untuk menyederhanakan pengembangan dan untuk diperpanjang di masa depan.

Ini adalah beberapa hal TextBox yang menurut saya diperlukan. Tidak yakin tentang tombol "hapus teks", yang lebih masuk akal dengan string teks yang panjang.

Ini luar biasa - persis apa yang saya cari! Saya setuju ada nilai dalam semua ini. Tombol Hapus Semua saat ini ada karena merupakan fitur default dari TextBox - saya kira itu memiliki nilai untuk entri besar atau pengguna layar sentuh meskipun saya belum benar-benar berpikir untuk menonaktifkannya. Saya pasti setidaknya akan mencoba memasukkan tiga yang saya sebutkan (Header, PlaceholderText, Text) ke dalam pratinjau.

Adapun pratinjau nilai, tidak ada yang diselesaikan di sana dan hanya dalam spesifikasi sebagai pertanyaan terbuka. Saya kira solusi sementara yang paling mudah adalah dengan hanya mengekspos nilai pratinjau untuk ditampilkan oleh pengembang sesuai keinginan - yang dapat dengan mudah dalam cakupan untuk versi pratinjau tetapi saya akan menyerahkannya kepada @SavoySchuler & Co. untuk melakukan panggilan. Perhitungan mungkin bahkan tidak akan memotong PR saya setidaknya selama beberapa hari ketika saya sedang meneliti mesin matematika jadi itu bukan detail yang mendesak. Saya menghargai penelitian yang dilakukan, ada banyak ide menarik di sini!

@KevinTXY Idealnya akan ada kolaborasi dengan tim Kalkulator, untuk membuat mesin kalkulasi dasar yang dapat disematkan - serta untuk penggunaan di masa mendatang dengan ide CalculatorPicker yang dibahas bersama kontrol ini. (Kontrol dengan Tombol Kalkulator, yang menampilkan flyout dengan kalkulator standar)

Sebenarnya, kolaborasi dengan pengelola Kalkulator terdengar seperti ide yang bagus. Anda dapat mengekspos layanan aplikasi dari Kalkulator yang akan melakukan perhitungan matematika, sehingga Anda bahkan tidak perlu memuat biner WinUI - cukup bicara dengan layanan aplikasi jika aplikasi diinstal dan sebaliknya - gagal secara diam-diam.

Adapun turunan dari Slider - Saya benar-benar mengatakan RangeBase dan saya masih cukup yakin itu hal yang benar untuk dilakukan karena kontrol pada dasarnya menyediakan hampir semua properti dan fitur aksesibilitas yang Anda perlukan dan turunan darinya akan memberikan permukaan API yang konsisten di antara kontrol Anda dan Slider membuatnya menjadi penggantian swap-in yang mudah.

Ah ya, RangeBase, itu dia.

Kalkulator baru-baru ini melakukan pekerjaan untuk mendukung mode CompactOverlay yang selalu ada di atas - jadi memasukkan keypad yang lebih kecil ke flyout yang ukurannya mirip dengan CalendarFlyout - lebih bisa dicapai. (Jika kontrol CalculatorBox disetujui untuk dimasukkan.

Tidak yakin apakah ini layanan aplikasi (yang akan menautkan pembaruan WinUI semi-bergantung pada pembaruan toko Kalkulator - atau apakah itu biner layanan yang dapat ditambahkan ke WinUI dan diturunkan dari mesin Kalkulator.

Pembaruan: Kode PR sekarang ada !

Saya melacak beberapa masalah di sana, meskipun sebagian besar tidak terkait dengan desain.

Terima kasih, @xyzzer dan @mdtauk! Kami telah memeriksa RangeBase dan tampaknya membawa bagasi yang sama banyaknya dengan subkelas TextBox. Sampai sekarang, kami akan tetap menggunakan TextBox di kontrol dan menambahkan hanya properti yang diperlukan dan fitur aksesibilitas. Ini masih merupakan pertimbangan yang berharga dan membantu menginformasikan percakapan aksesibilitas kami yang terjadi sekarang.

@mdtauk , terima kasih untuk daftar awal! @KevinTXY telah mulai mengekspos API yang Anda daftarkan dan saya akan segera meninjau sisanya.

Pratinjau dan kalkulator pop-up, seperti yang disebutkan @KevinTXY , dalam pembicaraan (meskipun tidak ada jaminan v1 di sini). Kami secara aktif mengobrol dengan Kalkulator tentang penyelarasan dan pekerjaan yang dapat dimanfaatkan. Kalian luar biasa! Terima kasih telah terus mendorong inovasi pada kontrol ini. Itu mengagumkan. @KevinTXY memiliki Kode PR-nya diposting di atas. Saya akan mengikat semua ujung longgar yang tersisa pada spesifikasi sesaat sebelum beralih ke penyusunan Panduan & Dokumentasi.

Penamaan

Ada begitu banyak komentar yang didapat dari spesifikasi saya, jadi saya baru mulai melihat setelah semuanya beres. Pertama, saya melihat beberapa penamaan yang tidak benar-benar mengikuti konvensi C# -- ya saya tahu kontrol ini ditulis dalam C++ tapi saya masih berpikir itu tidak konsisten dengan penamaan lain di platform.

| Ketik | Nama Saat Ini | Nama yang Diusulkan |
|-------|----------------|-------------------|
| Boolean | MenerimaPerhitungan | IsCalculationDiterima |
| Boolean | HyperDragEnabled | IsHyperDragEnabled |
| Boolean | HyperScrollEnabled | IsHyperScrollEnabled |

LangkahFrekuensi

Juga, apa itu StepFrequency? Ini tidak ditentukan dalam spesifikasi dan saya tidak memiliki pengalaman dengan "NumericUpDown XAML Toolkit". Tergantung pada fungsinya, menambahkan kata Frekuensi mungkin tidak masuk akal. Ini mungkin hanya "Langkah"? Dalam kontrol Slider, TickFrequency masuk akal karena kutu ditampilkan pada modulus rentang maks-min keseluruhan. Namun, dalam kontrol ini saya pikir ini hanya ukuran kenaikan/langkah minimum. Pada dasarnya, apakah pengguna dapat memasukkan nilai yang berada di luar langkah?

Misalnya MinValue = 0, MaxValue = 6, StepFrequency = 2. Menggunakan nilai panah atas akan menjadi {2, 4, 6} cukup adil. Bisakah pengguna mengetik 0,5 sebagai nilai yang valid? Atau apakah itu akan dibulatkan menjadi 0 atau 2 tergantung pada RoundingMode?

Nilai Min/Maks

Untuk dua properti di bawah ini, saya pikir ini seharusnya Minimum dan Maksimum seperti pada kontrol lain (Slider, RangeBase). API harus konsisten.
Nilai Min Ganda;
Nilai Maks Ganda;

Tombol Ulangi Naik Turun

Fitur lain yang belum dibahas sejauh yang saya ketahui adalah apakah akan membuat tombol atas/bawah benar-benar RepeatButtons (saya pikir seharusnya begitu). Jika itu adalah tombol berulang, properti Delay/Interval harus ditambahkan seperti kontrol Slider: Slider.Interval Slider.Delay

Digit

Bisakah Anda menambahkan deskripsi untuk apa yang diwakili oleh IntegerDigits dan FractionDigits? Dugaan saya adalah mereka membatasi jumlah digit untuk setiap bagian nomor. IntegerDigits = 2 berarti nilai maks bisa 99. FractionDigits = 3 berarti MaxValue bisa 0,999. Juga, bagaimana SignificantDigits menimpa kedua properti ini?

Nol Negatif?

Mengapa properti ini dibutuhkan? Apakah itu masalah lokalisasi itu sendiri? Saya belum pernah melihat "-0.0" atau "-0". Itu selalu hanya "0".
Boolean IsZeroDitandatangani;

Lokalisasi

Saya bersikeras saya memerlukan kontrol ini untuk mendukung penggantian pelokalan UI dan format angka. Saya memiliki banyak kegunaan (aplikasi keuangan) di mana saya membutuhkan jumlah lokal dan asing yang harus ditampilkan secara berbeda. Saya tidak melihat ini di mana pun dalam spesifikasi.

Konversi dari ganda ke teks harus disesuaikan melalui ValueConverter, dalam semangat Slider.ThumbToolTipValueConverter. Dengan cara itu bagian yang paling kompleks dapat disesuaikan untuk kebutuhan apa pun, seperti dalam beberapa contoh dunia nyata di bawah ini:

Perhatikan, bahwa pemisah desimal untuk angka dan uang bisa berbeda, serta penunjukan jumlah negatif, jadi mungkin pendekatan teraman untuk NumericBox tanpa ValueConverter adalah beroperasi dalam mode bilangan bulat. Kalkulator dapat diimplementasikan sebagai ValueConverter juga, tidak perlu membebani kontrol dengan pekerjaan ini.

@eugenegff Anda memiliki ide yang sangat bagus untuk membuat konversi nomor ke string menjadi generik. Ini akan memungkinkan saya menangani pelokalan tetapi juga memungkinkan pengembang untuk melakukan apa pun yang mereka inginkan seperti menambahkan unit.

Satu-satunya kerumitan yang saya lihat adalah menjaga Culture/NumberFormatInfo terkait dengan kontrol. Saya kira ini bisa menjadi parameter konverter di XAML yang menuju ke IValueConverter khusus tetapi mungkin harus ada cara yang lebih bersih untuk menangani ini di kontrol itu sendiri.

Mengapa properti ini dibutuhkan? Apakah itu masalah lokalisasi itu sendiri? Saya belum pernah melihat "-0.0" atau "-0". Itu selalu hanya "0".

Ini adalah properti dari kelas DecimalFormatter di windows. Apakah itu aneh? Mungkin. Ada beberapa properti seperti IsGrouped dan properti lokalisasi yang kami tinggalkan jadi mungkin yang ini juga tidak diperlukan. Pada saat yang sama itu juga sudah diimplementasikan sehingga menghapusnya tidak memiliki tujuan selain membuka 3 baris kode. Cukup menarik ada penggunaan dan IEEE prasyarat untuk memiliki nol ditandatangani .

Saya bersikeras saya memerlukan kontrol ini untuk mendukung penggantian pelokalan UI dan format angka. Saya memiliki banyak kegunaan (aplikasi keuangan) di mana saya membutuhkan jumlah lokal dan asing yang harus ditampilkan secara berbeda. Saya tidak melihat ini di mana pun dalam spesifikasi.

@SavoySchuler mungkin kita harus melihat ke dalam mendukung pengaturan Bahasa di kelas DecimalFormatter? Saya tidak terbiasa dengan bagaimana perilakunya.

Ok, saya pikir saya mengerti masalah mendasar di sini. Di dunia C++ Anda memiliki akses ke DecimalFormatter tetapi di dunia C# (jika saya menggunakan WinUI) saya biasanya menggunakan IFormatProvider (NumberFormatInfo dari Budaya tertentu). NumberFormatInfo sudah memiliki sebagian besar properti (tidak ada IsZeroSigned secara kebetulan) jadi saya berpikir hanya mengizinkan devs untuk menentukan itu atau IFormatProvider. Nah, ada masalah, C++ tidak dapat menggunakan IFormatProvider karena berasal dari dunia .net.

Jadi bagaimana kontrol ini sepenuhnya mendukung pelokalan di C# dan C++ mengingat mereka memiliki dua cara berbeda untuk melakukannya? Nah, kecuali Microsoft memiliki solusi cerdas, saya hanya dapat memikirkan dua kemungkinan:

1. Tambahkan sepenuhnya semua properti untuk pemformatan angka (secara efektif menerapkan kembali NumberFormatInfo dan DecimalFormatter). Menambahkan hanya IsZeroSigned, IntegerDigits, FractionalDigits, dll. tidak akan menutupinya. NumberNegativePattern, NumberGroupSeparator, NumberGroupSizes, dll. juga diperlukan.
2. Lakukan seperti yang disarankan @eugenegff dan izinkan pengembang menimpa pemformatan dengan semacam panggilan balik. Sejujurnya, ini sepertinya pendekatan termudah.

Saya agak khawatir dengan bagaimana lokalisasi terbentuk dalam kontrol ini. Saya telah membahas pelokalan sejak awal (komentar ke-3 tentang topik ini!). Harus ada beberapa cara untuk sepenuhnya menyesuaikan format angka saat kontrol dikonversi ke string. Tanpa itu, kontrol ini akan sangat terbatas dalam penggunaan di dunia nyata.

Jadi bagaimana kontrol ini sepenuhnya mendukung pelokalan di C# dan C++ mengingat mereka memiliki dua cara berbeda untuk melakukannya?

Kami mendengarmu! Ini adalah sesuatu yang telah kami selidiki secara offline tetapi pada dasarnya .NET melakukan pelokalannya sendiri secara terpisah dari platform. Saya pikir panggilan balik untuk menimpa adalah jalan keluar yang bagus, tetapi saya berharap opsi Anda 1 adalah rute yang bisa kita tempuh. Saat ini API WinRT untuk memformat dan mengurai tidak memiliki semua tombol penyesuaian yang kita butuhkan. Kami masih menyelidiki.

Belum memeriksa apakah ini sudah dibahas, tetapi ingin segera bertanya apakah ada yang melihat kebutuhan besar atau yang lebih penting preseden apa pun untuk dukungan fungsi untuk perhitungan, yang berarti salah satu di bawah ini atau lebih:
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

Saya menyatukan pengurai matematika agar sesuai dengan kebutuhan dan fungsi kami mempersulit proses konversi ke RPN (yang mengatakan saya sudah memiliki versi yang mendukung ini dengan beberapa bug), jadi saya tertarik untuk melihat apakah ada yang layak masalah atau jika tampak seperti kembung. Saya pribadi tidak berpikir itu terlalu cocok tetapi jika ada banyak preseden itu tidak terlalu merepotkan.

Saya pikir ini tidak akan terlalu mudah ditemukan dalam banyak kasus dan jika ada yang membutuhkan dukungan untuk fungsi yang lebih rumit - lebih baik bekerja untuk membuka parsing ke acara panggilan balik yang memungkinkan pengguna untuk mengimplementasikan logika parsing atau prapemrosesan mereka sendiri.

Apa yang akan lebih berharga adalah mengizinkan untuk mulai mengetik teks dengan operator, jadi jika Anda mengklik teks - itu akan memilih semua secara default dan Anda dapat mengetikkan nilai baru tanpa harus menekan hapus terlebih dahulu untuk menghapus yang sebelumnya atau cukup ketikkan sesuatu seperti "*1.2" atau "x1.2" [Enter] dan minta nilai saat ini dikalikan dengan 1,2 meskipun teks yang dimasukkan tidak berisi nilai yang dimasukkan lagi. Hal yang sama akan bekerja untuk "+2", "-5", "/3", "%120", dll.

Ini digunakan dalam beberapa aplikasi profesional.

Kami (Perangkat Lunak BeLight, proyek Live Home 3D) membutuhkan ValueConverter yang dapat dicolokkan untuk konversi teks nilai <=>, jika tidak, NumberBox tidak cocok untuk kami.

Saya pikir penggunaan fungsi-fungsi itu akan sangat jarang, saya memiliki input sudut di aplikasi saya tetapi itu hanya nilai derajat. Kegunaan yang paling penting bagi saya adalah untuk dapat menambah nilai yang ada atau membagi yang ada dengan angka, hanya untuk menghemat waktu dan menghindari untuk melakukan perhitungan itu secara mental. (Btw saya pikir itulah yang dimiliki aplikasi Adobe, 4 operator aritmatika: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -bidang)

Juga berfungsi seperti cos() Anda mungkin tidak menginginkannya di tempat yang tidak masuk akal, kecuali jika Anda membuat semacam aplikasi Excel.

Kegunaan yang paling penting bagi saya adalah untuk dapat menambah nilai yang ada atau membagi yang ada dengan angka, hanya untuk menghemat waktu dan menghindari untuk melakukan perhitungan itu secara mental

OK bagus! Kedengarannya mirip dengan apa yang diusulkan @xyzzer . Saya akan melihat implementasi serupa dan melihat apakah ada ruang untuk melakukan ini dengan cara yang terasa alami dan intuitif.

Kami (Perangkat Lunak BeLight, proyek Live Home 3D) membutuhkan ValueConverter yang dapat dicolokkan untuk konversi teks nilai <=>, jika tidak, NumberBox tidak cocok untuk kami.

Saya melihat contoh Slider yang Anda berikan dan kedengarannya sangat masuk akal - saya bisa melihat nilai dalam IValueConverter untuk NumBox. Saya akan segera memeriksanya dan kami akan mencoba memutuskan apakah itu cocok dengan spesifikasinya. Belum ada janji untuk apa pun!

@KevinTXY Saya menduga bahwa menambahkan fungsi yang Anda sebutkan di atas akan membuka pintu ke lebih banyak masalah daripada nilai yang mungkin diberikannya. Ini karena akan memungkinkan pengetikan karakter dalam jumlah yang lebih banyak (pada dasarnya huruf apa saja) ke dalam kontrol. Pada gilirannya ini akan memudahkan untuk secara tidak sengaja mengetik sesuatu yang tidak valid dan juga akan menambah kompleksitas validasi dan penguraian.
Itu juga akan mematahkan baris pertama deskripsi di awal spesifikasi "Kotak angka adalah kontrol teks numerik saja ...".

Saya heran masih ada pertanyaan tentang lokalisasi. Karena kontrol akan (harus?) mewarisi dari FrameworkElement ia akan memiliki akses ke properti Bahasa dan, seperti setiap FrameworkElement lainnya, mendukung pengaturan lokal secara langsung dan tidak bergantung pada pengaturan UI lokal sistem.
Ini berarti bahwa hal-hal seperti desimal dan karakter pengelompokan dapat diatur pada basis per-instance.

Saya heran masih ada pertanyaan tentang lokalisasi.

Masalahnya adalah bahwa Bahasa bukanlah hal yang mengontrol pemformatan, melainkan pengaturan wilayah/budaya. Pelokalan adalah tentang memperbarui string UI agar ditampilkan dalam bahasa yang benar sedangkan pemformatan angka/mata uang/waktu dikendalikan oleh wilayah. Info lebih lanjut di sini: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Dan untuk memperumit masalah Windows memungkinkan Anda untuk menyesuaikan pengaturan lokal Anda di UI dengan mengesampingkan default -- sehingga Anda dapat mengatakan bahwa Anda ingin pemisah desimal Anda menjadi karakter acak apa pun alih-alih default. Dan di atas itu, .NET memungkinkan aplikasi untuk menyesuaikannya juga sehingga pengembang mengharapkan tingkat penyesuaian itu di sini.

Masalahnya adalah bahwa Bahasa bukanlah hal yang mengontrol pemformatan, melainkan pengaturan wilayah/budaya. Pelokalan adalah tentang memperbarui string UI agar ditampilkan dalam bahasa yang benar sedangkan pemformatan angka/mata uang/waktu dikendalikan oleh wilayah. Info lebih lanjut di sini: https://docs.microsoft.com/en-us/globalization/locale/locale-and-culture. Dan untuk memperumit masalah Windows memungkinkan Anda untuk menyesuaikan pengaturan lokal Anda di UI dengan mengesampingkan default -- sehingga Anda dapat mengatakan bahwa Anda ingin pemisah desimal Anda menjadi karakter acak apa pun alih-alih default. Dan di atas itu, .NET memungkinkan aplikasi untuk menyesuaikannya juga sehingga pengembang mengharapkan tingkat penyesuaian itu di sini.

Language mengambil nilai yang diterjemahkan ke dalam CultureInfo --perhatikan bahwa budaya disebut lokal dalam pengembangan kode yang tidak dikelola. Ini berisi properti NumberFormat yang merupakan tipe NumberFormatInfo yang berisi properti untuk desimal, pengelompokan, tanda negatif, dan banyak lagi.

Pemahaman saya adalah bahwa jika Anda ingin memaksakan pemformatan tertentu atau spesifik pelokalan lainnya pada kontrol, daripada mengandalkan pengaturan sistem, maka cara melakukannya adalah dengan menentukan Language .

Deskripsi untuk properti dengan jelas menyatakan bahwa itu "menetapkan informasi bahasa pelokalan/globalisasi yang berlaku untuk FrameworkElement"

Atau mungkin saya salah memahami dokumen yang saya rujuk tetapi semuanya tampaknya mendukung apa yang tercakup dalam halaman yang Anda tautkan.
Mungkin ini masalah terminologi dengan C++ dan C# menggunakan istilah yang berbeda.
Yang saya tahu adalah bahwa pengaturan Bahasa di XAML adalah bagaimana saya akan memaksa budaya/lokal di aplikasi lain dan dengan kontrol lainnya.

Pertanyaan yang saya lihat di pelokalan adalah tentang memaksa format angka tertentu, atau pemisah grup dan desimal. Atau apakah masalah sebenarnya, bagaimana mengontrol ini tanpa memengaruhi lokalisasi properti berbasis teks (Header, PlaceholderText, dll.) dari kontrol?

Language mengambil nilai yang diterjemahkan ke dalam CultureInfo

Tidak di asli/WinRT, kami hanya mendapatkan string langs BCP-47. Dan itulah masalahnya. Di .NET Anda menggabungkan CultureInfo yang memiliki pengaturan bahasa dan pengaturan format. Di WinRT itu terpisah dan tidak ada yang setara dengan objek CultureInfo.

Saya mendengar bahwa API ICU dapat mengaktifkan apa yang kami cari, tetapi kami belum memiliki kesempatan untuk menyelidikinya.

Saya pikir Microsoft harus mempertimbangkan untuk menyelesaikan masalah ini dan sepenuhnya menerapkan mekanisme konversi antara .net culture/localization (CultureInfo) dan native/WinRT. Idealnya Anda tidak akan mempertimbangkan cara baru dalam melakukan sesuatu:

Saya pikir kode terkelola adalah apa yang ditulis oleh sebagian besar aplikasi LOB dan ini perlu dilakukan dengan benar sejak awal. WinRT perlu mendapatkan mekanisme/teknik pelokalan yang sama seperti .net dan konversi harus otomatis.

Apakah itu akan lebih banyak pekerjaan? Jangka pendek: ya, jangka panjang: tidak. Apakah itu mungkin menunda rilis kontrol NumberBox? Mungkin, kecuali jika panggilan balik digunakan dalam jangka pendek.

Ini perlu dilakukan dengan benar atau akan ada masalah di tempat lain. Saya sudah dapat melihat beberapa masalah serupa dengan skenario lain seperti CalendarDatePicker yang dapat diedit, dll. (#735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
Rupanya tim FastDNA juga melakukan pekerjaan pada kontrol Spinner mereka untuk desain Bidang Nomor Input mereka, dan mereka datang dengan proposal yang mungkin layak dipertimbangkan.

Mereka juga bertanya mengapa kami menggunakan Chevron, bukan Arrows.

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

Bahkan jika kita menjaga tombol berdampingan, memiliki desain yang diperluas bertumpuk sebagai hover, dapatkah menjadi ide ketika lebar Kontrol terlalu sempit? Mungkin ada beberapa konsensus tentang tata letak yang berfungsi di semua kerangka kerja Microsoft UI?

@mdtauk , terima kasih telah memberi tahu kami.
Memeriksa dengan orang-orang FastDNA jika ini adalah desain yang mereka uji dan validasi kegunaannya.

Kembali ke NumberBox

Baiklah Tim,

Maaf untuk jeda yang tidak terduga. Saya kembali ke NumberBox dengan kecepatan penuh dan @teaP bergabung dengan saya sebagai pengembang fitur kami! Kami masih menargetkan akhir November untuk pratinjau kontrol ini, yang akan membuat kami melihat rilis stabil dengan WinUI 2.4.

Ada banyak beban dalam alur kerja lama, jadi saya akan menyimpan pertanyaan terbuka atau yang sudah dijawab dan memindahkannya ke PR spesifikasi baru di mana

• lokalisasi
• desain (terutama yang berkaitan dengan tombol Atas/Bawah)
• hyperscroll/hyperdrag

Perhatikan bahwa topik validasi telah diselesaikan. Dengan pekerjaan Validasi Input @LucasHaines yang dijadwalkan untuk WinUI 3.0 dan rilis perencanaan NumberBox sebelumnya, kami telah mengurangi mode validasi yang didukung NumberBox V1 menjadi:

enum NumberBoxBasicValidationMode
{
Dengan disabilitas,
Masukan Tidak ValidDitimpa,
};

Ayo WinUI 3.0 dan pekerjaan validasi input co-syarat, kami akan mencari untuk memperluas enum itu dengan mode validasi IconMessage dan TextBlockMessage yang direncanakan semula di NumberBox V2.

Saya akan mengakhiri semua kemajuan sebelumnya sekarang, dan saya akan memposting pertanyaan dan meminta umpan balik yang relevan. Terima kasih untuk tetap bersama kami. 😄

Fiuh. Itu semakin dekat dengan saya mencoba melakukan ini sendiri.

Haha saya ingin terus mengerjakan ini secara pasif tetapi semester ini telah membuat saya habis. Senang melihatnya terbungkus, saya akan mengawasinya!

Komit awal NumberBox langsung sekarang!

TOLONG - Perlu diingat ini masih dalam proses dengan pelacakan masalah aktif di sisi dev dan PM . Jika Anda melihat bug atau kelemahan umum pada fitur yang belum dicatat di salah satu tautan yang sesuai, jangan ragu untuk memberi tahu kami. 😊

@SavoySchuler , akankah Anda membuka PR baru untuk spesifikasinya? Juga, apakah Anda memperhatikan apa yang saya tulis di komentar ini terutama di sekitar tampilan NaN? Terima kasih.

@SavoySchuler Beberapa komentar tentang kode spec/NumberBox sejauh ini. Mudah-mudahan, komentar untuk ini bisa berakhir di spec/dokumentasi juga. Secara keseluruhan, itu bagus untuk melihat ini datang bersama-sama!

LangkahFrekuensi

Menggunakan kata 'Frekuensi' di sini tidak cocok dengan saya. Dalam kontrol Slider, TickFrequency masuk akal karena kutu dihitung dan ditampilkan pada modulus rentang maks-min keseluruhan. Namun, dalam kontrol ini, itu hanya ukuran kenaikan/langkah. Ini lebih merupakan 'StepAmount' atau 'StepValue' -- lebih baik lagi hanya 'Step' yang mirip dengan 'Minimum' daripada 'MinimumValue'.

Juga, apakah pengguna dapat memasukkan nilai yang berada di luar Langkah yang ditentukan?
Misalnya Minimum = 0, Maksimum = 6, StepFrequency = 2. Menggunakan nilai panah atas akan {2, 4, 6} cukup adil. Bisakah pengguna mengetik 0,5 sebagai nilai yang valid? Atau akan dibulatkan menjadi 0 atau 2?

pembulatan

Bagaimana pembulatan matematika ditangani? Ini sangat penting saat memasukkan nilai mata uang menggunakan ekspresi. Kita harus dapat menentukan -- atau menyediakan -- pembulatan khusus setelah Ekspresi dihitung. HalfAwayFromZero adalah apa yang saya cari untuk memulai tetapi mode pembulatan lainnya harus diizinkan juga.

Lokalisasi

Harap konfirmasikan bahwa NumberBox akan menerima implementasi INumberFormatter /

Pembungkusan Teks

Sunting: Saya harus membaca seluruh spesifikasi lain kali.

Mengapa Anda membuat properti 'IsWrapEnabled' baru? Apakah karena Anda merasa istilah 'Teks' tidak cocok untuk NumberBox?

Juga, saya mengerti mungkin baik Wrap dan WrapWithOverflow diimplementasikan sama tetapi kemudian biarkan kedua nilai enum menjadi setara dan jelaskan fungsionalitas dalam dokumentasi.

Tangani Akselerator Keyboard dengan Benar

Pastikan kontrol ini mendukung penggunaan akselerator keyboard lebih baik daripada TextBox. Mungkin itu tidak dapat dilakukan sampai/jika TextBox diperbaiki, tetapi #1435 benar-benar masalah bagi saya yang menyebabkan banyak pekerjaan buruk. TextBox akan menangani paste 'Ctrl+V' itu sendiri dan kemudian KeyboardAccelerator apa pun akan dimunculkan. Namun, tidak ada cara di dalam KeyboardAccelerator untuk mengetahui bahwa TextBox baru saja melakukan tugasnya sendiri.

Sebuah pemikiran yang cepat. Haruskah ada Mode Sudut yang akan menambahkan mesin terbang derajat ke nilai (dan logika apa pun untuk bungkus 360 °)

°

Atau apakah embel-embel ini akan lebih baik ditangani di masa depan dengan proposal Suffix saya untuk TextBox #784

@mdtauk , Menambahkan simbol derajat dimungkinkan dengan INumberFormatter2 -- itulah alasan bagus lainnya bahwa ini perlu tetap generik. Anda dapat melakukan apa pun yang diperlukan untuk mengonversi angka menjadi string dan meneruskan string kembali ke kontrol.

Untuk pembungkus, sebenarnya untuk itulah properti IsWrapEnabled... Saya perlu membaca akhir dokumentasi lain kali.

Intinya saya pikir kami dapat melakukan semua yang Anda inginkan dengan API yang ada.

@mdtauk , Menambahkan simbol derajat dimungkinkan dengan INumberFormatter2 -- itulah alasan bagus lainnya bahwa ini perlu tetap generik. Anda dapat melakukan apa pun yang diperlukan untuk mengonversi angka menjadi string dan meneruskan string kembali ke kontrol.

Untuk pembungkus, sebenarnya untuk itulah properti IsWrapEnabled... Saya perlu membaca akhir dokumentasi lain kali.

Intinya saya pikir kami dapat melakukan semua yang Anda inginkan dengan API yang ada.

Saya tahu Min, Max, Wrap, menanganinya, tetapi apakah Derajat cukup umum untuk memiliki mode Sudut eksplisit untuk kotak? Dan seharusnya itu menampilkan simbol di TextBox Text, sedangkan Nilai internal hanya angka.

@teaP Melihat Compact SpinButtonMode yang baru, apakah mungkin untuk menambahkan animasi pertunjukan dan sembunyikan ke Tombol Putar yang dilapis?

Anda juga sudah mempertimbangkan untuk menambahkan Akrilik ke dalamnya, agar lebih cocok dengan Kotak Kombo dan bidang formulir lainnya dengan elemen flyout?

Sunting: Ini akan memperbaiki masalah visibilitas ini di Tema Gelap. Apakah niatnya untuk mencocokkan warna fokus Kotak Teks atau mencocokkan warna tema saat ini? Bagaimanapun, Akrilik memecahkan ini.

@SavoySchuler , akankah Anda membuka PR baru untuk spesifikasinya? Juga, apakah Anda memperhatikan apa yang saya tulis di komentar ini terutama di sekitar tampilan NaN? Terima kasih.

@adrientetar pastinya. Ketika NumberBox kosong, Value akan disetel ke NaN (seperti yang Anda minta) dan PlaceholderText akan ditampilkan.

@SavoySchuler Beberapa komentar tentang kode spec/NumberBox sejauh ini. Mudah-mudahan, komentar untuk ini bisa berakhir di spec/dokumentasi juga. Secara keseluruhan, itu bagus untuk melihat ini datang bersama-sama!

LangkahFrekuensi

Menggunakan kata 'Frekuensi' di sini tidak cocok dengan saya. Dalam kontrol Slider, TickFrequency masuk akal karena kutu dihitung dan ditampilkan pada modulus rentang maks-min keseluruhan. Namun, dalam kontrol ini, itu hanya ukuran kenaikan/langkah. Ini lebih merupakan 'StepAmount' atau 'StepValue' -- lebih baik lagi hanya 'Step' yang mirip dengan 'Minimum' daripada 'MinimumValue'.

Saya telah membagikan umpan balik ini dengan @MikeHillberg dan kami sedang membicarakannya sekarang. Untuk mendokumentasikan diri sendiri di antara semua properti lain di sini, kami sedang mempertimbangkan sesuatu di sepanjang baris "SpinButtonStep" jika alasan ini cukup pembenaran untuk menyimpang. Aku akan memberitahu Anda. Terima kasih telah menaikkan poinnya!

Juga, apakah pengguna dapat memasukkan nilai yang berada di luar Langkah yang ditentukan?
Misalnya Minimum = 0, Maksimum = 6, StepFrequency = 2. Menggunakan nilai panah atas akan {2, 4, 6} cukup adil. Bisakah pengguna mengetik 0,5 sebagai nilai yang valid? Atau akan dibulatkan menjadi 0 atau 2?

Pengguna dapat memasukkan input numerik atau formula hukum apa pun yang mereka suka. Lihat bagian pemformatan untuk contoh tentang cara menggunakan properti NumberFormatter untuk kemudian memaksa input itu ke pemformatan yang Anda konfigurasikan.

SpinButton hanya akan menambah atau mengurangi nilai itu dengan ukuran langkah SpinButton yang ditentukan (nama API sekarang tertunda). Jadi, pastikan Anda mengonfigurasi pemformatan dan ukuran langkah yang bermain bersama dengan baik.

Strategi pembulatan yang digunakan ditentukan melalui pemformatan Anda . Untuk menguraikan contoh DecimalFormatter, berikut adalah contoh properti pembulatan yang dapat Anda konfigurasikan.

pembulatan

Bagaimana pembulatan matematika ditangani? Ini sangat penting saat memasukkan nilai mata uang menggunakan ekspresi. Kita harus dapat menentukan -- atau menyediakan -- pembulatan khusus setelah Ekspresi dihitung. HalfAwayFromZero adalah apa yang saya cari untuk memulai tetapi mode pembulatan lainnya harus diizinkan juga.

Pembulatan ditangani melalui pemformatan . Berikut adalah contoh properti pembulatan yang dapat diatur untuk DecimalFormatter. Saya akan menambahkan contoh dalam Pedoman untuk membantu memperjelas hal ini. Terima kasih lagi. 😊

Lokalisasi

Harap konfirmasikan bahwa NumberBox akan menerima implementasi INumberFormatter /

Itulah maksud dari implementasi saat ini. Adapun jaminan pembuktian di masa depan, NumberBox akan terus memiliki solusi untuk kebutuhan pelokalan dan pemformatan. Untuk saat ini dan untuk masa mendatang, kami telah menerapkannya.

Pembungkusan Teks

Sunting: Saya harus membaca seluruh spesifikasi lain kali.

~Mengapa Anda membuat properti 'IsWrapEnabled' baru? Ini bertentangan dengan konvensi TextBox/XAML menggunakan TextBlock.TextWrapping dan Enum TextWrapping. Apakah karena Anda merasa istilah 'Teks' tidak cocok untuk NumberBox?~

~Juga, saya mengerti mungkin baik Wrap dan WrapWithOverflow diimplementasikan sama tetapi kemudian biarkan kedua nilai enum menjadi setara dan jelaskan fungsionalitas dalam dokumentasi. Membuat properti baru di sini hanya berarti kita membutuhkan konverter nilai baru, dll... tidak ada alasan untuk melanggar konvensi yang sudah ada.~

Tangani Akselerator Keyboard dengan Benar

Pastikan kontrol ini mendukung penggunaan akselerator keyboard lebih baik daripada TextBox. Mungkin itu tidak dapat dilakukan sampai/jika TextBox diperbaiki, tetapi #1435 benar-benar masalah bagi saya yang menyebabkan banyak pekerjaan buruk. TextBox akan menangani paste 'Ctrl+V' itu sendiri dan kemudian KeyboardAccelerator apa pun akan dimunculkan. Namun, tidak ada cara di dalam KeyboardAccelerator untuk mengetahui bahwa TextBox baru saja melakukan tugasnya sendiri.

NumberBox berisi TextBox dan menambahkan properti dan konfigurasi di atasnya. Saya akan menandai @jevan karena dia mungkin memiliki pemahaman yang lebih komprehensif, tetapi intuisi saya adalah bahwa ini mungkin perlu diperbaiki pada level TextBox.

Secara keseluruhan, umpan balik yang luar biasa @robloo! Saya menghargai waktu yang Anda luangkan untuk membantu memastikan kami selengkap dan selengkap mungkin dengan V1 NumberBox! Harap beri tahu saya jika Anda memiliki pertanyaan lagi. 😊

@mdtauk

Sebuah pemikiran yang cepat. Haruskah ada Mode Sudut yang akan menambahkan mesin terbang derajat ke nilai (dan logika apa pun untuk bungkus 360 °)

°

Atau apakah embel-embel ini akan lebih baik ditangani di masa depan dengan proposal Suffix saya untuk TextBox #784

Sejauh ini, NumberBox tidak mendukung tampilan karakter non-numerik (bahkan karakter formula dihapus pada evaluasi ekspresi).

Saya pikir proposal Anda untuk #784 sejauh ini adalah yang paling komprehensif untuk platform kami. Jika proposal itu tidak ditindaklanjuti, itu menurut saya sebagai fitur V2 NumberBox yang sesuai sebagai cadangan.

Kami sudah merencanakan V2 untuk dirilis bersama atau segera setelah WinUI 3.0 karena dua mode validasi input yang sangat diminta untuk NumberBox diblokir karena membutuhkan WinUI 3.0. Jadi saya akan membuka edisi V2 setelah V1 ditayangkan dan saya akan mencoba memastikan untuk mencatat ini di sana juga.

Untuk mendokumentasikan diri sendiri di antara semua properti lain di sini, kami sedang mempertimbangkan sesuatu di sepanjang baris "SpinButtonStep" jika alasan ini cukup menjadi pembenaran untuk menyimpang

Saya melihat bahwa StepFrequency adalah apa yang digunakan Slider, jadi saya pikir kami mencoba untuk konsisten dengan terminologi itu. Jangan lupa bahwa itu bukan hanya untuk tombol putar tetapi juga untuk nilai perubahan penyedia dragging dan UIAutomation.

@robloo dan @mdtauk , saya seharusnya membaca lebih jauh ke dalam utas sebelum membalas tentang °. Saya tidak percaya saat ini didukung untuk menampilkan simbol ini di dalam Text karena NumberBox menjaga Text dan Value sinkron sehingga untuk tujuan memungkinkan Anda sebagai pengembang dapat mengambil jenis apa pun yang Anda butuhkan tanpa biaya konversi. Saya tidak melihat cara untuk mencapai ini melalui properti pemformatan yang tersedia, tetapi jika Anda tahu caranya, beri tahu saya!

Kami sedang menghadapi rilis V1 sekarang, tetapi untuk V2 kami akan melihat lagi pada karakter awalan/suffic/khusus. Sementara itu, saya percaya proposal @mdtauk untuk #784 adalah solusi paling komprehensif yang telah diajukan untuk platform sejauh ini. Berikan jempol dan komentar untuk proposal itu jika ini adalah fitur yang Anda butuhkan.

@adrientetar , scroll-to-change berhasil masuk untuk V1 tetapi drag-to-change ditunda ke V2. Karena kami masih mencari untuk melengkapi fitur-fitur tersebut, kami belum sempat membahas permintaan Anda agar Shift+Atas/Bawah melangkah dalam satuan 10 dan Ctrl+Shift+Atas/Bawah melangkah dalam satuan 100.

Bisakah Anda memberi saya lebih banyak konteks tentang skenario Anda akan menggunakan fitur ini? Bagaimana pengguna Anda tahu ini tersedia? Bisakah Anda membantu saya memahami mengapa ini harus menjadi default (atau setidaknya tersedia) di semua NumberBox dibandingkan dengan yang diterapkan secara lokal dalam solusi Anda?

@SavoySchuler

Terima kasih banyak atas komentar Anda.

Untuk mendokumentasikan diri sendiri di antara semua properti lain di sini, kami sedang mempertimbangkan sesuatu di sepanjang baris "SpinButtonStep" jika alasan ini cukup menjadi pembenaran untuk menyimpang

Saya sangat menyukai terminologi itu, saya melewatkan bahwa Slider sudah memiliki properti StepFrequency. Karena itu masalahnya, tidak masuk akal untuk menyimpang dari konvensi seperti yang dinyatakan @jevansaks .

Pembulatan ditangani melalui pemformatan. Berikut adalah contoh properti pembulatan yang dapat diatur untuk DecimalFormatter.

Katakanlah pengguna memasukkan "1 / 3" di NumberBox. Apakah urutan berikut ini benar:

• Saat kehilangan fokus / masukkan ekspresi akan dievaluasi dan nilai ganda 0,33333333...34 akan dihitung
• 0.333333333...34 akan diteruskan ke DecimalFormatter
• 0.333333333...34, tergantung pada pengaturan Anda, dapat dibulatkan menjadi "0,30" (hanya untuk mempersulit)
• Nilai "0,30" itu kemudian akan dimasukkan ke dalam TextBox untuk ditampilkan kepada pengguna
• Ganda Value sekarang {0.33333333...34} dan nilai Text sekarang "0.30"
• Membaca ganda Value TIDAK akan mengembalikan angka bulat yang ditampilkan di Text
  (Atau apakah nilai yang diformat desimal entah bagaimana diuraikan lagi setelah konversi ke string? dan kemudian semuanya dievaluasi ulang?)

Saya juga khawatir bahwa properti Nilai dan Teks sangat erat digabungkan secara internal. Dokumentasi tidak mendefinisikan kopling ini dan jika tidak sangat terstruktur, dependensi dua arah tidak pernah menyenangkan.

Saya belum yakin bagaimana ini diterapkan secara internal, tetapi tampaknya cara yang benar untuk melakukan ini adalah dengan memperlakukan Nilai ganda sebagai satu-satunya properti nyata. Teks hanyalah versi Value yang diformat. Kemudian pengembang akan dapat memformat nilai sesuai keinginan mereka untuk ditampilkan di TextBox dan properti Text (kita akan mendapatkan simbol derajat atau simbol kaki/inci yang sebelumnya diminta). Itu tidak akan sulit dilakukan sama sekali jika semuanya sudah didorong secara internal oleh properti Value. Input tekstual dari pengguna tidak disimpan dan hanya akan digunakan untuk menghitung ulang Nilai yang kemudian diformat lagi untuk ditampilkan.

Urutan harus:

• Input Tekstual Pengguna -> Parser -> Nilai Ganda -> Pemformatan -> Teks

Mengubah nilai Teks dari kode akan menjadi seolah-olah pengguna memasukkan beberapa teks. Mengubah Nilai secara langsung hanya akan melalui langkah Pemformatan dan Teks.

Untuk menjaga pembulatan akurat antara urutan Nilai dan Teks akan lebih seperti:

• Input Tekstual Pengguna -> Parser -> Nilai -> Pembulatan -> Nilai -> Pemformatan -> Teks

Sunting: Untuk menerapkan pembulatan dalam parser ekspresi/input dan mesin evaluasi (apa pun namanya), Anda mungkin perlu menambahkan properti baru untuk mendefinisikan algoritme seperti RoundingAlgorithm . Enum itu sudah didefinisikan di Windows.Globalization.NumberFormatting seperti yang Anda tunjukkan. INumberFormatter2 harus digunakan untuk pemformatan dan tidak ada yang lain -- sekali lagi pisahkan tahapan antara perhitungan dan teks yang akhirnya ditampilkan.

@adrientetar , scroll-to-change berhasil masuk untuk V1 tetapi drag-to-change ditunda ke V2. Karena kami masih mencari untuk melengkapi fitur-fitur tersebut, kami belum sempat membahas permintaan Anda agar Shift+Atas/Bawah melangkah dalam satuan 10 dan Ctrl+Shift+Atas/Bawah melangkah dalam satuan 100.

Bisakah Anda memberi saya lebih banyak konteks tentang skenario Anda akan menggunakan fitur ini? Bagaimana pengguna Anda tahu ini tersedia? Bisakah Anda membantu saya memahami mengapa ini harus menjadi default (atau setidaknya tersedia) di semua NumberBox dibandingkan dengan yang diterapkan secara lokal dalam solusi Anda?

Satu harus menjadi kenaikan yang lebih besar, dan yang lainnya harus lebih kecil - mirip dengan menyenggol area/objek yang dipilih di aplikasi Adobe

Bisakah Anda memberi saya lebih banyak konteks tentang skenario Anda akan menggunakan fitur ini?

Ini bagus ketika Anda ingin mengubah nilai dengan implikasi visual (misalnya rotasi objek) tetapi Anda tidak yakin seberapa jauh Anda ingin pergi. Jadi bagus untuk desain visual.

Bagaimana pengguna Anda tahu ini tersedia?

Ini hanya fitur yang dimiliki alat modern, misalnya Adobe XD, Framer...

Bisakah Anda membantu saya memahami mengapa ini harus menjadi default (atau setidaknya tersedia) di semua NumberBox dibandingkan dengan yang diterapkan secara lokal dalam solusi Anda?

Saya pikir itu baik untuk memiliki ini ketika Anda berada di perangkat sentuh, itu cara yang nyaman, ketuk-seret, untuk mengubah nilai yang diberikan (seperti widget pemilih waktu telepon tempat Anda mengetuk-seret untuk menggulir nilai).

Satu harus menjadi kenaikan yang lebih besar, dan yang lainnya harus lebih kecil - mirip dengan menyenggol area/objek yang dipilih di aplikasi Adobe

RangeBase memiliki properti SmallChange dan LargeChange. Kami di Perangkat Lunak BeLight dalam versi NumericUpDown kami berasal dari RangeBase dan mengubah nilai dengan SmallChange menggunakan pintasan ArrowUp dan ArrowDown, dan oleh LargeChange menggunakan pintasan PageUp dan PageDown

Dan kita tidak sendirian di sini,
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

Hanya satu komentar tentang keypad numerik keyboard yang muncul di benak saya selama panggilan komunitas ...

Di sebagian besar aplikasi, "." tombol keypad masih dipetakan ke "." karakter, yang berbeda dari pemisah desimal saat menggunakan bahasa non-Inggris (misalnya "," dalam bahasa Prancis). Jadi ketika Anda menekan tombol "." kunci di notepad, ia menulis "." karakter.

Beberapa aplikasi (Excel adalah yang paling dikenal tentang itu) mengubah perilaku tombol ini untuk menafsirkan ulang penekanan tombol apa pun pada keypad "." sebagai masukan pemisah desimal. Ini lebih kompatibel dengan desain tombol "kalkulator".

Aplikasi Kalkulator juga menulis ulang "." tekan untuk menafsirkannya sebagai karakter pemisah desimal.

Karena kotak angka akan diizinkan untuk bekerja lebih sebagai "kalkulator", dapatkah kontrol mengizinkan untuk menggunakan "." tombol di keypad sebagai pemisah desimal ? Atau setidaknya menyediakan cara bagi pengembang untuk menambahkan fitur ini tanpa harus berjuang dengan filter dan acara utama?

Mungkin sebuah properti dapat mengizinkan untuk mengaktifkan (jika memilih) atau menonaktifkan (jika memilih tidak ikut) fitur tersebut. Seperti KeyPadDotAsDecimalSeparator="false" ?

Proposal NumberBox V2: https://github.com/microsoft/microsoft-ui-xaml/issues/1736

Halo Komunitas WinUI yang luar biasa! Terima kasih tulus telah membantu kami mengantar pulang komunitas pertama kami mengusulkan kontrol untuk melihat rilis. Kami tahu ini adalah tugas besar dan Anda semua menginvestasikan banyak waktu untuk menyusun koleksi terbaik fitur V1 yang dapat kami rancang bersama.

Kami juga tahu bahwa tidak semuanya berhasil masuk ke rilis V1. Beberapa konfigurasi validasi input yang sangat diinginkan bergantung pada kerja fitur WinUI 3.0, beberapa kebutuhan fitur yang diinginkan muncul di akhir validasi/aplikasi, dan beberapa fitur yang kami tahu akan dieksplorasi lebih baik setelah rilis V1.

Kami ingin menyelesaikan pekerjaan fitur NumberBox yang kami maksudkan dengan rilis WinUI 3. Saya telah membuka masalah untuk mengumpulkan umpan balik tentang fitur yang diperlukan yang hilang dari V1. Jika NumberBox kehilangan sesuatu yang Anda butuhkan, pastikan untuk memberikan komentar di sini: https://github.com/microsoft/microsoft-ui-xaml/issues/1736