出発点として、Telerikにはhttps://www.telerik.com/universal-windows-platform-ui/numericboxが1つありhttps ：

私が彼らから気に入っているのは、ValueFormatプロパティを使用したフォーマットのアプローチです。

例：ValueFormat = "{} {0,0：C2}"

また、これが正しくローカライズされていることを確認してください。 Windows Community Toolkitの実装には、いくつかの欠点があります。

ValidationType = "Decimal"のTextBoxRegex拡張機能は、すべてのUIカルチャをサポートしているわけではありません。 代わりに、InvariantCultureに修正されています。 英語では、10進値はピリオド付きの「10.1234」です。 スペイン語またはドイツ語では、10進値は「10,1234」と表記されます。 英語の構文解析は正しいでしょう。 ただし、スペイン語またはドイツ語のユーザー入力は「101234」になり、小数部分が失われます。

参照： https ：

上矢印と下矢印は、開発者が設定できる値だけ値をインクリメントまたはデクリメントする必要がありますが、デフォルトは1のintである必要があります

• ラップアラウンドの最小/最大値は、たとえば角度を選択する場合に適しています
• 接尾辞を追加する機能
• テキストボックスをクリックし、上下にドラッグして値を変更します。AdobeXDではこれが数値入力に含まれています。

WinRT XAML Toolkitでの私の実装は、値を変更するための上下のドラッグもサポートしており、特定のシナリオでボタンをクリックするよりも、マウスで使用する方がはるかに使いやすくなっています。
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

こんにちは、 @ sonnemaf 、 @ ArchieCoder 、 @ robloo 、 @ mdtauk 、 @ adrientetar 、および@xyzzer！ 私はこの提案に割り当てられました。

まず、これを提出してくれた@sonnemafに感謝します。 先週のMicrosoftBuild2019で披露したところ、観客から歓声が上がりました！ ここでのコメントでのコミュニティの反応は、NumberBoxが発生するのを見なければならない興奮も反映しています。

私は皆のコメントを読み、受け取った入力を反映するようにスコープセクションを更新しました。 皆さんがこの小さなアップデートを幸いです。一部の詳細（フォーマットのローカリゼーションなど）は仕様レベルで処理されます。

こんにちは@SavoySchuler 、

今週は、アプリのユーザー補助機能に取り組んでいます。 たとえば、新しいコントロールでアクセシビリティが正しく処理される場合、これはプラスになります。たとえば、「プラス」、「マイナス」の代わりに増分を大声で言うことができます。 残りは私には問題ないようです。

ナレーターが値を適切に読み取ることができるようにすることで、何が起こっているかが重要であることを明確にします。

アナログスティックと十字キーが正しく機能することを確認するために、Xboxコントローラーにフォーカスタップが必要かどうかわからない

小さな修正-ドラッグして増減すると、テキストフィールドがアクティブになるまでテキストフィールド自体で機能するはずです。 私の実装では、IIRCを有効にするためにテキストフィールドの上に透明なオーバーレイを配置し、ドラッグ中にマウスカーソルを非表示にして、コントロールまたは画面の境界がドラッグ距離を制限しないようにし、ドラッグが完了したときにそれを制限する必要がありました。カーソルをもう一度表示します。最初に消えた場所に表示されます。

@SavoySchulerあなたは素晴らしい仕事をしました。 私はあなたのスコープで生きることができます。 電卓は持っておくと便利です（WinUI 3.0または3.1）。 私は多くのデスクトップ環境（VB6、WinForms、WPF、およびUWP）で開発してきましたが、常にNumberBoxを見逃していました。 最後にそれを取得します。

たぶん、上/下のマウススクロールホイールを追加することもできます。 Blend for VisualStudioはこれをサポートしています。

また、ExpressionBlendでよく使用したDrag-to-changeも大好きです。

入力検証が何をするのか、何をしないのかわかりません。 最小/最大のみですか、それともキーボード（文字azなど）を制限しますか？ 無効な番号の貼り付けを処理しますか？

私は完全な仕様を読みたいです。

@ArchieCoder 、私はあなたが大声ではっきりと聞こえます。 アクセシビリティは優先事項であり、事前に処理するのが最善です。 私はあなたのメモを追加したこの提案のアクセシビリティとインプットのセクションを始めました。

@mdtauk 、いつものように素晴らしい質問です。 これを調べるためのメモとして、これを[アクセシビリティと入力]セクションに追加しました。

@xyzzer 、その通りです。 スコープリストを再編成するときに、関連する機能として上/下ボタンとドラッグして変更をグループ化しました。 読み直すと、ボタンの機能としてドラッグして変更することを提案しているように見えました。 わかりやすくするために、ドラッグして変更するセクションを独自のセクションに移動しました。

@sonnemaf 、すごい。 スペックがオープンしたらすぐにリンクを投稿します。これはおそらく今日か来週になるでしょう。 ぜひご参加ください。 それまでは、ここでスコープにスクロールして変更を追加しました。

すべて、電卓のサポートに関するメモ付き-私はその価値を信じています。 私はチームと協力して、プラットフォームで機能をさらに活用できる場合に備えて、モジュール化する必要があるかどうかを判断しています。 さらに、電卓のサポートをどこまで利用できるかという問題があります。 +-/ *の操作の単純な順序は実行されますか？ それとも、ある種のwolfram alphaサービスに接続するなど、より包括的なものですか？ モジュラールートを探索することで、より包括的な形式の計算機サポートの機会を妨げずに、より基本的なケースから始めることができるかもしれません。 ここでみんなのニーズを知りたいです。

入力検証についても、同じ質問があります。 最小、最大、文字なし、無効な貼り付けはカバーしていませんか？

電卓の機能はかわいいと思いますが、実際にはこの機能はユーザーによってどのように発見されますか？ これについての小さなウィジェットのヒントはありますか？

@ ArchieCoder 、

開発者に頼ることができるアプリレベルのガイダンス用のToolTipまたはより重いTeachingTipがありますが、私の強い好みは、NumberBox自体の中でこれを解決することです。

ここであなたの考えを聞いてみたいです！

スペースの制限のために他のコンテキストが必要ない限り、プレースホルダーは確かに良い方法です。 たとえば、NumberBoxの幅はテキストボックスよりも小さくなると思います。

コントロールがnull許容数をサポートしていない限り、常に値が表示されますが、
そのため、内部にプレースホルダー文字列用のスペースはありません。

10:14 ArchieCoderで金、2019年5月17日には[email protected]
書きました：

他のコンテキストがそうでない限り、プレースホルダーは確かに良い方法です
スペースに限りがあるため必要です。 NumberBoxの幅は
たとえば、テキストボックスよりも小さくします。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
。

@Sonnemafの例のように見える@ArchieCoder （これらに感謝します）、「a + b --c」のプレースホルダーテキストを表示するのに十分な幅ではないNumberBoxも、推奨されるユーザーエクスペリエンスを作成するのに十分な幅ではありません。に方程式を入力します。 その点で、私はこの解決策の選択肢がこの目的のためにまだ実行可能であると想像します。 ただし、まだ対処していない領域を利用していると思います。コンパクトなNumberBox /単純な数値のみを入力するシナリオです。 電卓のサポートには、それを無効にするためのAPIが必要だと思います。その場合、長いプレースホルダーテキストを気にする必要はなく、NumberBoxの方程式形式が必要とする最小スペースの制約を破る必要もありません。ただし、コンパクトモードのプレースホルダーテキストオプションはまだ良いかもしれません。 、「＃」や「eg2」のようなものであっても。

@xyzzer 、これを持ってきてくれてありがとう。 これが最初に適切なユーザーエクスペリエンスでさえあることを確認しましょう。そこから実装を理解できます。 緩和できる可能性のある技術的な制限があるため、_right_ユーザーエクスペリエンスの検索を制限する必要はまだありません。 ：リラックス：

私は誰にとっても優先度の高い質問があります：

標準のTextBoxから独立してこれらの機能を統合するNumberBoxコントロールが必要ですか、それともAPIまたはInputScopeを介してアクティブ化できるネイティブ機能としてこれらの機能をTextBoxに焼き付けたいですか？

（ @ sonnemaf 、 @ ArchieCoder 、 @ robloo 、 @ mdtauk 、 @ adrientetar 、および@xyzzer）

これらすべてをTextBoxコントロールに入れることは重要な変更です。

入力された文字の検証。

InputScopeで正しいキーボードレイアウトを使用する

異なるマウスの動作。

FabricWebバージョンのようにスピナーボタンを表示する機能。

アプリで現在TextBoxを使用している他のすべての人に影響を与えることなく、TextBoxタイプを定義する動作列挙型を使用して、これらすべてを追加できれば、それは良いことです。

また、検索を表すアイコンやボタンのように機能するカレンダーなど、他のTextBoxの動作を組み合わせることも検討できます。 横にテキストを入力すると、プレースホルダーテキストのスタイルで「http：//」を表示するIPアドレスやURLなどのマスク。

FabricWebには、TextFieldsが豊富に用意されています。

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

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

これらすべての機能をTextBoxコントロールにベイクする代わりに、私は間違いなく独自のNumberBoxコントロールを使用します（入力モードの「パスワード」を持つTextBoxではなくPasswordBoxコントロールもあるのと同様です）。

たとえば、NumberBoxコントロールは、IPアドレスの単純な入力フィールド以上のものになります。 独自のアクセス可能性/独自のスクロール＆ドラッグ機能、電卓のサポートなどが付属します。これらはすべて、これまでのTextBoxの通常の使用方法（グループの表現名を指定するのと同じくらい簡単な場合）とは大きく異なります。データの）。 また、NumberBoxコントロールに対してさらに多くの特別な機能/要件が提案されるため、NumberBoxとTextBoxの両方をきれいに分離することができます。

その槍は、ドキュメントとアプリのxamlレイアウトにも含まれます（たとえば、NumberBoxは、入力モードを指定するプロパティの束を持つTextBoxよりも簡単に検出できます）。 数値入力機能に関するTextBoxのドキュメントを読む代わりに、その部分は特定のNumberBoxコントロールのドキュメント（今日のPasswordBoxの場合と同じように）で整理されています。

コントロールの外観に関しては、ユニット/サフィックスを小さいサイズ/彩度の低い色で脇に表示して、値自体と区別できると思います。

マウスをコントロールの上に置くと、ユニットの代わりに上向き/下向き矢印がフェードインする可能性があります。

別の方法は、figma.comの番号コントロールです。ユニットにカーソルを合わせると、クリックして左右にドラッグして値を変更できます。

左右は、マウスを上下よりも左右に動かす方が簡単なので、興味深いです（手首を持ち上げる必要はありません）。

他のもの：

• フォーカスのないテキスト領域をクリックすると、すべてのコンテンツが選択されます。 クリック+値の入力+入力で値が変更されるようにします
• Shiftキーを押しながら矢印をクリックするか、フォーカスが10ずつ増減するときにShiftキーを押しながら上/下に移動します（その値もカスタマイズ可能である必要があります）。
• 上/下矢印はユーザーにとってあまり役に立たないと思います。 ユーザーが正確な値を必要とする場合は、それを入力するだけです。必要な値がわからない場合は、クリックしてドラッグすることで、値の変化のスペクトルを視覚化できます。 したがって、上向き/下向き矢印はおそらく少なくともオプションである必要があります。

@adrientetarがユニットの表示をコントロール内に配置すると、多くの追加の問題が発生します。

• ローカリゼーション
• アクセシビリティ
• 選択
• 貼り付け
• 変換

これらはすべて、これをヘッダー、説明、または別のTextBlockに配置することで回避できます。

Textプロパティではなく、Valueプロパティを持つ別のNumberBoxコントロールを使用します。 データバインド（x：Bind）できるように、値はDoubleにする必要があります。 Decimalデータ型もサポートする必要があるかどうか、およびその方法はわかりません。

null許容型のサポートは私が考えなければならないことです（@xyzzerに感謝します）。 ValueプロパティはNullableである必要がありますデータ・タイプ。 null許容値以外の値にバインドするときに、これによってバインドの問題が発生するかどうかはわかりません。

構成には利点があり、番号付きの動作が付属していますが
モードを実装してTextBoxに添付することができます-
それは不必要に複雑で制限されています。
実装で発生する可能性のある最大の問題のいくつかは、
アクセシビリティ。 私はいくつかのアクセシビリティパターンをサポートすると信じています-
特定のインターフェイスの実装をTextBoxに組み込む必要があります
TextBoxがナンバーボックスモードになっていないと混乱します。

2:33 Fons Sonnemansで月、2019年5月20日には[email protected]
書きました：

null許容型のサポートは私が考えなければならないことです（@xyzzerに感謝します）
https://github.com/xyzzer ）。 ValueプロパティはNullableである必要があります
データ・タイプ。 これがバインド時にバインドの問題を引き起こすかどうかはわかりません
null許容値ではありません。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
。

皆さんにもう1つ質問があります。 入力の検証またはマスキングが必要/優先されますか？

（@sonnemaf、@ArchieCoder、@robloo、@mdtauk、@adrientetar、@xyzzer、及びフェリックス-DEV @）

文字列に数値を追加することはできないため、検証は不可欠です。 そして、数学演算子は評価され、処理される必要があります。

計算できない場合は、よくわからないエラーメッセージを表示する必要がありますか。

マスキングは便利ですが、URLと電子メールの入力を処理できるように、おそらくテキストボックス自体に組み込む必要があります。 NumberBoxは、電話番号、IPなどになります

電話番号やIPにNumberBoxを使うべきではないと思います。 これらは、TextBoxの単純なマスキング/フィルタリング拡張機能のように見えます。 NumberBoxは、単一の値を入力するために使用したいものです。
通貨ボックスコントロールを持つ可能性があるかもしれませんが、TBやNBとは別のコントロールにする必要があると思います。

@xyzzerあらゆる種類の数値入力に対してNumberBoxをより柔軟にすることは、私には良い考えのように思えます。 これはTextBoxコントロールから派生させることができ、そのコントロールにはMaskプロパティやその他の動作プロパティを含めることができます。

NumberBoxのこれらのプロパティのいくつかは次のようになります。

• スピナーボタンの表示/非表示
• 値のインクリメントとデクリメントを許可する
• 値の計算を許可する
• マスクされた入力を許可する
• 電話番号やIPアドレスなどのローカライズされたマスク

TextBoxに追加できるプロパティは次のとおりです。

• Maskプロパティ-カスタム形式（---- @ ----.----）および郵便番号などのローカライズされたマスクを定義するXAML文字列
• プレフィックス/サフィックステキスト表示（たとえば、プレフィックスとして_http：// _）
• アクションボタンの表示/非表示-アイコンを使用してイベントプロパティをクリックします
• アイコン（ファブリックUI検索ボックスの左側にアイコンが表示され、ボックスにフォーカスが移動するとアニメーションがオフになります）

これらの画像はFabricUI TextFieldのものであり、これらのさまざまな状態をすべてサポートしています。可能な場合は、Fluent WinUI3.0コントロールを同等にすることを目指す必要があります。

ファブリックUIスピナーボタンはタッチするには小さすぎるので、上下のボタンが互いに積み重ならないように並べて配置するようにフォーマットを変えます。

私にとって、検証は必須であり、マスキングは必要なものです。 私はマスキングが好きではありませんでした。 硬すぎます。

上で提案さ@rudyhuyn Windowsの電卓は、便利な機能をリポジトリ。 @mdtaukがコメントしました。

日付/時刻/カレンダーピッカーと同様に、NumberBoxから電卓ポップアップを開くことができます。

@xyzzerが上で言ったことと同様です。 数字と数字のシーケンスを含む文字列には根本的な違いがあります。
説明されている違いを聞いた最良の方法は、数値に対して乗算と除算の演算を実行できることです。 あなたは数の半分を求めて、2で割ることができます。 郵便番号の半分や「電話番号」を要求して、意味のあるものを取得することはできません。

数学的な機能を備えた特定のNumberBoxと、数字で構成される他の値をキャプチャする機能を混在させると、他の問題も発生する可能性があります。
「電話番号」は先行ゼロ（またはプラス記号）で始まる場合があり、そこでは意味があります。 _number_の場合、それらは削除されず、削除されます。
「電話番号」も角かっことハイフンでフォーマットされていることがよくあります。 数学演算として処理されると、これらは乗算と減算が必要であると簡単に解釈される可能性があります。

TextBoxと同じ方法で、また入力をフォーマットする方法としてマスキングを許可すると、 NumberBoxとTextBoxの違いと、それぞれをいつ使用するかを混乱させるリスクがあります。

単純な検証は必須ですが、検証がプラットフォームに

これらのプロパティのみに基づいて検証を続けます。

• MaximumValue
• 最小値
• AllowDecimalPlaces

別途、の表示が必要です

• 計算からの無効な出力
• 入力/貼り付け/計算された値の処理方法とバインディングで使用されるもの。 計算値または無効な値を表示して無効であることを示す必要がありますが、これをバッキングプロパティに渡すことはできません。

マスクは、何が必要かを明確にするために視覚的なアフォーダンスを必要としますが、基本的な計算入力は、マスクされた入力と一緒に使用されません。

Fabric Webテキストコントロールはこれをうまく処理しているように見えますが、もちろん、NumberBoxのスコープは、デフォルトのTextBoxコントロールに対する一般的な適合と仕上げの改善とは別のものです。

スピナーボタン（およびオプションの電卓フライアウト）は、NumberBoxに固有のように見える唯一の視覚的なものです。

プロパティに関しては、おそらくキーボードの上下ボタンで値を変更できる場合、ステップ値を含めることができるので、キーを押したときにインクリメントまたはデクリメントする量を選択できます。

@mdtauk 、私はステップ値が好きですが、キーを押したときだけではありません。 スクロールと上/下ボタンにもあります。

@sonnemaf確かに、このステップは、マウスホイールのティック、キーの押下、キーの押下などのバイナリに適しています。 おそらく、ボックスからドラッグされた距離がステップ量を増加させる可能性がありますか？

では、 StepMinimumとStepMaximumはおそらく？

では、StepMinimumとStepMaximumはおそらく？

それらの値が何に関連しているのか、またはそれらに何を期待するのか、私にはわかりません。
「ステップ」の目的が増分を定義することである場合は、それを「増分」と呼びます。

これにより、 Max:100 Min:0 Increment:10は、値0、10、20、30、40、50、60、70、80、90、および100のみを指定できるようになります。

ドラッグした距離に基づいてステップ/増分量を変化させると、予測できない値の変化につながる可能性があります。 このコントロールの目的が数値の指定を容易にすることである場合、値がさまざまな量で変化し始めると、これは非常にイライラする可能性があり、専用のコントロールを使用して簡単にするという根本的な目標を打ち破ることになります。

@mrlaceyスライダーとプログレスバーにちなんで名付けられたプロパティであるStepを使用しますが、必要に応じて増分を使用することもできます。 増分が値の増加だけと混同されない限り、値は上下します。

クリックして上下にドラッグし、値を増減するという提案があります。 値がより速く変化することをユーザーが期待している場合は、さらに上または下にドラッグし、Stap MinおよびMax値を設定すると、開発者はデルタの変化に応じてこれを制御できます。 したがって、小さなドラッグ距離は0.1または1ずつ増加する可能性がありますが、さらにドラッグすると、たとえば5または10のステップで変化する可能性があります。

ドラッグ距離が値の変更の速度を変更する必要があると言っているのではありません。それが自然に感じられ、ユーザーに自信とコントロールの感覚を与えた場合に役立つかもしれないという考えだけです。

皆さん、素晴らしいフィードバックです！ 詳細を打ち出すためにスペックとPRを開きました。

@KevinTXYが、このコントロールの開発者として私に加わります。 ここで要件の会話を続け、PRでAPI /サンプル固有の会話を開始します。

仕様書の作成にぜひご参加ください。

TeachingTipの仕様は、完成した仕様がどのようになるかを示す完全な機能を備えた例です。 主な概要は次のとおりです。

• 説明
• すべてのAPI /機能の例
• ガイドライン
• API（IDL）

素晴らしいアイデア、私はこれらすべてがどこに向かっているのかが好きです。 私の2セントを追加する：

• 間違いなく、これはTextBoxと統合するのではなく、別のNumberBoxにする必要があると思います。 さらに、ここで説明する優れた機能はたくさんありますが、NumberBoxを軽量に保つ必要もあります。 したがって、電卓ボックスなどをNumberBoxから派生させ、高度な「2 +3」入力または電卓を開くためのボタンを使用できるようにすることを提案します。
• ローカリゼーションは、事前に仕様で十分に検討する必要があります。 さらに、UIローカルをオーバーライドしたい場合があります。 したがって、NumberformatInfoプロパティまたはCultureInfoを設定すると非常に便利な場合があります。 たとえば、一部のアプリケーションでは、外部値とローカル値の両方が追跡されます。 それぞれが異なる形式になる可能性があります。
• コントロールは、小数点以下の桁数の移動をサポートする必要があります。 これは、変更されたすべてのテキストの形式を単に検証するよりも注意が必要です。 各文字入力を追跡し、必要に応じて前の小数点以下の桁数を置き換える必要があります。
• インクリメント/デクリメント矢印は、オフに設定してプレーンな入力ボックスを表示する必要があります。ここでも、他のコントロールの一部として必要な場合に備えて、軽量のコントロールが必要です。
• まだ説明されていない他のことは、理想的には複数の型（10進数、整数、場合によってはLong、Doubleなど）をサポートする必要があるということです。これは根本的に多くのことを変える可能性があり、私はまだ十分に考えていません。 。
• 値は間違いなくnull許容である必要があります。 未設定の値はゼロとは異なります。
• 重要ではないもう1つのアイデアは、decimal、double、またはfloat型に10進精度を指定できるようにすることです。

私はもっ​​と多くのアイデアが続くと確信しています。 スペックを読むのを楽しみにしています！

（@mdtauk、@xyzzer、@mrlacey、@sonnemaf、@robloo、フェリックス-DEV @、@adrientetar、@ArchieCoder）

仕様/ PRにそれぞれのAPIと例を記入してもらいます。 基本的な事前定義されたタイプ（まだ進行中）の列挙型と、設定されている場合に事前定義されたタイプをオーバーライドするカスタムフォーマットプロパティを使用して、仕様に合わせてフォーマットに対処したと思います。

それをチェックして、それがあなたの懸念を解決しないかどうか、またはそれを追加または改善できるかどうか私に知らせてください。 ここで求められる仕様に貢献するプルリクエストを受け付けます。

• 検証は必須として記載されています。 このコントロールをTextBoxから派生させて、マスキングやその他のサポートプロパティを無料で取得するように規定しました。

• @mrlaceyの懸念に、カスタムフォーマット文字列と組み合わせて使用​​できる先行ゼロの削除を有効/無効にするAPIを追加して、カスタム数値文字列入力のシナリオを有効にしました（国際電話番号とIPアドレスはすでに存在することに注意してください）可能な基本フォーマットタイプのリストにあります）。

• これは、計算機のサポートを有効/無効にする機能と組み合わせて、数値/文字列の軽量化と十分な計算およびカスタマイズのサポートの両方を提供できるコントロールの交差点を実現します。 例の簡潔さがこれを浮き彫りにしていると思いますが、これが将来のコントロールを使用するのをより面倒にするだろうと思う人から聞いてみたいと思います。

• @sonnemafアイコン>ポップアップ計算機の例の斬新さと直感性に感謝します。 私にとって、これは例としてCalendarDatePickerの概念から派生しており、V1で検討する必要があるという強いプッシュがここにいるすべての人からない限り、V2機能の優れた検討事項になる可能性があります。

電卓のオープンソースの取り組みとの調整があれば、ポップアップ電卓は理にかなっているかもしれません。 両方とも、電卓フライアウトの外観の一貫性のためだけでなく、その背後にあるエンジンでも一貫性があります。

ここがこの画像を投稿する場所かどうかはわかりませんが、仕様に準拠したさまざまな州のデザインがここにあります。

画像は200％の縮尺です

@mdtaukモックアップの目的は何ですか？

各画像はどのような状態を表示しようとしますか？ あなたがこれを明確にしないと、私たちはあなたとは異なる仮定をするかもしれません。

これらはピクセルパーフェクトリファレンスになることを目的としていますか？

画像内の何かがプラットフォームまたはベースコントロールのデフォルトと異なる場所を呼び出して、追加または変更するもの（ある場合）が明確になるようにできますか？

@mrlaceyそれが役立つなら、私はより完全な内訳をすることができますか？ 私は、仕様で呼び出された例のいくつかを説明しようとしていました。

それらの目的は、プレフィックス、サフィックス、マスク、上下ボタンなど、提案されたさまざまなコントロール要素を使用して、これらのコントロールがどのように見えるかを説明することです。 これらはFabricWebコントロールデザインから推定されますが、FocusRevealやボタンのコントロールサイズなどのXAML要素を使用します。

例は、Rest-Focus-Disabled状態を示しています

ポップアップ計算機はV2の優れた機能です。

どこに発言すればいいのかわからない。 仕様についてPRを行う必要がありますか、それともこの号で自分の考えを書き続けることができますか？

整数

NumberBoxFormatTypeの整数値は役に立ちますか？

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

言語

この言語を使用して、通貨、10進数のグループ化記号を指定しますか？

次の例では、言語はnl-NLに設定されています。 これは、接頭辞がユーロ記号であり、小数点記号がその後に2つの小数点が付いたコンマであり、数字のグループ化がドットであることを意味しますか？ 負の通貨の前にはマイナス記号があり、米国のように括弧はありません。

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

Windowsには多くの数値と通貨の形式オプションがあるので、これで十分です。

1つまたは複数の値プロパティ

Valueプロパティが必要ですか？それはどの（数値）タイプになりますか？ 私はそれをデータバインドするために使用します。 double、decimal、intのいずれかである必要があります。 Nullableサポート（double？、decimal？、int？）が必要ですか。 継承されたTextBoxコントロールのTextプロパティをデータバインディングに使用したくありません。 Decimalのサポートも必要です。doubleでは不十分です。

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

従業員の給与プロパティがNULL可能である場合はどうなりますか（10進数？）。 ValueNullableDecimal依存関係プロパティが必要ですか。 DatePickerコントロールのSelectedDateはNullableです。 Nullableは、特にデータバインディングの問題です。

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

MinValueとMaxValueについても同じです。 それらは仕様では整数になりましたが、これはダブルであるべきではありませんか？

@sonnemafの仕様では、数字を入力できるすべてのコントロールを対象としているため、「値」をテキストとして扱い、必要に応じて変換するために消費コードに依存していることを意味していると思います。 理想的ではありませんが、長いまたはフロートのValueプロパティがあったとしても、変換が必要になる場合が多くあります。
すべての数値型に対してオーバーロードするよりも優れています。
次に、米国の郵便番号、電話番号、IPアドレスなど、「数値」タイプに変換できないコントロールが設計されているものがあります。 これらの種類の値の場合、テキストを取得するのが最良の（唯一の）オプションのようです。
私はそれがより簡単だと思います（少なくとも初期バージョンでは、入力された値にアクセスし、必要に応じてコンバーターに依存する1つの方法があります。最初にツールキットに来るヘルパー（またはサブクラス）のコレクションの場所を見ることができます。それらはフィードバックに基づいてメインコントロールに組み込まれます。

Languageプロパティは必要ですか？ なぜこれはUILocaleと同じではないのですか？ 正当な理由があるかもしれませんが、これは（OSレベルで）ユーザーが構成可能である必要があり、特定の形式を指定する機能を提供すると、形式が他の場所と一致しない場合、またはユーザーが何を使用するかについて、開発者にとってより多くの問題が発生する可能性がありますアプリケーションが望んでいます。 頭のてっぺんから：誰かが別の形式で値を貼り付けた場合はどうなりますか？

@mdtaukモックアップの目的は何ですか？

各画像はどのような状態を表示しようとしますか？ あなたがこれを明確にしないと、私たちはあなたとは異なる仮定をするかもしれません。

これらはピクセルパーフェクトリファレンスになることを目的としていますか？

画像内の何かがプラットフォームまたはベースコントロールのデフォルトと異なる場所を呼び出して、追加または変更するもの（ある場合）が明確になるようにできますか？

@mrlaceyこれはあなたが望んでいたようなものですか？

@mdtaukは、表示しようとしている内容の一部を説明しているので、少し優れています。

しかし、根底にある質問はまだ残っています：これを示すことにおけるあなたの目標は何ですか？ それは単なるアイデアですか？ さまざまなアイデアを検討した後、それはあなたの好みのバージョンですか？ もしそうなら、なぜこれらが最良/好ましいのですか？

現在のコントロールを、好みの新しいシステムワイドスタイルで新しいコントロールをどのように表示するかを比較すると、コントロールに固有のものと、好みの新しいシステムワイドスタイルのものを区別することができなくなります。

たとえば、境界線の透明度を変更するとします。 この変更は、すべてのコントロールを対象としていますか、それともこれだけを対象としていますか？ そして、どの州で？

（ボタンに）明示的なサイズを指定すると、コンテナのサイズ変更に基づいて常に均等に変換されるとは限らないため、デザインコンプで問題が発生する可能性があります。 それらは常に正方形である必要がありますか？ または、それらの幅はデフォルトのコントロールの高さに基づいて固定されていますか？

接頭辞と接尾辞の背景ブラシが決定されることをどのように提案していますか？ 私は既存のシステムブラシを推測していますが、どれですか？

マスキングはこの仕様ではカバーされていません。 「マスクされた」例は、フォーマット文字列に関連することを目的としていますか？
マスクされた例はどのようにフォーマットに対応していますか？
あなたの例はバージョン4のIPアドレスのエントリを示していると思いますが、すべてがうまく収まっているように見えることに基づいて、そこには多くの仮定があるように見えます。 入力できないすべての値に背景とマージンを含める必要がありますか？ 常に表示されない場合はどうなりますか？ あなたの例のように、コンテンツは利用可能なすべてのスペースに合うように引き伸ばされるべきですか？ 使用可能なスペースよりも広いコンテンツをパンする場合、入力できない値に割り当てられたスペースはどのように処理されますか？

@mdtaukは、表示しようとしている内容の一部を説明しているので、少し優れています。

しかし、根底にある質問はまだ残っています：これを示すことにおけるあなたの目標は何ですか？ それは単なるアイデアですか？ さまざまなアイデアを検討した後、それはあなたの好みのバージョンですか？ もしそうなら、なぜこれらが最良/好ましいのですか？

現在のコントロールを、好みの新しいシステムワイドスタイルで新しいコントロールをどのように表示するかを比較すると、コントロールに固有のものと、好みの新しいシステムワイドスタイルのものを区別することができなくなります。

たとえば、境界線の透明度を変更するとします。 この変更は、すべてのコントロールを対象としていますか、それともこれだけを対象としていますか？ そして、どの州で？

NumberBox仕様には視覚的な例は含まれていません。元の提案の画像は、機能の大まかな例です。 コントロールテンプレートが2epxのCornerRadius値で更新される別のPR＃524があります。これも、FabricWebで使用されるのと同じ丸めです。

したがって、TextBoxから派生したコントロールも同様に更新されると想定して、NumberBoxの提案された機能がそれにどのように適合するかを示すためのガイドとして使用しました。 ファブリックWebテキストフィールドはすでにプレフィックスとサフィックスの値をサポートしているので、私はそのデザインを採用し、XAMLメトリックを使用しました。

（ボタンに）明示的なサイズを指定すると、コンテナのサイズ変更に基づいて常に均等に変換されるとは限らないため、デザインコンプで問題が発生する可能性があります。 それらは常に正方形である必要がありますか？ または、それらの幅はデフォルトのコントロールの高さに基づいて固定されていますか？

現在のTextBoxには、SearchBox、Password Revealボタン、ClearTextボタンなどの統合ボタンがいくつかあります。 XAMLのタッチターゲットは、ボタンが32 x 32 epxであることを提案します-私はそれらを正方形に保ち、そのガイダンスを使用しました。

接頭辞と接尾辞の背景ブラシが決定されることをどのように提案していますか？ 私は既存のシステムブラシを推測していますが、どれですか？

私の例では、テーマの前景色を使用しましたが、不透明度は15％です。 FabricWebのものは10％近くを使用し、XAMLボタンは20％を使用します。
ListLowBrushと同様のブラシ値がありますが、新しいTextBoxAppendixBackgroundブラシが必要になる場合があります。 Text Foregroundは、同じPlaceholderTextForegroundブラシを使用します。

マスキングはこの仕様ではカバーされていません。 「マスクされた」例は、フォーマット文字列に関連することを目的としていますか？
マスクされた例はどのようにフォーマットに対応していますか？
あなたの例はバージョン4のIPアドレスのエントリを示していると思いますが、すべてがうまく収まっているように見えることに基づいて、そこには多くの仮定があるように見えます。 入力できないすべての値に背景とマージンを含める必要がありますか？ 常に表示されない場合はどうなりますか？ あなたの例のように、コンテンツは利用可能なすべてのスペースに合うように引き伸ばされるべきですか？ 使用可能なスペースよりも広いコンテンツをパンする場合、入力できない値に割り当てられたスペースはどのように処理されますか？

私はこれに対するすべての答えを持っているふりをしません、そしてそれがコントロールにどのように視覚的に表示されるかは、マスクフォーマットがコントロールにどのように実装されるかにかかっています。

仕様で取り上げられている例であるIPv4アドレスを使用しました。当初の意図は、提案されている内容を説明することでした（ただし、プレフィックスとサフィックスの例が不足しているため、他の値を選択しました）

他のコントロールがマスキングをどのように処理するかを調べました。値が入力されるとキャレットを移動するインラインテキストを使用するものもあります。 他の人は、電話番号を入力するときに角かっこやハイフンなどを入力します。 Tabキーまたは矢印キーを使用してセグメント間を移動するものもあります。 頭に浮かぶMicrosoftの最も近い例は、Windowsのインストール中にプロダクトキーを入力することです。

追加された要素と同じスタイルを使用すると、美的感覚に合うと思いましたが、これによりコントロールの長さが長くなり、すべてに収まるようになり、インラインでスペースをより有効に活用できる可能性があることを認識しています。

現在TextBoxを使用しているので、 https：//doc.qt.ioのように、ユーザーが変更した値を通知する単一のイベントはありません（つまり、フォーカスが失われ、リターンキーが押された場合）

@adrientetar NumberBoxは、すべての入力が数値としてカウントされるため、名前としては問題ないようです。 IPアドレスには、電話番号、通貨、測定値などの4つの番号があります。

DigitBox、NumeralBoxなどはすべて、Microsoftの命名スタイルに完全には適合しないバリアントです。

また、値は本質的に数値である必要はないため、ValueBoxも少し誤解を招く可能性があります。

@sonnemafと@mdtauk 、私は組み込み計算機のアイデアについてチームに話しました、そして要するに私たちはそれを愛しています-誇張ではありません。 私たちは、皆さんが私たちが提供するコントロールの品質と創造性をすでに高めていることに興奮しています。

これを実現するには、あなたの助けが必要です。 私たちのレポを通じてもたらされる素晴らしいアイデアの連なりを常に把握する方法は、アイデア主導であるだけでなく、シナリオ主導でもあることです。 （この言語を話すと、レポ全体で機能リクエストに具体的な影響力が与えられるため、これを共有します。）

あなたのどちらかがあなたが開発するアプリのいずれかに埋め込まれた計算機の実際のシナリオで私を可能にすることができますか？ コンテキスト、スクリーンショット、ユーザープロファイルがすべて役立ちます。 （あなたが機密詳細を維持することを好む場合は私の電子メールは、私のGitHubのプロファイルにもあります。）@xyzzer、@mrlacey、@robloo、フェリックス-DEV、@adrientetar、および@ArchieCoder @、この機能があればご利用シナリオを共有することを奨励感じてくださいあなたにも興味があります。

この手順を超えて、この機能をボトルネックにする可能性がある唯一のことは、電卓アプリのエンジンでWinUIのDLLサイズを膨らませるリスクです。 これを並行して調べて、実現可能性を調査します。

私は以前、このコントロールを単なる数値型以上のものとして扱う提起しました。

数字と数字のシーケンスを含む文字列には根本的な違いがあります。

これは仕様の最初のドラフトが公開される前だったので、これが考慮され、このコントロールで「従来の数値」と「数字を含む文字列」の両方を処理することが決定されたと思います。

IPv4アドレスは、フォーマットされた数字のシーケンスとして通常表される以外の定義では「数値」であると実際に主張しようとする人はいないと思います。 実際には、4バイトの値です。

@SavoySchuler

• おそらく経費の入力-一部のアイテムが個人的なもので、他のアイテムが仕事の一部である領収書からそれらのアイテムを入力します。
• 請求書を分割するときのレストランアプリ、または多分チップ計算？
• 16進編集アプリ、選択範囲を移動するオフセット値を計算するには？

IPアドレスをサポートするコントロールを持つことは、プラットフォームへの素晴らしい追加ですが、NumberBoxがこのシナリオに適したコントロールではないと思います。

前に述べたように、NumberBoxコントロールは次のようになります。

• 物理キーボードのないデバイスで使用する場合は、 Number仮想キーボードを使用します
• 2つのボタンがあります-/ +
• 電卓でポップアップを表示するか、ユーザーが基本的な算術演算を入力できるようにします

これらの機能はいずれもIPアドレスでは意味がありません。 コントロールのデザインでさえ非常に異なります。

さらに、IPv4アドレスをサポートする場合は、数字ではなく16進数を使用してIPv6アドレスもサポートする必要があることに注意してください。

このコントロールにIPアドレスのサポートを含めず、代わりにUWPの新しいMaskedTextBoxコントロール（IPv4、IPv6、電話番号、郵便番号、SSNなどをサポート）に取り組む方が理にかなっていると思います。 Community Toolkit（https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask）からTextBoxMaskを置き換える/改善するための豊富なUI（@mdtaukによってデモされた）

IPアドレスをサポートするコントロールを持つことは、プラットフォームへの素晴らしい追加ですが、NumberBoxがこのシナリオに適したコントロールではないと思います。

前に述べたように、NumberBoxコントロールは次のようになります。

• 物理キーボードのないデバイスで使用する場合は、 Number仮想キーボードを使用します
• 2つのボタンがあります-/ +
• 電卓でポップアップを表示するか、ユーザーが基本的な算術演算を入力できるようにします

これらの機能はいずれもIPアドレスでは意味がありません。 コントロールのデザインでさえ非常に異なります。

さらに、IPv4アドレスをサポートする場合は、数字ではなく16進数を使用してIPv6アドレスもサポートする必要があることに注意してください。

このコントロールにIPアドレスのサポートを含めず、代わりにUWPの新しいMaskedTextBoxコントロール（IPv4、IPv6、電話番号、郵便番号、SSNなどをサポート）に取り組んでいる方が理にかなっていると思います。リッチUI（@mdtaukによってデモされたもの）およびコミュニティツールキット（https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask）からのTextBoxMask置き換え/改善

@rudyhuyn私はあなたがここで言ったことにほとんど同意します、そして私のイラストは提案されたスペックのためのものでした。

ただし、他の人が言及しているように、マスクされたテキストボックスは数字だけに限定する必要はなく、文字列も含めることができます。 Microsoftのプロダクトキーボックスは良い例であり、0〜9のAZ文字が5セット受け入れられます。

マスキングが分離されたとしても、PrefixTextプロパティとSuffixTextプロパティをNumberBoxコントロールに含めるための良いユースケースがあると思います。 通貨、測定値はすべて、ある種のコンテキストを必要とします。

スピンボタンは純粋に値をインクリメントおよびデクリメントするためのものであるため、これらもNumberBoxコントロールの範囲内にあります。

プレフィックスとサフィックスは、TextBoxコントロール自体のプロパティになる可能性があるため、他のコントロールに継承されます。 （脆弱性が発生した場合は、PasswordBoxの例外が必要になる場合があります）

一般的な値のマスクは、この分離されたコントロールの列挙型（CustomFormatMaskと共に）である可能性があります。 これらのマスクの一部には、英国の郵便番号が英数字である、英国の国民保険番号が特別なフォーマットに準拠しているなど、文化のコンテキストが含まれる場合があります。

SW1A 2AA

英国の郵便番号の例（ダウニング街10番地用）

今朝、返信を送信する前にページを更新できなかったくれたロックスターの皆さんに感謝します！ GitHubで言葉が多用されていることは知っていますが、それを意味します。

@ mdtauk-あなたのモックアップは素晴らしいです。 このコントロールのプロトタイプデザインはまだ作成していません。 モックを分解して、デザイナーがパレットを開始するためのプロトタイプとして仕様に追加してもよろしいですか？ 今日はデザイナーに連絡してリクエストし、 @ mrlaceyであなたのスレッドに返信してもらうことができるかどうかを確認します。 私はあなたのスレッドを読み、まもなくよりきめ細かい詳細で返信します。

@sonnemaf 、ありがとうございました！ コメントをコピーして、プルリクエストの[会話]タブに再投稿することをお勧めし@mdtaukのモックアップなど）に適したフォーラムです。

@mdtauk ：私はあなたに同意します、プレフィックス/サフィックスはTextBoxへの良い追加であり、数字に限定されません、いくつかの例：

• ドメインが常に同じである場合（たとえば、@ microsoft.com）、従業員に電子メールアドレスを入力するように依頼します。
• フォームが常にW-始まる場合は、フォームの名前を入力します

NS...

別のチケットを開いて、ディスカッションを開始する必要があります。

@rudyhuyn IPアドレスのようなものをサポートする機能ではなく、電話番号や郵便番号をサポートする機能が機能していると思いますか？
私の考えでは、あるものを制限し始め、他のものを制限し始めない場合、対象となるもののルールを非常に明確に定義する必要があります。
整数や浮動小数点数などとして表示できる値をサポートするだけで、物事が非常に明確になり、それでも多くの値を提供するコントロールが作成されます。

@SavoySchuler私のデザインは完全に自由に使用できます。貢献しているすべての人のコントロールを視覚化できるように、デザインを投稿しました。

@rudyhuyn MaskedTextBoxまたはFormattedTextBoxの提案を投稿する場合は、より重要になる可能性があります。 NumberBoxと同様に、私のデザインがそのような提案に含まれることを嬉しく思います。必要に応じて、より多くの例を作成できます。

@mrlacey電話番号（書式設定文字を除く）は純粋な数字ですが、計算のユースケースには該当しないため、マスクされたTextBoxに適していますか、それともNumberBoxでこれらのサポートを提供することに価値がありますか？

コントロールとドキュメントを作成するときは、明確なユースケースと、どのコンテキストでどのコントロールを使用するかが重要な例を示します。

@mrlacey ：私はしません。

前に言ったように、0〜9文字を使用するだけでなく、算術値に関連付けられた実数を分離する必要があります。

IPアドレス、電話番号、SSN、郵便番号は0〜9文字を使用しますが、算術値はありません（2つ追加できます。末尾に「.00」を追加すると、値の意味が変わります。など）。 。 このような場合、値はint / doubleではなく文字列であり、MaskedTextBoxの方が理にかなっています。

さらに、郵便番号は米国では数字のみを使用しますが、カナダでは使用しません。たとえば、IPv6アドレスにはAF文字を含めることができ、電話番号には+記号を含めることができます（555-123-4567と+ 555-123-4567は2つの異なるものです）。電話番号）など...

私の意見を要約すると、NumberBox.Valueは文字列ではなくdoubleである必要があります。

@mrlacey電話番号（書式設定文字を除く）は純粋な数字ですが、計算のユースケースには該当しないため、マスクされたTextBoxに適していますか、それともNumberBoxでこれらのサポートを提供することに価値がありますか？

電話番号は完全に数字（およびフォーマット）で構成されている場合がありますが、それでは番号にはなりません。 それらに対していかなる種類の算術演算も実行できず、意味のあるものを取得できません。
また、プラス記号で始めることもできます。
また、電話番号の先行ゼロの数には意味があります。 数値の場合はそうではありません。
計算や上下ボタンなど、コントロールの他の機能は、「電話番号」には意味がありません。

このコントロールは、情報を失うリスクなしにint / uintまたはdecimalに変換できる値に制限する必要があります。

あなたは、このフォーマットの種類とthumb-から（例えば電話番号とIPv4など）すべてのタイプの数値、文字列の入力のための最高の場所であると考えている場合は必ず、私は適切にこのフィードバックを合成してるようにするには、このコメントに私の親指を、あきらめてくださいNumberBoxが数学と数学的な値のキャプチャに専念するように、その機能を別のコントロールまたは新しいコントロールに延期する必要がある場合は、ダウンします。 （電卓モードや上/下ボタンなどの数学演算をサポートする機能に注意するには、それぞれのAPIを介して有効にする必要があります。）

これが民主的に決定されることを保証することはできません。世界中のお客様に最高の投資収益率をもたらす決定を下すからです。しかし、ここで私が見ていることを検証するのに役立ちます。数値をサポートするためにこれを求める人は誰もいません。文字列とそのための専用コントロールを好むでしょう。

@SavoySchuler操作、インクリメント、デクリメントが可能な数値、および値にコンテキストと意味を追加するプレフィックスとサフィックス。

ここでチームと同期し、いくつかの未解決の質問に関する最新情報を共有したいと思いました。

• 私たちはあなたのフィードバックに耳を傾けており、NumberBoxが数値文字列に適した場所ではないことに同意します。 FormatKindsプロパティとCustomFormatプロパティは、より直感的な方法で数値形式を制御するために、より具体的なAPIに置き換えられました。
• プレフィックスとサフィックスは実際にはTextBoxに属しています（NumberBoxはそこから継承します）。 @ mdtauk 、 @ mrlacey 、または他の誰かに機能リクエストを提案するために数日前に開始します。それ以外の場合は、開始してここにリンクします。 当面は、ローカリゼーション/自動化の出力でNumberBoxがブロックされるのを回避できます。
• NumberBoxの最終フィード（計算、丸めなどの後）は、TextBoxから取得されるTextプロパティの文字列として、および新しいValueプロパティのDoubleとして保存されます。 これらのフィードバックを相互に提供し、一方への変更が他方に反映されるようにする予定です。 これの目的は、できるだけ多くの作業を手から離し、必要に応じて値にアクセスできるようにすることです。
• 仕様のプロパティとしてStepSizeがありませんでした。
• 整数型はDoubleに変更されます。
• 私たちはまだ組み込み計算機のアイデアに誇大宣伝されており、それを洗練するのに役立つより多くのシナリオを探しています。 @mdtauk 、すでにこのフィードバックのポイントに
• 入力の検証に関しては、最初にValueChangedタイプのイベントを送信して、開発者が入力を操作したり、必要に応じて終了/ブロックフォームの送信時に入力を処理したりできるようにすることを目的としています。 修正措置が取られない場合（最小/最大内での強制、無効な文字の削除など）、NumberBoxは代わりにユーザーに入力に関するエラー表示を表示します。 この2つのアプローチにより、開発者は必要に応じて応答できますが、修正をユーザーに任せることもできます。

私がまだ返答している素晴らしい量のフィードバックがありました。 しばらくお待ちいただきますようお願いいたします。こことスペックリポジトリのすべての人に返信します。

「電卓が埋め込まれたNumberBoxのコンセプトアート。」 WinUIコミュニティ、2019年5月。（色付き）

（ @ryandemopoulosの褒め言葉）

@SavoySchulerあなたは、私たちが議論しているタイプのコントロールを使用できるいくつかのシナリオ例を求めました。 私のアプリには良い例かもしれない2つがあります。

ケース1：軸を調整できる2Dグラフ用の設定エディターがあります。

• これには、必要最低限​​の単純な数値入力が必要です。 ここでは、+ /-ボタンをインクリメントすると便利です。
• 値を2倍にしても問題ありませんが、入力は文字を押して検証する必要があります。 ユーザーが「a」を押して入力ボックスに表示することさえできないようにする必要があります。 入力検証によって境界線が赤くなり、ユーザーに警告が表示されないようにする必要があります。無効な値を入力できないようにする必要があります。
• ローカリゼーションは、コントロールによってサポートされ、特殊なケースとして扱われる小数点以下の桁数（コンマ、ピリオドなど）を移動する必要があります（見逃しやすいため、これを取り上げ続けます）

ケース2：以下に示すように、通貨値の入力フィールドがあります。 これはカスタムコントロール「CurrencyBox」です

• これは電卓ボタンを使用することができ、方程式2 + 3を入力する機能は、ここである程度の価値があります（ただし、これは別のコントロールである必要があると思います）
• double値はこれには理想的ではありません。 このタイプのユースケースをサポートするには、Valueの仕様をdoubleからdecimalに変更することをお勧めします。 それ以外の場合は、文字列テキストを解析するのは開発者の責任です。
• ここでは、負の符号が個別に処理される特殊なケースがあります。 これにより、ユーザーがサインを間違えないようにすることがはるかに簡単になります。 しかし、NumberBoxがそれをすぐにサポートすることは実際には期待していません。
• テキストの配置は設定することが重要であり、接頭辞/接尾辞は通貨記号を表示するのに非常に役立ちます（ローカリゼーションは、記号を右に表示するか左に表示するかを知る上で問題になる可能性がありますが、アプリ自体にそのロジックがある可能性があります）
• ユーザーは、外部値またはローカル値の両方を入力できます。 これらの値の両方のNumberFormatInfoとCultureInfoは、UIカルチャとは異なる場合があります。 したがって、ローカリゼーションの場合、コントロールはカスタムNumberFormatInfoへのオーバーライドをサポートする必要があります。

現在、アプリでは、Windows Community Toolkitが、以下のようにTextBoxにプロパティがアタッチされた両方のケースで使用されています。
TextBoxRegex.ValidationMode = "Dynamic"
TextBoxRegex.ValidationType = "Decimal"

いくつかの最後のコメント（申し訳ありませんが、これはとても長いです！）

• ここでは、潜在的に3つの異なるコントロールについて説明していると思います。 バーボーンのNumberBox、方程式と高度な数値入力（電卓ボタン！）を持つことができるCalculatorBox、そして最後に電話番号やIPアドレスなどの非数値入力用のMaskedTextBox。 それらを混乱させてはならず、これらの概念をどのように分割するかについて合意することが、仕様を前進させるための鍵となります。
• 最も基本的で、おそらく最も有用なユースケースの焦点を失うことはできません。入力フィルタリングだけで、有効な数値のみを入力できる、通常の外観のテキストボックスです。 他のすべてのオプションはオフにできるはずです（私は増分+/-ボタンを考えています）
• 解析された値で小数の精度を正確に取得するために、仕様でdoubleからdecimalに変更することをお勧めします。 さらに、整数入力は有理数入力とは異なると考える必要があります。 これはおそらく、API「IsInteger = true」の新しいプロパティであり、10進数のデフォルトから変更されます。

編集：NumberBox.Value型の2進数から10進数に切り替えるアイデアを削除しました。 これがC ++ WinRTの世界に存在すると仮定するのは間違っていました。 そうではなく、代わりに.netコア/フレームワークにのみ存在します。

@robloo 、その最後のコメントについては、WinRTにはDecimal型はありません。

XAMLツールキットのビジュアルツリーデバッガーは、ツールキットのNumericUpDownコントロールに大きく依存するツールであり、マウスのドラッグ、ボタン、キーボードによるインクリメント/デクリメントがすべて重要です。 電卓の入力も役立つ場合があります。

@roblooと@xyzzer 、これはまさに私が探している種類の情報です！

検証/マスキング

@robloo 、私は特にケース1：

• 新しいユーザーがNumberBoxに「two」と入力します。
• NumberBoxは、「ValueChanged」イベントを発生させます。これにより、数値以外の入力を「0」に戻すか、必要に応じて「0」に戻すことができます。 アクションが実行されない場合は、...
• NumberBoxの検証キックが赤く点灯し、数値入力のみが許可されていることをユーザーに通知するエラーメッセージが表示されます（この部分は実際にはまだ完全に合理化されていないため、これは単なる仮説です）。

この一連のイベントは、あなたが作成する必要のある体験を作成する能力をあなたに与えますか？

マスキングが望ましいデフォルトになる可能性があることは理解していますが、先週私のチームが話し合ったことを共有しましょう-代替手段であるマスキングがイライラする可能性があるため、Fluentコントロールでは検証（エラーインジケーター/メッセージ）が優先されるという方向に到達しましたキーボード入力からの出力がない場合、エンドユーザーを混乱させます。 それについて考える別の方法は、検証がユーザーに一定レベルの透明性と情報を提供し、ユーザーが黙って強制されるのではなく、エクスペリエンスをより認識できるようにすることです。 したがって、現在の行動方針は、開発者が高度な検証（TextBoxに間もなく登場）を追加したり、必要に応じてValueChangedイベントを介してマスキングしたりする機会を妨げずに、基本的な検証を組み込むことでした。 理解するには、これは十分に柔軟性があり、推奨されるエクスペリエンスをデフォルトとして提供しながら、すべてのニーズを満たすことができます。

ここであなたはどう思いますか？ これらの概念をさらに構成したり、可能であればさらに優れたエクスペリエンスを構築したりするためのアイデアに興味があります。

値のフォーマット

他のポイント、 @ roblooに、 SpecにDecimalPrecision精度プロパティを追加しました。 この= "0"を設定すると、整数が得られます。 さらに、MinValue = "0"を設定すると、数値を負でない状態に保つのに役立ちます（または、ValueChangedイベントは、入力を絶対値に強制変換するもう1つの機会です）。

スペックをもう確認しましたか？ 私はあなたの経験を完全に可能にするために必要なすべてのプロパティを含めたと思います（検証とマスキングの議論を保留中）が、私が何かを逃したと思うかどうか知りたいです。

マスキングは、キーボード入力からの出力がない場合、エンドユーザーにとって苛立たしく混乱する可能性があります。

100％同意します。 LosingFocus / EnterPressedで検証し、入力した値が検証されない場合はoldValueを復元することをお勧めします。そのため、LosingFocus / EnterPressedでトリガーされ、oldValue / newValueを含むシグナルが最適です。

@adrientetar 、素晴らしいポイント！ それはあなたが作成する必要のある体験ですか？ もしそうなら、ValueChangedイベントに古い値と新しい値の両方を送信させるために何をする必要があるかがわかります。

@SavoySchulerこれは実際にアプリで実行したいことです。コントロールがデフォルトで実行しない限り、自分でその動作を構築します。

もう1つ必要なのは、10の増分の場合はShift +↑/↓、100の増分の場合はCtrl + Shift +↑/↓ですが、100の増分が常に意味があるとは限りません。

素晴らしいポイントです！ コントロールがRangeBaseから派生していることを確認する必要があります。
SmallChangeとLargeChangeの両方を定義し、これらの両方をで使用すること
少なくとも。
呼び出すために使用する標準的なキーボードの組み合わせの例はありますか
UWPのRangeBaseまたはWinForms / ComCtl（？）NumericUpDown？のいずれかで大きな変更があります。

15:50エイドリアンTétarで月、2019年6月3日には[email protected]
書きました：

@SavoySchulerhttps ：//github.com/SavoySchulerそれは私がしたいことです
確かに私のアプリで行う、コントロールがしない限り、私は自分でその動作を構築します
デフォルトでそれ。

もう1つ欲しいのは、Shift +↑/↓で10刻みで
Ctrl + Shift +↑/↓100刻みで、100刻みと考えていますが
持っていることが常に意味があるとは限りません。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
。

確認するために確認しますが、実装するにはキーボードショートカットをアプリに任せる必要があるとかなり確信しています。 私は＃21のアクセシビリティの正当化でこれを試しましたが、新しいキーボードショートカットを導入することは、Windowsによって要求されなかったほとんどすべてがアプリレベルで行われるようになったため、プレイするのに危険なゲームです（TeachingTipはジャンプできたと言われています） F6バンドワゴン）-しかし、ここでコントロールフォーカスが例外を許可するかどうかを確認します！

ビルド2018は、INotifyDataErrorInfoを使用して、TextBoxコントロールの検証状態が発表されたときでした。
これは、現在のテキスト文字列を検証または無効にするためにマスキングとともに使用すると便利です。

編集：アイコンとより厚い下の境界線の色の使用は、色覚異常の状況で、そして白黒で見たときに認識を助けるためです。 スペースが限られている場合は、下部のエラーテキストをアイコンのツールチップとして表示できます。

@mdtaukあなたはこれらのマークアップで驚異的です。 私はこれらを私たちのデザイナーによって実行します、彼らは私にとてもよく似合います！

@SavoySchulerビルド2018で示された例に基づく簡単な外挿

そして、見るべき例がたくさんあります:)

申し訳ありませんが、これはもう1つの長いものです！

@SavoySchuler @adrientetar以下のステートメントで、あなたがどこから来ているのかがはっきりとわかります。 ほとんどの場合、検証を処理するための最良の方法であるとは言いません。 ただし、明らかに数値のみの入力であるため、ユーザーが間違った文字を太く指で触れないようにすることで、実際にユーザーに好意を示している特殊なケースがあると考えなければなりません。

マスキングは、キーボード入力からの出力がない場合、エンドユーザーにとって苛立たしく混乱する可能性があります。

100％同意します。 LosingFocus / EnterPressedで検証し、入力した値が検証されない場合はoldValueを復元することをお勧めします。そのため、LosingFocus / EnterPressedでトリガーされ、oldValue / newValueを含むシグナルが最適です。

それでも、他のアプリをざっと見て、どのように処理されるかを確認することにしました。 ユーザーの操作についてMicrosoftほど研究している人はいないと思うので、参考のためにデスクトップ64ビットバージョンのWordを取り出し、次にUWPバージョンのOneNoteを取り出しました。 それは多かれ少なかれあなたたちが言っていることに完全に同意します。 明らかに数値入力のみであるフォントサイズまたは形状サイズの入力ボックスに、任意のテキストを入力できます。 主にフォーカスの喪失を検証し、最後の有効な入力に戻ります。

| タイトル| 写真| コメント|
| ------ | ----- | ------------ |
| UWPOneNoteフォントサイズエントリ| | キーボードから任意の値を入力できます。自動的に検証され、フォーカスが失われると最後の有効な値にリセットされます。
| デスクトップのWordフォントサイズの入力| | キーボードから任意の値を入力できます。フォーカスが失われると自動的に検証され、無効な場合はエラーメッセージが表示されます。 [OK]をクリックすると、最後の有効な値にリセットされます。 |
| UWP OneNote2Dグラフ| | キーボードから任意の値を入力できます。 無効な値は単に無視され、最後の有効な入力が計算に使用されます（フォーカスが失われた場合は検証されません）。 インクリメント+/-ボタンを押すと、最後の有効な入力を使用してインクリメントします。 |
| デスクトップのWordの形状サイズの入力| | キーボードから任意の値を入力できます。フォーカスが失われると自動的に検証され、フォーカスが失われると最後の有効な値にリセットされます。 |

だから私は自分が間違っていることを証明したと思います。つまり、あなたに同意する必要があります！

サイドコメント：

• 他の誰かが以前に述べたように、NumberBoxがタッチ/仮想キーボードでキーボードフォーカスを持っている場合、数字キーボードのみが表示されます。
• 左側の増分と右側の増分は、スタイリングの観点からここで説明する興味深いアイデアです。 それはいいですね！
  

• 新しいユーザーがNumberBoxに「two」と入力します。
• NumberBoxは、「ValueChanged」イベントを発生させます。これにより、数値以外の入力を「0」に戻すか、必要に応じて「0」に戻すことができます。 アクションが実行されない場合は、...
• NumberBoxの検証キックが赤く点灯し、数値入力のみが許可されていることをユーザーに通知するエラーメッセージが表示されます（この部分は実際にはまだ完全に合理化されていないため、これは単なる仮説です）。
  この一連のイベントは、あなたが作成する必要のある体験を作成する能力をあなたに与えますか？
  ここであなたはどう思いますか？ これらの概念をさらに構成したり、可能であればさらに優れたエクスペリエンスを構築したりするためのアイデアに興味があります。

私は、入力検証を追加することがプラットフォーム全体にとって素晴らしいことであることを完全に理解し、同意します。 ただし、基本的には、数値の特別な処理を行わずに入力検証について説明しただけです。 したがって、値を自動的に解析する以外に、NumberBoxはどのように使用されますか？ 開発者として、データ検証を備えたTextBoxは多かれ少なかれ同じようです。

上記の例に基づいて、すぐに使用できる機能は両方のアイデアを組み合わせたものである必要があり、 @ adrientetarが言っていることだと

イベントに関しては、そのユースケースがより明確になった場合は、テキストの変更をキャンセルする機会があります。 したがって、ValueChangedに加えて、ValueChangingおよびTextChangingイベントを使用して、入力を比較およびキャンセルできるようにすることをお勧めします。 間違いなくOldValueとNewValueが必要ですが、これにより、少なくとも必要に応じてすばやくOldValueに戻すことができます（ただし、イベント内でTextValueを変更するとUWPがクラッシュするのが好きです）。

スペックに関して：DecimalPrecisionの良いアイデアですが、それを調べてコメントを追加するにはもっと時間が必要です。 デフォルト値はString = Empty、Value = Nullである必要があり、インクリメント+/-ボタンが押されると、値は空ではなくゼロとして扱われる必要があるなど、微妙な違いがたくさんあります。

@mdtaukこんなにいいイラストをこんなに早く作るのは人間的にはできないはずです:)

@robloo親切なコメントありがとうございます。 私はあなたの+/-に関して簡単なコメントをするだけです
このNumberBoxが実行できる数学演算との混同を避けるために、現在のスピンボタンで使用されている上と下の記号を使用する方がよい場合があります。

iOSは「ステッパー」コントロールを使用しますが、テキスト入力は別個であり、インライン計算はありません。

これが私が見つけた他のいくつかのデザインです

私が選んだデザインは、このコントロールに対するMicrosoftの典型的なスタイルに適合しているようですが、それが最良の選択であるか、正しい選択であるかです。 他の人がどう思うか聞いてみたいです。

編集：代替フォームのモックアップをいくつか追加しました（ただし、最初のアイデアが最適だと思います...）

+/-の場所については@mdtaukに同意します。最初の場所が最適です。

XAML ControlTemplateがあるため、ユーザー（開発者）は他の2つのレイアウトのカスタムテンプレートをいつでも作成できます。

@robloo 、詳細な回答について謝罪する必要はありません-特に彼らがいくつかの良い笑いを詰め込んでいるとき！ タッチ/仮想キーボードの優れたアイデア-開発者/チームが実行する仕様の[未解決の質問]セクションに追加し、許容できないパフォーマンスのオーバーヘッドがないことを確認しました。 それを実現できれば、ユーザーにとっては素晴らしい便利だと思います。

あなたは検証に関して素晴らしいポイントを持ち出します...

[1]質問時間：開発者がこの動作をキャンセルし、代わりにエラーインジケータまたはメッセージを実行/発生させるイベントを公開しながら、受け入れられない入力を以前の値に自動的に戻す検証システムに反対する人はいますか？

視覚的には、あなたが投稿した例では、互いに素なUpDownButtonsのメリットがわかります。 @mdtaukと@sonnemafはデフォルトの正しい方向に思います。 UpDownButtonの近接性は、異なる（ただし離れていない）入力の前後の結果をテストする場合でも、オーバーステップされた入力を修正する場合でも、真の利便性です。 距離は、改善された設計または機能によってメリットがない限り、エクスペリエンスに回避可能な労力を追加するように見え、これをコントロールの機能部分として明確にグループ化するのとは対照的に、プレフィックス/サフィックスのプロパティ/ラベル付けの明確さを損なう可能性があります。 192 [+]

互いに素なUpDownButtonのシナリオがあると思います。 私の心は、最小限の単方向入力を期待するタスク、または開発者が入力ミスをより難しくしようとするタスクに行きます。 これは、たとえば映画やコンサートのチケットを購入するときに、いくつかのアプリケーションやWebサイトが提供するエクスペリエンスだと思います。

私の質問は...

[2]質問時間：互いに素なUpDownButtonsを使用してNumberBoxを作成するためにXaml ControlTemplateに依存する必要がありますか（つまり、これは、すぐにサポートすることを正当化するのに十分なほど一般的ではありません）、またはUpDownButtonsが連続して表示されるかどうかを設定するためのプロパティを含める必要があります対ばらばら？

フルーエントデザインシステムのガイドラインがこの2番目の質問を上書きする可能性があるため、この質問について@chigyにpingを

UpDownButtons会話のアクセシビリティに関する考慮事項を含める必要があります。UpDownButtonsを相互に近接させることで、ナレーター/スクリーンリーダーユーザーの概念を明確にすると同時に、キーボードナビゲーションユーザーのナビゲーション効率を維持できます。これを妥協しないことも重要です。

コントロールの幅があまり広くない場合は、矢印を垂直に積み重ねる必要があります（アプリで必要なことはわかっています）。 たぶん、コントロールはその設定された幅に反応するようにすることができますか？ 彼らがそれが理にかなっていると思うなら、それをそのように指定するのは流暢な設計ガイドライン次第です。

3つの未解決の質問で提案を更新しました。

コンセプトデザインをありがとう@mdtauk ！

@adrientetarあなたがそれを必要として指摘してくれてうれしいです。 これらの3つの構成に列挙型が必要なように聞こえますか？

コントロールの幅があまり広くない場合は、矢印を垂直に積み重ねる必要があります（アプリで必要なことはわかっています）。 たぶん、コントロールはその設定された幅に反応するようにすることができますか？ 彼らがそれが理にかなっていると思うなら、それをそのように指定するのは流暢な設計ガイドライン次第です。

コントロールが使用可能なスペースの量を認識して応答できるようにする提案がありました。＃677これは、コントロールが狭くなるにつれてスピンボタンを再配置するために使用できます。 たぶん、MinWidthに似たNarrowWidthのプロパティが必要なのか、それともNumberOfDigitsがヒントとして機能する必要があるのでしょうか。

グレー表示されたテキストの例について-これにより、ユーザーが最終結果がどうなるかについてのヒントとしてではなく、表示される値を入力するように促される可能性があるのではないかと心配しています。 PlaceholderTextと同じように見えます。

AccentColorとさまざまなフォントの太さを使用して目立たせるのはどうですか

素晴らしいリンク、@ mdtauk。 これが私たちが降りる道路である場合、[Auto、Vertical、Horizo​​ntal、Detached]などの値を持つ列挙型でこれを処理できると思います。ここで、AutoはコンパクトさがVerticalを要求するまでHorizo​​ntalを優先します。 考え？

また、画像を更新しました！ グレー表示されたテキストがプロンプトのように見える可能性があり、その後に続くと、「=」が原因でエラーが発生する可能性があることは正しいと思います。

素晴らしいリンク、@ mdtauk。 これが私たちが降りる道路である場合、[Auto、Vertical、Horizo​​ntal、Detached]などの値を持つ列挙型でこれを処理できると思います。ここで、AutoはコンパクトさがVerticalを要求するまでHorizo​​ntalを優先します。 考え？

最初の考えは、コンテナ内の数は、垂直方向が必要になる場所で十分に大きくなるでしょうか？ AutoCompleteBoxは検索ボタンを動かさず、文字列は通常数字よりも長くなります。

それが純粋に利用可能なスペースに依存するものである場合、自動応答動作（その提案が先に進められた場合）は列挙型よりも優れています。 コントロール自体にオプションを開発者に与えると、コントロールの一貫した使用法が得られなくなる可能性がありますが、これは、githubで私たちだけが規定するのではなく、ユーザーの調査で検討する必要があると思います。

開発者は、コントロールに別のレイアウトが_本当に_必要な場合は常にコントロールを再テンプレート化するオプションがあり、A）デフォルトとの両方を作成する作業に進む場合は、そのための代替スタイルを含めることができます。垂直スタイルとテンプレート-およびB）両方のスタイルが適切にテストされていることを確認します

@mdtauk上/下の記号が最適であることに同意します。 入力の反対側に矢印がある例を示したかっただけです。 前述のように、これは、タッチベースのUIではほぼ必須である間違ったものをユーザーが押さないようにするのに役立ちます。 OneNoteから提供した例には、たまたま+/-記号が含まれていましたが、記号自体を無視するように追加する必要がありました。

@SavoySchuler

[2]質問時間：互いに素なUpDownButtonsを使用してNumberBoxを作成するためにXaml ControlTemplateに依存する必要がありますか（つまり、これは、すぐにサポートすることを正当化するのに十分なほど一般的ではありません）、またはUpDownButtonsが連続して表示されるかどうかを設定するためのプロパティを含める必要があります対ばらばら？

UWPが最初に作成されたとき、それは最初にタッチであったことを私は知っています-したがって、ばらばらのUpDownButtonsは間違いなくより良いでしょう。 それ以来、タッチファーストの要件は緩和され、ユーザーがマウスなどの正確な入力方法（移動距離が短い）を使用している場合は、ボタンが隣り合っている方が確実に優れています。 これはユースケースに依存するため、列挙型がUpDownButtonsの表示方法を指定するのに役立つことに同意します。

列挙値については、いくつかの状態について説明しました。一般化すると、さらにいくつか追加できます。

• 分離水平：左側に下向き矢印、右側に上向き矢印
• 分離垂直：下部に下向き矢印、上部に上向き矢印
• 左：左側にある下向き矢印と上向き矢印の両方（水平方向）
• 右：下向き矢印と上向き矢印の両方が右側に並んでいます（水平方向）
• 上：上にある下向き矢印と上向き矢印の両方（垂直方向）
• 下：下矢印と上矢印の両方が下に並んでいます（垂直方向）

これらすべてが複雑になりすぎた場合（すぐにそうなりますが）、XAMLでの自分のユースケース用にコントロールを再テンプレート化できてうれしいです。

別のアイデアを捨てるだけです。ばらばらのUpDownButtonのシンボルの方向を変更することも、ある程度意味があるかもしれません[<] 123 [>]。 アプリごとにスタイルを変更できることは確かですが、この追加された複雑さは無視してかまいません。

また、アクセシビリティの懸念のいくつかは、私が例を引き出したOneNoteですでに対処されている可能性があります。

@roblooあなたが言及した左右の配置は、目立たない設定ではなく、RtLとLtRのローカリゼーションのために保持する必要があると思います。

以下は私の意見です

また、テキストフィールドの上にボタンを配置することが意味的に意味があるかどうかもわかりません。ボタンに指を置いているときは言うまでもなく、数字が変化しているのがわかりにくい場合があります。

コントロールにすべての組み合わせを組み込むと、混沌とした使用法になります。差し迫った必要がある場合は、再テンプレート化することでこれらすべてを実行できます。

テキストフィールドの下のボタンは、スペースが限られた領域で、またコントロール自体のオプションとして、ボタンをタップするのにはるかに大きくなるため、使用できる場合があります。 それがコントロールにバンドルされたスタイルであるか、またはその間の列挙型であるかどうか。

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

簡単な質問の可能性のある提案：理論的には、数字ボックスでは、数字ボックスにのみ数字を入力できるはずです。 書かれた数字を解析し、これらのフィールドの実際の数字に変換するのはどれほど難しいでしょうか？

例えば：
1 + 2 = 3
翻訳する
1 + 2 = 3

または
1プラス2は3に等しい
に変換されます
1 + 2 = 3

それはただのアイデアです。

簡単な質問の可能性のある提案：理論的には、数字ボックスでは、数字ボックスにのみ数字を入力できるはずです。 書かれた数字を解析し、これらのフィールドの実際の数字に変換するのはどれほど難しいでしょうか？

例えば：
1 + 2 = 3
翻訳する
1 + 2 = 3

または
1プラス2は3に等しい
に変換されます
1 + 2 = 3

それはただのアイデアです。

英語にとって、それは理にかなっています。 これらの文字列を他の言語に翻訳して解析する必要がある場合、問題になります。 そして、英語の単語を入力するポーランド語のユーザーはどうですか？

現在のところ、0〜9の数字、小数、数字の区切り記号、および数学演算子の形式についてのみ説明しました。 ただし、他の番号システムにも対応する必要がある場合があります。

言語翻訳を追加することは大きな努力であり、その利点が何であるかは明確ではありません。

ここで、このコントロールが音声入力によって操作される場合は、番号または操作を話します。これには、話されている言語の解釈が含まれる場合があります。

ナレーター：
「値のないピクセル番号ボックス」

ユーザー：
「百二十八ピクセル」

[128 _________ | px]

ユーザー：
「64ピクセルを追加」

[192 _________ | px]

ナレーター：
「百九十二ピクセル」

[1]質問時間：開発者がこの動作をキャンセルし、代わりにエラーインジケータまたはメッセージを実行/発生させるイベントを公開しながら、受け入れられない入力を以前の値に自動的に戻す検証システムに反対する人はいますか？

入力したテキストが無効になった場合、値が古いものに変更されるのはなぜですか？ 「最後に知っているValue 」を維持しようとすることは、コントロールが責任を負う必要があることではないと思います。 コントロールに単一の現在の値（またはエラー状態）を処理させ、アプリにValueChangedイベントを介して必要に応じて追加の履歴処理を処理させます。

初期バージョンでは、必要に応じて再テンプレート化できるため、上/下ボタンの単一の位置をサポートするだけで問題ないと思います。
アップ/ダウンボタンの位置を決定する能力が必要とみなされる場合は、追加された列挙型が持っている必要が削除する必要がありますUpDownButtonsEnabled財産をとの列挙値Hidden可能性があり代わりに追加されました。
上/下ボタンの位置を操作するためのサポートが組み込まれていると、提供されているオプション以外のテンプレートを調整する必要がある人にとっては複雑になることにも注意してください。

@shaheedmalik 、そして優れた直感的なアイデア。 スペックをチェックしましたか？ その入力をインターセプトし、入力された数値を手動で数値に解析できるValueChangedイベントがあります。これにより、特に特定の言語を念頭に置いている場合に、作成できる可能性があります。 コントロールのデフォルトV1でグローバル言語パーサーをベイク処理することに関しては-

@mrlaceyは、あなたがレビュー@roblooさんへのチャンスが持っていたNumberBox同様のコントロールのWindows全体で使用の比較分析を？ これらのフィールドを最後の有効な数値のみの入力にリセットする動作には、実際にはシステム全体の前例があります。つまり、このパターンに合わせるために、コントロール自体または開発者ガイドラインのいずれかが押されます。 私の傾向は、このコントロールを標準のWindowsエクスペリエンスに一貫して調整し、エコシステムの他の部分から逸脱する動作を標準化し、後者が作成するようにこのシステムのデフォルト動作を作成するためのガイドラインを主張するのではなく、必要な逸脱の道を作成することです一般的なケースでは簡単で効率的です。 意見の相違をお勧めします。これによりコントロールが不必要に複雑になると思われる場合、またはおそらくこの前例を再評価する必要がある場合は、お知らせください。

| タイトル| 写真| コメント|
| ------ | ----- | ------------ |
| UWPOneNoteフォントサイズエントリ| | キーボードから任意の値を入力できます。自動的に検証され、フォーカスが失われると最後の有効な値にリセットされます。
| デスクトップのWordフォントサイズの入力| | キーボードから任意の値を入力できます。フォーカスが失われると自動的に検証され、無効な場合はエラーメッセージが表示されます。 [OK]をクリックすると、最後の有効な値にリセットされます。 |
| UWP OneNote2Dグラフ| | キーボードから任意の値を入力できます。 無効な値は単に無視され、最後の有効な入力が計算に使用されます（フォーカスが失われた場合は検証されません）。 インクリメント+/-ボタンを押すと、最後の有効な入力を使用してインクリメントします。 |
| デスクトップのWordの形状サイズの入力| | キーボードから任意の値を入力できます。フォーカスが失われると自動的に検証され、フォーカスが失われると最後の有効な値にリセットされます。 |

@ mdtauk 、LTRおよびRTL言語に関するコメントと、UpDownButtonsが表示されるコントロールの側面に注意してください。 これをローカリゼーションの専門家が実行して、これが考慮すべき考慮事項であることを確認します。

@mrlaceyブール値が列挙型に対して冗長になることも正しいです。 別の構成が必要かどうかをすぐに確認しようと思います。

@adrientetar 、あなたは垂直ボタンの主要な顧客です。 スペースの制約をよりよく理解するのに役立つ画面の断片やコンテキストはありますか？ @mdtaukは私にこの返信で以前に考えさせました：

最初の考えは、コンテナ内の数は、垂直方向が必要になる場所で十分に大きくなるでしょうか？ AutoCompleteBoxは検索ボタンを動かさず、文字列は通常数字よりも長くなります。

@SavoySchuler （最後の適切な値へのリセットに関して）仕様により、 @ roblooのレビューのコントロールよりも、エラー処理とレポート用の機能がNumberBoxに追加されるため、これらの機能をさらに活用したいと考えていました。

このことを考慮：

1. AllowsCalculations=True NumberBox
2. 手動で1100を入力し、タブで次のコントロールに移動します
3. これは入りたかったものではないことに気づきます
4. コントロールに戻り、「99x12」と入力します
5. タブを次のコントロールに移動すると、値は「1100」の表示に戻ります（「x」は「*」と同じではないため、計算ステップで失敗します。または、「x」が失敗した場合に失敗する他の無効な計算を検討してください。押すと表示されません。）
6. 計算の結果ではない値が表示され、エラーメッセージは表示されず、入力された合計は失われるため、何が起こったかの記録はありません。

ステップ5で次のコントロールにタブで移動したときに発生したいのは

• 「99x12」はText値のままです
• エラー状態が表示されます。
• ValueChangedイベントがトリガーされ、渡されました（Text = '99 x 12 '、OldValue = 1100、NewValue = Double.NaN）
• その後、ユーザーは何かが間違っていたことを確認できます
• ユーザーは、合計を再入力しなくても問題を修正できます。
• コード/アプリロジックは、必要に応じて適切な処理を実行できます。

エントリ時に最後の既知の適切な値に自動的に戻る場合：

• 必須フィールドに値が入力されていない場合とは別に、エラー状態が示されますか？
• ValueChangedイベントを発生させることの価値は、無効な状態を報告することは決してないため、大幅に減少していませんか？

@ SavoySchuler @ mrlacey他のMicrosoftアプリでそれらの例を見て...

モーダルポップアップは除外する必要があります。 代わりに、これはコントロール自体の検証状態によって処理される必要があります。

画像

無効な値がある場合、おそらくコンテンツはその無効な状態のままである必要がありますが、コントロールがフォーカスされている間のみです。 フォーカスが失われると、テキストフィールドの値は元に戻りますが、検証通知にはユーザーが入力した内容が表示されますか？

InputScope：NumberまたはFormulaNumber？

前に述べたように（PRコメントで）、 FormulaNumberは、ここと仕様のすべての計算例に含まれる「スペース」は含まれていません。 FormulaNumberには、このコントロールでサポートされていない数式も含まれています

私は「数」に投票します

番号

FormulaNumber

@SavoySchulerつまり、デスクトップアプリを作成しているだけです（独自のバージョンのExcelなどを作成しようとはしていません）。 矢印を完全に無効にするだけだと思います。マウスをドラッグするだけで十分だと思います。 マウスのドラッグが計画されている場合、ユーザーはその場合に可能な変更の範囲をプレビューしたいので、おそらく値の変更はすべての変更で発生するはずです。 サイドバー：

ところで、TextBoxのコンテンツは垂直方向に中央揃えされません。これは、VerticalContentAlignment = "Center"の場合です。

これは、Paint 3Dが使用する種類のプロパティサイドバーに似ています（これは、より細い明るい境界線を備えた独自のコントロールスタイルを使用し、接尾辞プロパティのように見えます）

ドラッグを実装しない場合は、Paint 3Dが行ったことをいつでも実行でき、スライダーをNumberBoxにバインドできます。

また、コントロールにドロップダウンスライダーを配置することで、Adobeが行うことと似ています。

@adrientetarあなたはそこでNumberBoxの独自のバージョンを実行しているようです。 フォントには説明が必要なディセンダーがあるため、TextBox内のテキストにはベースラインの配置があります。

NumberBoxの場合、視覚的に中央に配置された文字を使用する場合がありますが、これらのNumberBoxは、ComboBoxのような標準のTextBoxまたはTextBoxから派生したコントロールの横に配置すると整列しません。

デフォルトのテンプレートとスタイルを作成するときは、さまざまなWindows.UI.Xaml.Documents.Typographyプロパティを考慮する必要があります...

• Typography.CaseSensitiveForms
• Typography.NumeralAlignment + Typography.NumeralStyle（比例よりも表形式の方が望ましい場合があります）

@mrlacey 、あなたは有効な議論をします。 @adrientetarからの応答に基づいて、次のシナリオはどうでしょうか。

値/テキスト変更イベントは_すべての_変更時に発生するため（ドラッグ/スクロールユーザーが範囲をテストしている場合）、「Enter」が押される/フォーカスが失われるまでエラーメッセージとインジケーターが表示される検証を継続的に実行できます。この場合、検証値のオーバーライドが開始され、最後の適切な値が上書きされます（その動作がそれぞれのプロパティによって無効にされている場合を除く）。

今日の午後、チームとチャットして、その一定のイベントの発生/検証が現実的なアイデアであるかどうかを検証します。そうでない場合は、別の方法で範囲を構築する可能性があります。

@mdtaukですが、検証の視覚的表現に関する主張は正しいと思います。 @LucasHaines 、私を再確認できますか？

@jevansaks 、以下のInputScopeの考慮事項を検討することができますか？

前に述べたように（PRコメントで）、 FormulaNumberは、ここと仕様のすべての計算例に含まれる「スペース」は含まれていません。 FormulaNumberには、このコントロールでサポートされていない数式も含まれています

私は「数」に投票します

番号

FormulaNumber

@SavoySchuler re this

値/テキスト変更イベントは変更のたびに発生するため（ドラッグ/スクロールユーザーが範囲をテストしている場合）、「Enter」が押される/フォーカスが失われるまでエラーメッセージとインジケーターが表示される検証を継続的に実行できます。この場合、検証値のオーバーライドが開始され、最後の適切な値が上書きされます（その動作がそれぞれのプロパティによって無効にされている場合を除く）。

ValueChangedイベントは、実際のValueが変更されたときにのみ発生し、 Textが変更されるたびに発生するわけではありません。

その動作がそれぞれのプロパティによって無効にされていない限り

この新しいプロパティは何ですか？

より頻繁なイベントが、最後の既知の適切な値に戻ったときに誤った値とエラー状態が失われる問題にどの程度対処するかはわかりません。
これが実際にどのようになるかを理解するには、ここでいくつかの実験が必要だと思います。 （時間を見つけることができれば...）

関連するメモについて。

TextBoxから継承された既存のTextChangedイベントは、コンシューマー用に変更されないと想定しています。 しかし、 TextChangingイベントはどうですか？ これは、新しいコントロール固有の処理が行われる場所ですか？ コントロールのコンシューマーもこのイベントを処理できますか？

同意しました-調査する価値はありますが、回避するのが最善です。 検証に関するセクションを改訂し、デフォルトで無効になっているIsInvalidInputOverwrittenプロパティを追加しました。 誰もが次のことについてどう思いますか：

• 非数値の公式または最小/最大値を超える入力は、ます。
• 開発者は、ValueChangedイベントまたはTextChangedイベント（変更されたプロパティと更新されるプロパティを公開する）をインターセプトし、入力検証警告が表示される前に無効な入力を手動で操作できます。
• IsInvalidInputOverwrittenプロパティを有効にすると、入力検証の警告が表示されずに、無効な入力が最後の有効な状態に戻ります。 たとえば、IsInvalidInputOverwrittenが有効で、StepSize = 0.2、MaxValue = 3.0で、値2.9がインクリメントされると、3.1は無効として登録され、2.9に上書きされます。

これの多くは、検証が入力全体または入力後に行われるべきかどうかという質問に要約できます。 私はパフォーマンスのために、そして入力時に検証を受け取った経験が不快でアクセスしにくい可能性があるため、私は頼りにしています-これは上記を私の現在の好ましい実装に導きます。

無効な値を入力しようとすると、FWIW、Adobe Photoshop、およびIllustratorは以前の値に戻ります。 これには計算動作がありますが、測定単位の接尾辞はテキストの一部であり、それ自体が検証の問題を引き起こす可能性があります:)

私が自分自身と矛盾したアイデアを投げ入れたかった-インクリメント/デクリメント機能を備えたソート番号ボックスを持っていた過去の多くの経験で、最小値を下回ると最高値に戻ることを思い出すことができます、およびその逆。 ここで_ValuesWrap_プロパティのようなものが意味をなすかどうかを確認したかったのです。

これは明らかにすべての場合に意味があるわけではありませんが、限られた数値範囲の場合、AgeやDateOfBirthエントリなどの場合、またはその他の小さな範囲の場合に数値が折り返されると想定することは、これまで私にとって直感的でした。 一方、これは、複数選択選択ボックスが使用されているためにのみ発生する場合があり、通常、これらは停止する代わりに値をラップします。 正当化または必要性があるかどうかを確認したかっただけです。もちろん、追加の作業を伴うonValueChangedイベントを介して、開発者側でも実装できる可能性があります。

cc @SavoySchuler

素晴らしいアイデア、@ KevinTXY。 ここにいる開発者のいずれかがそのようなものを必要としている場合は、それを追加することを検討できます！

質問時間：16進数または2進数のサポートが必要であることを正当化する実際のアプリシナリオはありますか？ 最大/最小値をラッピングしますか？

ここで、ValuesWrapプロパティのようなものが意味をなすかどうかを確認したかったのです。

ええ、角度プロパティが好きな場合は、359→0、基本的にはmod 360にします。面白いのは、MaxValueは包括的であるため、コントロールをサブクラス化する必要があったことです（Qtにありました）。したがって、359またはを指定できます。 360ですが、私は本当に359.99を書きたいのですが、360は書きたくありませんでした（つまり、≤ではなく<が欲しかったのです）。

QSpinBoxには、その目的のためのラッピングプロパティがありますhttps://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler 16進数に関しては、16進エディターがそれを望んでいるのではないかと思いますが、それは本当にニッチなユースケースのようです。コントロールがサブクラス化されやすいことを確認するだけで、考えられるすべてのものをサポートする必要はありません。 Qtでは、コントロールにテキストボックス文字列からオーバーライド可能な数値（intまたはdouble）に変換するメソッドがあります。

たとえば、IsInvalidInputOverwrittenが有効で、StepSize = 0.2、MaxValue = 3.0で、値2.9がインクリメントされると、3.1は無効として登録され、2.9に上書きされます。

その場合、おそらくMaxValueにクランプすることができます。

@SavoySchler @xyzzer @mrlacey Twitterで、予測テキスト入力を提供する何かが20H1に登場するのを見ました。

これは、先ほど説明したプレビュー完了機能に干渉する可能性があり、NumberBoxコントロールで何かを抑制する必要がある場合があります。 Win32とXAMLコントロールに来ると...

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

16進数または2進数の処理は、電話番号や郵便番号などの「数字のように見える文字列」の処理よりもさらに特殊なシナリオだと思います。 （そして独自の複雑さをもたらします）
そのため、NumberBoxコントロールの範囲外である必要があると思います。

プレビュー計算機能について言えば、それが見落とされた場合に備えて、ユーザーにオン/オフの選択を与えることを提案します。 したがって、おそらく次のようなプロパティを追加します

public bool ShowPreviewResult { get; set; }

なぜプレビュー結果を表示するのですか？ 🤔ユーザーが結果に応じて数式を変更するのとは異なり、必要な結果がわかっている場合は、すぐに入力するだけです

なぜプレビュー結果を表示するのですか？ 🤔ユーザーが結果に応じて入力しているものとは異なり、必要なものがわかっている場合は、すぐに入力します

コントロールの機能の1つは、 32 * 4のように計算を入力できることです。これは128として解決されます。プレビュー機能は、コントロールがフォーカスを失うか、Enterキーが押されたときの結果を示します。

@adrientetarプレビューは

皆様、フィードバックをありがとうございました！ 今のところ、2進数または16進数のサポートに対する差し迫った必要性や関心を保証するものはないようです。 また、必要に応じて、サブクラス化、新しいコントロールとして提案、またはV2用に提案することもできます。

@SavoySchulerは、「16進数または2進数のサポートが必要であることを正当化する実際のアプリシナリオはありますか？」に関して、1つの例はWinUI独自のColorPickerコントロールです。 16進入力ボックスが含まれています。 また、他の多くの番号エントリTextBoxも含まれています。 新しいコントロールを検証する方法として新しいNumberBoxコントロールを使用するように、ColorPickerを更新する可能性を検討する価値があるかもしれません。 NumberBoxがColorPickerの現在の実装を簡素化できれば、それは勝利です。

テキストボックスの細い境界線のスタイルが@chigyとWinUIデザインチームの意思決定を

@ kmahone-同意しました。 今朝のウォータークーラーでおっしゃったように、TextBox +ローカル検証ロジックのインスタンスをNumberBoxに置き換えることで、ColorPickerから多くのコードを削除できることは、それ自体がメリットになる可能性があります。

@ mdtauk-モックアップが信じられないほどに見えると何度も言いましたか？ これらはまもなく仕様に組み込まれます。

@SavoySchulerWindowsデザインチームが

確かに、@ mdtauk！ 近い将来、 @ chigy （＃524で素晴らしい仕事をするのに忙しい）との設計収束の会話に

みなさんの議論に感謝します。今年の夏、インターンとしてこの機能に取り組むことに興奮しています。

誰かに関係がある場合は、次のリポジトリでコントロールのC＃プロトタイプを開始しました。
https://github.com/KevinTXY/NumberBox

これは基本的にC＃/ UWPを学ぶのは初めてなので、ゆっくりと進んでいきます。誰かがそれを見てくれたら、もっとうまくできることについてフィードバックをいただければ幸いです。

次の機能が大まかに実装されています。

• 数値入力検証（検証提案の仕様にはまだ従いません。そのためのコードを待ちます）
• 価値の保存/バインド
• ゼロトリミング
• 電卓/数式入力の完全なサポート

現在、スピナーボタンとテストアプリのほか、最小/最大検証に取り組んでいます。

乾杯！

タイムラインの更新！

今日（木曜日）にWinUIチームで検証する仕様に、いくつかの更新、提案、フィードバックを統合しました。 そうすることで、V1のAPIと動作コンポーネントを多かれ少なかれ完成させたいと思っています。

次に、入力とアクセシビリティ、データとインテリジェンス、およびビジュアルコンポーネントに移動します。

最後のステップは、ドキュメントの整理とガイドラインの作成です。

ばらばらで連続したオプションは、Microsoftのファーストパーティアプリ/シェルUIがWPFまたはWin32のいずれかで実行する必要があるユースケースがなければ、非常にニッチだと思います。

それを含めたい場合は、オプションではなく、コントロールに適用できる含まれているスタイルにします。 再テンプレート化されたNumberBoxコントロールは、新しいテンプレートでそのプロパティをどのように処理しますか？

このモードを含める必要があるというコンセンサスがある場合は、 SpinButtonPlacementModeの一部として列挙値になることをお勧めします。 このオプションが何と呼ばれるかわからない。 _Straddled_はおそらく十分に専門的ではありません笑、そして私は_Bookended_がこれ以上良いかどうかわかりません。

Edgeの最新のCanaryビルドを見ていたら、NumberBoxコントロールに最も近い<input type="number"/>のデザインを見ました。

このイメージを共有しようと思っただけです。

@ mdtauk-同意しました

名前のトピックに関して、@ Felix-Devは、SpinButtonが最も直感的またはよく知られた名前ではない可能性があるという仕様を正しく明らかにしました。 SpinBoxとUpDownButtonsは、Windowsエコシステムでも優先されます。 これについてはもうすぐ詳しく説明しますが、これらのオプションのいずれかに反対するケースがある場合はお知らせください。

@ mdtauk-共有していただきありがとうございます！ 私もカナリアを運営しているので、何か学ぶことができるかどうか、または開発の調整を提案する余地があるかどうかを確認します。

@SavoySchuler Fluent Controlsフラグを有効にしています（実験的なコントロールを含む）

WinUIの実装は、Fabric WebとEdgeが注目すべき、より考え抜かれた設計になると思いますが、位置合わせは良いことです。

w3schools入力タイプ番号

また、そのスライダーは、WinUIが計画しているものに近いですが、まったく同じではありません（塗りつぶされた円の親指と比較して、輪郭が描かれた円の親指）

ローカリゼーション機能を設定する方法がまだわかりません。 米国では、ドットは小数点記号として使用されます。 私が住んでいるオランダでは、コンマを使用しています。 米国のグループ化区切り文字はコンマですが、オランダではドットです。

例：

Framework要素のLanguageプロパティを使用して、数字とグループ化の区切り文字を指定する必要がありますか？

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

Edgeの最新のCanaryビルドを見ていたら、NumberBoxコントロールに最も近い<input type="number"/>のデザインを見ました。

このイメージを共有しようと思っただけです。

@ mdtauk 、 @ SavoySchuler 、
このコントロールがどこから来たのかわかりません。 Edgeチームの私の連絡先によると、これが彼らが使用するであろうコントロールです。

スライダー： https ：
番号ボックス： https ：

彼らがビジュアルを更新するかどうかはわかりませんし、最終的な出力はこのように正確に表示されない可能性があります（そうだと思いますが、それは私の大げさな推測です）。

@chigyその画像は、Edgeの現在のCanaryビルドからのものですが、前述したように、これはWIPであり、オンにするオプションのフラグです。

これが、前号で取り上げたfastdnaプロジェクトの目的を説明していると思います。 🙂

Framework要素のLanguageプロパティを使用して、数字とグループ化の区切り文字を指定する必要がありますか？

これらの設定は通常「リージョン」から取得されるため、

DecimalFormatter APIで区切り文字をカスタマイズする方法がわからないため、言語設定から区切り文字を取得する必要があります。 😖

@jevansaks 、洞察に感謝します！ @sonnemafにタグを

@jevansaksは、NumberBoxのDecimalFormatterにxamlの例をどのように記述できますか？ コードビハインドからではなく、XAMLで定義したいと思います。 DecimalSymbolプロパティとGroupingSymbolプロパティを持つことも私にとってはうまくいくでしょう。 しかし、これは簡単すぎるかもしれません。

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

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

侵入して申し訳ありませんが、私はこのトピックを発見しましたが、はいはいはい。 両方とも数値コントロールに欠落していることが多く、私とgithubの他の多くの開発者はその回避策を構築する必要があります。 特に電卓の例では、数値を16進数でフォーマットするだけでなく、入力を完全にサポートする必要があります。

現時点では、16進数のプレフィックスをカスタマイズ可能にすることをお勧めします。 ある時点ではプレフィックスをまったく付けない方が良いですが、他の時点では必ずしも0xは限りません。

NumberBoxのDecimalFormatterにxamlの例を書くことができますか？ コードビハインドからではなく、XAMLで定義したいと思います。 DecimalSymbolプロパティとGroupingSymbolプロパティを持つことも私にとってはうまくいくでしょう。 しかし、これは簡単すぎるかもしれません。

@sonnemaf WinRTで使用する必要があるのはDecimalFormatterだけですが、残念ながら、これらの設定をカスタマイズすることはできません。 小数点記号またはグループ化記号をカスタマイズする唯一の方法は、OSのリージョンコントロールパネルのユーザー設定を使用することです（私が知る限り）。

これらの設定についてユーザーの地域を尊重することは正しいようですが、それらをオーバーライドする必要があるシナリオはありますか？

@sonnemaf

16進数または2進数のサポートが必要であることを正当化する実際のアプリシナリオはありますか？

申し訳ありませんが、これに気づき、少し遅れて返信しました。 16進数/バイナリのサポートが非常に役立つと思います。 私は.NETIoTプロジェクトに深く関わっており、レジスターやピンへの読み取り/書き込みを行うビット/バイトを操作して物事を制御しているため、主に16進数/バイナリーの世界で働いています。

16進数/バイナリをサポートすることは非常にありがたいことです。 Thx😄

16進数や2進数は必要ありません。 特にバイナリーは「持っているといい」でしょう。

開発アップデート

皆さんこんにちは！ 私たちはNumberBox仕様に満足しつつあり、私が積極的にコントロールに取り組んでいることに注意したいと

いくつかの注意：

• 特にInputValidationの設計が複雑なため、TextBoxをサブクラス化しないことを選択しました。NumberBoxは、TextBoxを含む独自のコントロールになります。
  
  
  
  • これは、すべてのTextBoxプロパティが公開されないことを意味します。 これらのいずれかをNumberBoxに持ち込むことが重要であるかどうかを知りたいのですが、_Header、PlaceHolderText_、そしておそらく_Text_への欲求を見ることができましたか？ 私の側で行うのは非常に簡単な変更なので、間違いなくこれを少し開いてみたかったのです。
  
  
• 私は仕様に非常に小さな編集を加えてきました。これらは今のところほとんど言葉の修正ですが、値のプレビューなどの未解決の質問がまだあり、コントロールを作成するときに、独自の設計質問のいくつかを生成しています。 これはまだ入力を追加する良い機会です😄

@KevinTXY TextBoxではなくSliderベースから派生する提案が1つありました。これは、選択されたものですか？

• PlaceHolderText
• ヘッダ
• 文章
• 検証アイコン
• 検証メッセージ
• SelectionForeground
• SelectionBackground
• フォーカス状態/リソースなど

これらは私が必要だと思うTextBoxのもののいくつかです。 「クリアテキスト」ボタンについてはよくわかりません。これは、長いテキスト文字列でより意味があります。

値のプレビューはV2の機能だと思いましたが、これは変更されましたか？ スライダーコントロールには、親指がスライドするときに値を示すツールチップがあります。 これを処理する1つの方法として、また検証メッセージを使用してこれを処理するか、インラインで表示することを提案しました。

Inlineには、Windows Insiderが、ツールチップとして表示されるか、テキストフィールド内に表示される予測テキスト補完の実験を構築するという事実に問題があります。 どのプレビュー方法を選択しても、それらと競合したり、このコントロールの予測機能がオフになったりしないようにする必要があります。

@KevinTXY TextBoxではなくSliderベースから派生する提案が1つありました。これは、選択されたものですか？

NumberBoxは現在、TextBoxを拡張するのではなく、マークアップにTextBoxを含む独自のコントロール（Windows.UI.Xaml.Controls.Controlを拡張）です。 スライダーは面白そうに聞こえますが、実装が少しハックになると思います。これらのコントロールには、NumberBoxに属しているとは思わなかったプロパティもたくさんあります。 私はPMではありませんが、これを開発した経験から、これは開発を簡素化し、将来の拡張性のための良いルートであると感じています。

これらは私が必要だと思うTextBoxのもののいくつかです。 「クリアテキスト」ボタンについてはよくわかりません。これは、長いテキスト文字列でより意味があります。

これは素晴らしいです-まさに私が探していたものです！ これらすべてに価値があることに同意します。 [すべてクリア]ボタンは、TextBoxのデフォルト機能であるため、現在表示されています。まだ無効にすることは考えていませんが、大きなエントリやタッチスクリーンユーザーにとっては価値があると思います。 私は間違いなく、少なくとも私が言及した3つ（Header、PlaceholderText、Text）をプレビューに入れようとしています。

値のプレビューに関しては、そこでは何も確定されておらず、未解決の質問として仕様にのみ含まれています。 最も簡単な一時的な解決策は、開発者が望むように表示するためにプレビュー値を公開することだと思います。これはプレビューバージョンの範囲内に簡単に@ SavoySchuler ＆Co。に電話をかけるために残して

@KevinTXY理想的には、電卓チームとのコラボレーションがあり、埋め込み可能な基本的な計算エンジンを作成します。また、このコントロールと一緒に説明したCalculatorPickerのアイデアで将来使用することもできます。 （標準の電卓でフライアウトを表示する電卓ボタン付きのコントロール）

実際、電卓のメンテナーとのコラボレーションは素晴らしいアイデアのように思えます。 計算を実行する電卓からアプリサービスを公開できるため、WinUIバイナリをアップロードする必要はありません。アプリがインストールされている場合はアプリサービスに話しかけるだけで、それ以外の場合はサイレントに失敗します。

Sliderからの派生について-私は実際にRangeBaseと言いそれから派生すると一貫したAPIサーフェスが提供されるため、これが正しいことであると確信しています。コントロールとスライダーを使用すると、簡単に交換できます。

そうそう、RangeBase、それだけだった。

電卓は最近、常にトップのCompactOverlayモードをサポートする作業を行いました。そのため、CalendarFlyoutと同じサイズのフライアウトに小さなキーパッドを配置する方が実現可能です。 （CalculatorBoxコントロールの包含が承認された場合。

そのアプリサービス（電卓ストアの更新に半依存してWinUIの更新をリンクする）かどうか、またはWinUIに追加して電卓のエンジンから派生できるサービスバイナリかどうかはわかりません。

更新：コードPRが存在するようになりました🎆！

私はそこでいくつかの問題を追跡していますが、ほとんどはデザインに関連していません。

ありがとう、 @ xyzzerと@mdtauk！ RangeBaseをチェックアウトしましたが、TextBoxのサブクラス化と同じくらい多くの荷物を運んでいるようです。 今のところ、コントロールにTextBoxを含め、必要なプロパティとアクセシビリティ機能のみを追加することに固執します。 これはまだ価値のある検討事項であり、現在行われているアクセシビリティの会話を知らせるのに役立ちました。

@mdtauk 、スターティングリストをありがとう！ @KevinTXYはあなたがリストしたAPIの公開を開始しました。残りはまもなく確認します。

講演中の@KevinTXYのようなプレビューとポップアップ計算機（ただし、ここではv1の保証はありません）。 調整と活用可能な作業について、電卓と積極的にチャットしています。 あなたたちは素晴らしいです！ このコントロールの革新を推進し続けてくれてありがとう。 それは素晴らしいです。 @KevinTXYのコードPRは上記に掲載されています。 ガイダンスとドキュメントのドラフトに進む直前に、仕様の残りのすべてのルーズエンドを拘束します。

ネーミング

スペックが私から遠ざかったコメントが多かったので、物事が落ち着いた後、私はちょうど調べ始めています。 最初に、C＃の規則に実際には従わない名前付けに気づきました-はい、これらのコントロールがC ++で記述されていることは知っていますが、それでもプラットフォーム内の他の名前付けと矛盾していると思います。

| タイプ| 現在の名前| 提案された名前|
| ------- | ---------------- | ------------------- |
| ブール値| AcceptsCalculation | IsCalculationAccepted |
| ブール値| HyperDragEnabled | IsHyperDragEnabled |
| ブール値| HyperScrollEnabled | IsHyperScrollEnabled |

StepFrequency

また、StepFrequencyとは何ですか？ これは仕様で定義されておらず、「XAMLツールキットのNumericUpDown」の使用経験はありません。 これが何をするかによっては、Frequencyという単語を追加しても意味がない場合があります。 それはおそらく単なる「ステップ」ですか？ スライダーコントロールでは、ティックが全体の最大-最小範囲のモジュラスで表示されるため、TickFrequencyは理にかなっています。 ただし、このコントロールでは、これは最小の増分/ステップサイズにすぎないと思います。 基本的に、ユーザーはステップ外の値を入力できますか？

たとえば、MinValue = 0、MaxValue = 6、StepFrequency = 2です。上矢印値を使用すると、{2、4、6}で十分に公平になります。 ただし、ユーザーは有効な値として0.5を入力できますか？ または、RoundingModeに応じて0または2に丸められますか？

最小/最大値

以下の2つのプロパティについては、他のコントロール（Slider、RangeBase）と同様に、これらは最小値と最大値にする必要があると思います。 APIは一貫している必要があります。
ダブルMinValue;
ダブルMaxValue;

アップダウンリピートボタン

私の知る限り議論されていないもう1つの機能は、上/下ボタンを実際にRepeatButtonにするかどうかです（そうあるべきだと思います）。 彼らは繰り返しボタンであればディレイ/間隔のプロパティは、Sliderコントロールのように追加する必要があります。 Slider.Interval Slider.Delay

数字

IntegerDigitsとFractionDigitsが表すものの説明を追加できますか？ 私の推測では、それらは数の各部分の桁数を制限します。 IntegerDigits = 2は、最大値が99になる可能性があることを意味します。FractionDigits= 3は、MaxValueが0.999になる可能性があることを意味します。 また、SignificantDigitsはこれら2つのプロパティをどのようにオーバーライドしますか？

負のゼロ？

このプロパティが必要なのはなぜですか？ それ自体がローカリゼーションなのですか？ 「-0.0」や「-0」は見たことがありません。 常に「0」です。
ブールIsZeroSigned;

ローカリゼーション

UIのローカリゼーションと数値形式のオーバーライドをサポートするには、このコントロールが必要です。 異なる方法で表示する必要がある国内および海外の金額が必要な複数の用途（金融アプリ）があります。 これは仕様のどこにも見当たりません。

doubleからtextへの変換は、Slider.ThumbToolTipValueConverterの精神に基づいて、ValueConverterを介してカスタマイズ可能である必要があります。 このようにして、以下の実際の例のように、最も複雑な部分をあらゆるニーズに合わせてカスタマイズできます。

数値と金額の小数点記号、および負の合計の指定が異なる可能性があるため、ValueConverterを使用しないNumericBoxの最も安全なアプローチは、整数モードで操作することです。 電卓はValueConverterとしても実装できます。この作業で、コントロールをオーバーロードする必要はありません。

@eugenegff数値から文字列への変換を一般的にすることは本当に良い考えです。 これにより、ローカリゼーションを処理できるようになりますが、開発者はユニットの追加など、他に必要なことをすべて実行できます。

私が見る唯一の複雑さは、コントロールに関連するCulture / NumberFormatInfoを維持することです。 これは、カスタムIValueConverterに移行するXAMLのコンバーターパラメーターである可能性がありますが、コントロール自体でこれを処理するためのよりクリーンな方法があるはずです。

このプロパティが必要なのはなぜですか？ それ自体がローカリゼーションなのですか？ 「-0.0」や「-0」は見たことがありません。 常に「0」です。

これは、WindowsのDecimalFormatterクラスのプロパティゼロに署名するための使用法とIEEEの前提条件があります。

UIのローカリゼーションと数値形式のオーバーライドをサポートするには、このコントロールが必要です。 異なる方法で表示する必要がある国内および海外の金額が必要な複数の用途（金融アプリ）があります。 これは仕様のどこにも見当たりません。

@SavoySchulerおそらく、DecimalFormatterクラスの言語設定のサポートを検討する必要がありますか？ しかし、私はそれがどのように動作するのかよく知りません。

わかりました、私はここで根本的な問題を理解していると思います。 C ++の世界では、DecimalFormatterにアクセスできますが、C＃の世界（WinUIを使用している場合）では、通常、IFormatProvider（指定されたカルチャのNumberFormatInfo）を使用します。 NumberFormatInfoにはすでにほとんどのプロパティがあります（偶然にもIsZeroSignedがありません）ので、開発者がそれまたはIFormatProviderを指定できるようにすることを考えていました。 問題があります。C++は.netの世界からのものであるため、IFormatProviderを使用できません。

では、2つの異なる方法があることを考えると、このコントロールはC＃とC ++でのローカリゼーションをどのように完全にサポートするのでしょうか。 ええと、マイクロソフトが賢い解決策を持っていない限り、私は2つの可能性しか考えられません。

1. 数値フォーマットのすべてのプロパティを完全に追加します（NumberFormatInfoとDecimalFormatterを効果的に再実装します）。 IsZeroSigned、IntegerDigits、FractionalDigitsなどを追加するだけではカバーされません。 NumberNegativePattern、NumberGroupSeparator、NumberGroupSizesなどもすべて必要です。
2. @eugenegffが提案したように開発者が何らかのコールバックでフォーマットをオーバーライドできるようにします。 正直なところ、これは最も簡単なアプローチのようです。

このコントロールでローカリゼーションがどのように形成されているかについて少し心配しています。 私は最初からローカリゼーションを取り上げてきました（このトピックに関する3番目のコメントです！）。 コントロールが文字列に変換されるときに、数値形式を完全にカスタマイズする方法が必要です。 それがなければ、この制御は実際の使用ではかなり制限されます。

では、2つの異なる方法があることを考えると、このコントロールはC＃とC ++でのローカリゼーションをどのように完全にサポートするのでしょうか。

聞こえます！ これは私たちがオフラインで調査してきたことですが、基本的に.NETはプラットフォームとは別に独自のローカリゼーションを行います。 オーバーライドするコールバックは素晴らしいエスケープハッチだと思いますが、オプション1が私たちが行くことができるルートであることを願っています。 現時点では、フォーマットと解析用のWinRT APIには、必要なすべてのカスタマイズノブがありません。 まだ調査中です。

これがすでに議論されているかどうかは確認していませんが、誰かが計算の関数サポートの大きな必要性、またはより重要な前例を見つけたかどうかをすばやく尋ねたいと思いました。つまり、以下のいずれか以上を意味します。
cos(), sin(), tan(), asin(), acos(), atan(), sqrt(), log(), abs(), ceil(), floor(), degree equivalents of trig functions, hyperbolic functions, etc

私は数学パーサーを私たちのニーズに合うようにつなぎ合わせており、関数はRPNへの変換プロセスを複雑にします（いくつかのバグを含むこれらをサポートするバージョンがすでにあると言っています）ので、これらのいずれかが価値があるかどうかを確認することに興味がありますトラブルや膨満感がある場合。 個人的にはあまり良くないと思いますが、前例がたくさんあれば面倒ではありません。

ほとんどの場合、これらはあまり発見できないと思います。より複雑な関数のサポートが必要な場合は、コールバックイベントへの解析を開いて、ユーザーが独自の解析または前処理ロジックを実装できるようにすることをお勧めします。

より価値があるのは、演算子を使用してテキストの入力を開始できるようにすることです。したがって、テキストをクリックすると、デフォルトですべてが選択され、最初に削除を押して前の値を削除せずに新しい値を入力するか、 「* 1.2」や「x1.2」 [Enter]ように入力するだけで、入力したテキストに入力した値が含まれていなくても、現在の値に1.2を掛けることができます。 「+2」、「-5」、「/ 3」、「％120」などでも同じことが機能します。

一部のプロフェッショナルアプリケーションで使用されています。

私たち（BeLight Software、Live Home 3Dプロジェクト）は、値<=>のテキスト変換のためにプラグ可能なValueConverterを必要とします。そうしないと、NumberBoxは私たちには不適切です。

これらの関数を使用することは非常にまれだと思います。アプリに角度を入力していますが、これは度の値にすぎません。 私にとって最も重要な用途は、時間を節約し、精神的にその計算を行わないようにするために、既存の値に値を追加したり、既存の値を数値で除算したりできることです。 （ところで、Adobeアプリには、4つの算術演算子があります：https：//adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/suggestions/12992463-support-math-operators-in-number -田畑）

また、cos（）のような関数は、ある種のExcelアプリを作成しているのでない限り、意味をなさない場所ではおそらく必要ありません。

私にとって最も重要な用途は、時間を節約し、精神的にその計算を行わないようにするために、既存のものに値を追加したり、既存のものを数値で割ったりできることです。

よし！ @xyzzerが提案したものと似ているように

私たち（BeLight Software、Live Home 3Dプロジェクト）は、値<=>のテキスト変換のためにプラグ可能なValueConverterを必要とします。そうしないと、NumberBoxは私たちには不適切です。

私はあなたが与えたスライダーの例を見てみました、そしてそれは非常に合理的に聞こえます-私はNumBoxのIValueConverterで価値を見ることができました。 すぐに調べて、仕様に適切に適合するかどうかを判断しようとします。 しかし、まだ何も約束はありません！

@KevinTXY上記の関数を追加すると、提供される値よりも多くの問題が発生する可能性があると思います。 これは、コントロールに、より多くの文字（基本的には任意の文字）を入力できるようになるためです。 これにより、誤って無効なものを入力しやすくなり、検証と解析が複雑になります。
また、「数値ボックスは数値のみのテキストコントロールです...」という仕様の先頭にある説明の最初の行が壊れます。

ローカリゼーションについてまだ質問があることに驚いています。 コントロールはFrameworkElementから継承するため（必須ですか？）、 Languageプロパティにアクセスできるため、他のすべてのFrameworkElementと同様に、システムロケールのUI設定に依存せずに、ロケールの直接設定をサポートします。
これは、10進文字やグループ化文字などをインスタンスごとに設定できることを意味します。

ローカリゼーションについてまだ質問があることに驚いています。

問題は、言語はフォーマットを制御するものではなく、地域/文化の設定であるということです。 ローカリゼーションとは、UI文字列を更新して正しい言語で表示することですが、数値/通貨/日時の形式は地域によって制御されます。 詳細については、 https ：

問題は、言語はフォーマットを制御するものではなく、地域/文化の設定であるということです。 ローカリゼーションとは、UI文字列を更新して正しい言語で表示することですが、数値/通貨/日時の形式は地域によって制御されます。 詳細については、 https ：

Languageは、 CultureInfo変換される値を取ります。カルチャは、アンマネージコード開発ではロケールと呼ばれることに注意してください。 これには、小数、グループ化、負の符号などのプロパティを含むNumberFormatInfoタイプのNumberFormatプロパティが含まれています。

私の理解では、システム設定に依存するのではなく、コントロールに特定のフォーマットやその他のローカリゼーションの詳細を強制したい場合、その方法はLanguageを指定することです。

プロパティの説明には、「FrameworkElementに適用されるローカリゼーション/グローバリゼーション言語情報を設定する」と明記されています。

または、参照しているドキュメントを誤解しているかもしれませんが、それらはすべて、リンク先のページでカバーされている内容をバックアップしているようです。
多分それは異なる用語を使用するC ++とC＃の用語の問題です。
私が知っているのは、XAMLで言語を設定することは、他のアプリや他のコントロールでカルチャ/ロケールを強制する方法であるということです。

ローカリゼーションで私が見た質問は、特定の数値形式、またはグループと小数点の区切り文字を強制することについてでした。 それとも、コントロールのテキストベースのプロパティ（Header、PlaceholderTextなど）のローカリゼーションに影響を与えずにこれらを制御する方法が本当の問題ですか？

Languageは、 CultureInfo変換される値を取ります

ネイティブ/ WinRTではなく、BCP-47langs文字列を取得するだけです。 そしてそれが問題です。 .NETでは、言語設定とフォーマット設定を持つCultureInfoをバンドルします。 WinRTでは、これは別個のものであり、CultureInfoオブジェクトに相当するものはありません。

ICU APIが私たちが探しているものを可能にするかもしれないと聞きましたが、私たちはまだそれを調査する機会がありませんでした。

マイクロソフトは、これに弾丸をかみ、.netカルチャ/ローカリゼーション（CultureInfo）とネイティブ/ WinRT間の変換メカニズムを完全に実装することを検討する必要があると思います。 理想的には、物事を行うための新しい方法を検討しないでしょう。

マネージコードは大多数のLOBアプリが書かれているものであり、これは最初から正しく行う必要があると思います。 WinRTは、.netと同じローカリゼーションメカニズム/手法を取得する必要があり、変換は自動である必要があります。

それはもっと多くの仕事になるでしょうか？ 短期：はい、長期：いいえ。 それはNumberBoxコントロールのリリースを遅らせる可能性がありますか？ おそらく、コールバックが短期的に使用されていない限り。

ただし、これは正しく行う必要があります。そうしないと、他の場所で問題が発生します。 編集可能なCalendarDatePickerなどの他のシナリオでも同様の問題が発生する可能性があります。（＃735）

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
どうやらFastDNAチームは、入力番号フィールドの設計のためにSpinnerコントロールの作業も行っており、検討に値する提案を思いついたようです。

また、ArrowsではなくChevronsを使用している理由も尋ねられました。

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

ボタンを並べて、積み重ねた拡張デザインをホバーとして持っていても、コントロールの幅が狭すぎる場合は考えられますか？ たぶん、すべてのMicrosoft UIフレームワークで機能するレイアウトについてコンセンサスが得られる可能性がありますか？

@mdtauk 、お知らせいただきありがとう
これが彼らがテストし、ユーザビリティを検証しているデザインであるかどうかをFastDNAの人々にチェックインします。

NumberBoxに戻る

了解しましたチーム、

予期せぬ休憩をお詫びします。 私はNumberBoxのフルスロットルに戻り、@ teaPが機能開発者として参加しています！ このコントロールのプレビューでは、11月末を目標としています。これにより、WinUI2.4での安定したリリースを検討することになります。

古いワークフローには多くの手荷物があるので、未解決の質問や回答済みの質問を保存し、 @ teaPと私が次の点に関する残りの未解決のトピックの解決を完了する新しい仕様のPRに移植します。

• ローカリゼーション
• デザイン（特に上/下ボタンに関して）
• ハイパースクロール/ハイパードラッグ

検証トピックが解決されていることに注意してください。 @LucasHainesの入力検証作業がWinUI3.0およびそれ以前のNumberBox計画リリースで予定されているため、NumberBoxV1でサポートされている検証モードを次のように減らしました。

列挙型NumberBoxBasicValidationMode
{{
無効、
InvalidInputOverwritten、
};

WinUI 3.0と相互に必要な入力検証作業が来たら、NumberBoxV2で最初に計画されたIconMessageおよびTextBlockMessage検証モードでその列挙型を拡張することを検討します。

これまでの進捗状況をすべて振り返り、質問を投稿し、関連するフィードバックを求めます。 いつもご愛顧いただき、誠にありがとうございます。 😄

ふぅ。 これを自分でやろうとすると、私に近づいてきました。

ハハ私はこれに受動的に取り組み続けたかったのですが、今学期は私をひっくり返しました。 それが包まれているのを見てうれしいです私はそれを監視します！

NumberBoxの最初のコミットがライブになりました！

お願いします-これはまだ進行中の作業であり、開発側とPM側の両方でアクティブな問題追跡が行われていることに注意してください。 どちらの適切なリンクにもまだ記載されていない機能にバグや一般的なルーズエンドが見られる場合は、お知らせください。 😊

@SavoySchuler 、スペックの新しいPRを開きますか？ また、特にNaNディスプレイに関して、このコメントに私が書いたことに注意しましたか？ ありがとう。

@SavoySchulerこれまでのspec / NumberBoxコードに関するコメント。 うまくいけば、これに対するコメントも仕様/ドキュメントに含まれる可能性があります。 全体として、これが一緒になるのを見るのは素晴らしいことです！

StepFrequency

ここで「周波数」という言葉を使用することは、私にはぴったりではありません。 スライダーコントロールでは、ティックが計算され、全体の最大-最小範囲のモジュラスで表示されるため、TickFrequencyは理にかなっています。 ただし、このコントロールでは、増分/ステップサイズのみです。 これは「StepAmount」または「StepValue」のようなものですが、「MinimumValue」ではなく「Minimum」に似た「Step」だけです。

また、ユーザーは定義されたステップの範囲外の値を入力できますか？
たとえば、Minimum = 0、Maximum = 6、StepFrequency = 2です。上矢印の値を使用すると、{2、4、6}で十分に公平になります。 ただし、ユーザーは有効な値として0.5を入力できますか？ それとも、0または2に丸められますか？

丸め

数学的な丸めはどのように処理されますか？ これは、式を使用して通貨値を入力する場合に特に重要です。 式が計算された後、カスタム丸めを指定できるか、または提供できる必要があります。 HalfAwayFromZeroは私が始めようとしているものですが、他の丸めモードも許可する必要があります。

ローカリゼーション

NumberBoxがすべてのINumberFormatter / INumberFormatter2実装を受け入れることを確認してください-そして将来も受け入れ続けるでしょう（それがコードで実装される方法です、私は仕様がそれを呼び出すことを確認したいだけです）。 これにより、既存のCurrencyFormatter / DecimalFormatterを使用する場合と比較して、テキストのローカライズを完全に制御できるようになります。 これに対する解決策があるのは素晴らしいことです！

テキストラッピング

編集：次回は仕様全体を読む必要があります。

新しい「IsWrapEnabled」プロパティを作成したのはなぜですか？ 「テキスト」という用語がNumberBoxにあまり当てはまらないと感じたからですか？

また、おそらくWrapとWrapWithOverflowの両方が同じように実装されていることを理解していますが、両方の列挙値を同等にして、ドキュメントで機能を説明しているだけです。

KeyboardAcceleratorsを正しく処理する

このコントロールが、TextBoxよりもキーボードアクセラレータの使用をサポートしていることを確認してください。 おそらく、TextBoxが修正されるまで、または修正されるまでは実行できませんが、＃1435は私にとって本当に問題であり、多くの醜い回避策を引き起こします。 TextBoxは「Ctrl + V」の貼り付け自体を処理し、KeyboardAcceleratorが発生します。 ただし、KeyboardAccelerator内では、TextBoxが独自のことを行ったことを知る方法はありません。

簡単な考え。 度グリフを値に追加する角度モード（および360°ラップアラウンドのロジック）がある場合

°°

または、この付属物は、TextBox＃784のサフィックスの提案で将来より適切に処理されますか？

@mdtauk 、度記号の追加は

ラッピングについては、実際にはそれがIsWrapEnabledプロパティの目的です...次回はドキュメントの最後を読む必要があります。

結論私たちは、既存のAPIであなたが望むすべてを行うことができると思います。

@mdtauk 、度記号の追加は

ラッピングについては、実際にはそれがIsWrapEnabledプロパティの目的です...次回はドキュメントの最後を読む必要があります。

結論私たちは、既存のAPIであなたが望むすべてを行うことができると思います。

Min、Max、Wrapがそれを処理することは知っていますが、Degreesは、ボックスに明示的な角度モードを設定するのに十分なほど一般的ですか？ また、内部の値は単なる数値であるのに対し、TextBoxテキストに記号を表示する必要があります。

@teaP新しいコンパクトSpinButtonModeを見て、オーバーレイされたスピンボタンに表示と非表示のアニメーションを追加することは可能でしょうか？

また、ComboBoxやその他のフォームフィールドをフライアウト要素とより適切に一致させるために、これにアクリルを追加することを検討しましたか？

編集：ダークテーマでの可視性のこの問題を修正します。 TextBoxのフォーカスされた色と一致させるつもりですか、それとも現在のテーマの色と一致させるつもりですか？ とにかく、アクリルはこれを解決します。

@SavoySchuler 、スペックの新しいPRを開きますか？ また、特にNaNディスプレイに関して、このコメントに私が書いたことに注意しましたか？ ありがとう。

確かに@adrientetar 。 NumberBoxが空の場合、 Valueは（要求どおりに）NaNに設定され、 PlaceholderTextが表示されます。

@SavoySchulerこれまでのspec / NumberBoxコードに関するコメント。 うまくいけば、これに対するコメントも仕様/ドキュメントに含まれる可能性があります。 全体として、これが一緒になるのを見るのは素晴らしいことです！

StepFrequency

ここで「周波数」という言葉を使用することは、私にはぴったりではありません。 スライダーコントロールでは、ティックが計算され、全体の最大-最小範囲のモジュラスで表示されるため、TickFrequencyは理にかなっています。 ただし、このコントロールでは、増分/ステップサイズのみです。 これは「StepAmount」または「StepValue」のようなものですが、「MinimumValue」ではなく「Minimum」に似た「Step」だけです。

私はこのフィードバックを@MikeHillbergと共有し、今話し合っています。 ここにある他のすべてのプロパティの中で自己文書化するために、この推論が逸脱するのに十分な理由がある場合は、「SpinButtonStep」に沿った何かを検討しています。 知らせます。 ポイントを上げてくれてありがとう！

また、ユーザーは定義されたステップの範囲外の値を入力できますか？
たとえば、Minimum = 0、Maximum = 6、StepFrequency = 2です。上矢印の値を使用すると、{2、4、6}で十分に公平になります。 ただし、ユーザーは有効な値として0.5を入力できますか？ それとも、0または2に丸められますか？

ユーザーは、数値的または法的に公式な入力を好きなように入力できます。 NumberFormatterプロパティを使用して、構成されたフォーマットにその入力を強制変換する方法の例については、フォーマットのセクションを参照してください。

SpinButtonは、定義されたSpinButtonステップサイズ（API名は現在保留中）だけその値をインクリメントまたはデクリメントします。 したがって、うまく連携するフォーマットとステップサイズを構成するようにしてください。

使用される丸め戦略は、フォーマットによって定義されます。 DecimalFormatterの例で言えば、、ここで設定できることを丸めプロパティの一例です。

丸め

数学的な丸めはどのように処理されますか？ これは、式を使用して通貨値を入力する場合に特に重要です。 式が計算された後、カスタム丸めを指定できるか、または提供できる必要があります。 HalfAwayFromZeroは私が始めようとしているものですが、他の丸めモードも許可する必要があります。

丸めはフォーマットによってここでDecimalFormatterに設定することができ、丸めプロパティの一例です。 これをより明確にするために、ガイドラインに例を追加します。 再度、感謝します。 😊

ローカリゼーション

NumberBoxがすべてのINumberFormatter / INumberFormatter2実装を受け入れることを確認してください-そして将来も受け入れ続けるでしょう（それがコードで実装される方法です、私は仕様がそれを呼び出すことを確認したいだけです）。 これにより、既存のCurrencyFormatter / DecimalFormatterを使用する場合と比較して、テキストのローカライズを完全に制御できるようになります。 これに対する解決策があるのは素晴らしいことです！

それが現在の実装の意図です。 将来性の保証に関しては、NumberBoxはローカリゼーションとフォーマットのニーズに対するソリューションを引き続き提供します。 今のところ、そして予見可能な将来のために、私たちはそれを実装しました。

テキストラッピング

編集：次回は仕様全体を読む必要があります。

〜なぜ新しい 'IsWrapEnabled'プロパティを作成したのですか？ これは、TextBlock.TextWrappingとTextWrappingEnumを使用するTextBox / XAML規則に反します。 「テキスト」という用語がNumberBoxにあまり当てはまらないと感じたからですか？〜

〜また、おそらくWrapとWrapWithOverflowの両方が同じように実装されていることを理解していますが、両方の列挙値を同等にして、ドキュメントで機能を説明しているだけです。 ここで新しいプロパティを作成するということは、新しい値コンバーターなどが必要であることを意味します...既存の規則を破る理由はないと思います。〜

KeyboardAcceleratorsを正しく処理する

このコントロールが、TextBoxよりもキーボードアクセラレータの使用をサポートしていることを確認してください。 おそらく、TextBoxが修正されるまで、または修正されるまでは実行できませんが、＃1435は私にとって本当に問題であり、多くの醜い回避策を引き起こします。 TextBoxは「Ctrl + V」の貼り付け自体を処理し、KeyboardAcceleratorが発生します。 ただし、KeyboardAccelerator内では、TextBoxが独自のことを行ったことを知る方法はありません。

NumberBoxにはTextBoxが含まれており、その上にプロパティと構成を追加します。 @jevanはより包括的な理解があるかもしれないので、タグを

全体として、素晴らしいフィードバック@robloo！ できる限り包括的でV1NumberBoxを完備していることを確認するために、時間を割いていただきありがとうございます。 他にご不明な点がございましたら、お気軽にお問い合わせください。 😊

@mdtauk

簡単な考え。 度グリフを値に追加する角度モード（および360°ラップアラウンドのロジック）がある場合

°°

または、この付属物は、TextBox＃784のサフィックスの提案で将来より適切に処理されますか？

これまでのところ、NumberBoxは数字以外の文字の表示をサポートしていません（式の評価で数式文字も削除されるため）。

＃784に対するあなたの提案は、私たちのプラットフォームにとって群を抜いて最も包括的なものだと思います。 その提案が実行されない場合、フォールバックとして適切なV2機能NumberBoxとして私を襲います。

非常に要求されているNumberBoxの入力検証モードの2つがWinUI3.0の必要性でブロックされているため、WinUI3.0と一緒にまたはその直後にV2をリリースすることをすでに計画しています。 そのため、V1が公開された後にV2の問題を開く予定であり、ここでもこれに注意するようにしています。

ここにある他のすべてのプロパティの中で自己文書化するために、この推論が逸脱するのに十分な理由がある場合は、「SpinButtonStep」に沿った何かを検討しています。

SlideFrequencyがSliderが使用しているものであることがわかったので、私たちはその用語と一致させようとしていたと思います。 スピンボタンだけでなく、ドラッグやUIAutomationプロバイダーの値の変更にも使用できることを忘れないでください。

@roblooと@ mdtauk 、°について返信する前に、スレッドをさらに読んでおく必要があります。 NumberBoxはTextとValue緊密に同期しているため、開発者が取得できるようにするために、このシンボルをText内に表示することは現在サポートされていないと思います。変換のオーバーヘッドなしで必要なタイプ。 利用可能なフォーマットプロパティを使用してこれを実現する方法はわかりませんでしたが、方法をご存知の場合はお知らせください。

現在、V1リリースに対応していますが、V2については、プレフィックス/サフィック/特殊文字をもう一度確認します。 それまでの間、 @ mdtaukの＃784の提案は、これまでのプラットフォームで提案された中で最も包括的なソリューションであると思います。 これが必要な機能である場合は、その提案に賛成とコメントを付けてください。

@ adrientetar 、scroll-to-changeはV1に

この機能を使用するシナリオについて、もう少し詳しく教えてください。 ユーザーはこれが利用可能であることをどのように知っていますか？ ソリューションにローカルで実装されているのと比較して、これがすべてのNumberBoxでデフォルト（または少なくとも使用可能）である必要がある理由を理解するのに役立ちますか？

@SavoySchuler

コメントありがとうございます。

ここにある他のすべてのプロパティの中で自己文書化するために、この推論が逸脱するのに十分な理由がある場合は、「SpinButtonStep」に沿った何かを検討しています。

私はその用語がとても好きですが、SliderがすでにStepFrequencyプロパティを持っていることを見逃しました。 そのため、 @ jevansaksが述べたように慣例から逸脱することは意味がありません。

丸めはフォーマットによって処理されます。 DecimalFormatterに設定できる丸めプロパティの例を次に示します。

ユーザーがNumberBoxに「1/3」と入力したとします。 次のシーケンスは正しいですか？

• フォーカスが失われると、式が評価され、0.33333333 ... 34のdouble値が計算されます。
• 0.33333333 ... 34がDecimalFormatterに渡されます
• 0.33333333 ... 34は、設定に応じて、「0.30」に丸めることができます（難しいため）。
• その「0.30」の値は、ユーザーに表示するためにテキストボックスに入力されます
• ダブルValueは{0.33333333 ... 34}になり、 Text値は「0.30」になります。
• ダブルValueを読み取ると、 Text表示される丸められた数値は返されません。
  （または、文字列に変換した後、10進形式の値を何らかの方法で再度解析してから、全体を再評価しますか？）

また、ValueプロパティとTextプロパティが内部で非常に緊密に結合されていることも懸念しています。 ドキュメントはこの結合を定義しておらず、高度に構造化されていない場合、双方向の依存関係は決して楽しいものではありません。

これが内部でどのように実装されているかはまだわかりませんが、これを行う正しい方法は、doubleValueを唯一の不動産として扱うことだと思われます。 テキストは、Valueのフォーマットされたバージョンです。 次に、開発者は、TextBoxおよびTextプロパティに表示するために値をフォーマットできます（以前に要求された度記号またはフィート/インチ記号を取得します）。 すべてがすでにValueプロパティによって内部的に駆動されている場合、これを行うのはまったく難しいことではありません。 ユーザーからのテキスト入力はとにかく保持されず、値を再計算するためにのみ使用され、値は表示用に再度フォーマットされます。

シーケンスは次のようになります。

• ユーザーテキスト入力->パーサー->二重値->フォーマット->テキスト

コードからテキスト値を変更することは、ユーザーがテキストを入力したかのようになります。 値を直接変更するには、フォーマットとテキストの手順を実行するだけです。

値とテキストのシーケンス間の丸めを正確に保つには、次のようになります。

• ユーザーテキスト入力->パーサー->値->丸め->値->フォーマット->テキスト

編集：式/入力パーサーと評価エンジン（呼び出されるものは何でも）に丸めを実装するには、 RoundingAlgorithmのようなアルゴリズムを定義するための新しいプロパティを追加する必要があります。 ご指摘のとおり、その列挙型はWindows.Globalization.NumberFormattingですでに定義されています。 INumberFormatter2はフォーマットに使用する必要があり、他には何も使用しないでください。ここでも、計算と最終的に表示されるテキストの間でステージを分離したままにします。

@ adrientetar 、scroll-to-changeはV1に

この機能を使用するシナリオについて、もう少し詳しく教えてください。 ユーザーはこれが利用可能であることをどのように知っていますか？ ソリューションにローカルで実装されているのと比較して、これがすべてのNumberBoxでデフォルト（または少なくとも使用可能）である必要がある理由を理解するのに役立ちますか？

1つは大きく、もう1つは小さくする必要があります。これは、Adobeアプリで選択した領域/オブジェクトを微調整するのと同じです。

この機能を使用するシナリオについて、もう少し詳しく教えてください。

視覚的な意味（オブジェクトの回転など）で値を変更したいが、どこまで行きたいかわからない場合に最適です。 ですから、ビジュアルデザインに適しています。

ユーザーはこれが利用可能であることをどのように知っていますか？

これは、Adobe XD、Framerなどの最新のツールに備わっている機能にすぎません。

ソリューションにローカルで実装されているのと比較して、これがすべてのNumberBoxでデフォルト（または少なくとも使用可能）である必要がある理由を理解するのに役立ちますか？

タッチデバイスを使用しているときにこれを使用するのは良いことだと思います。これは、タップドラッグして特定の値を微調整するのに便利な方法です（タップドラッグして値をスクロールする電話時間選択ウィジェットのようなものです）。

1つは大きく、もう1つは小さくする必要があります。これは、Adobeアプリで選択した領域/オブジェクトを微調整するのと同じです。

RangeBaseには、プロパティSmallChangeおよびLargeChangeがあります。 NumericUpDownのバージョンのBeLightSoftwareは、RangeBaseから派生し、ArrowUpおよびArrowDownショートカットを使用したSmallChange、およびPageUpおよびPageDownショートカットを使用したLargeChangeによって値を変更します。

そして、私たちはここで一人ではありません、
https://help.syncfusion.com/uwp/numeric-updown/gestures
https://docs.telerik.com/devtools/wpf/controls/radnumericupdown/features/navigation

コミュニティコール中に頭に浮かんだキーボードテンキーに関する1つのコメント...

ほとんどのアプリでは、「。」 キーパッドボタンは引き続き「。」にマップされます。 英語以外の言語（たとえば、フランス語の「、」）を使用する場合の小数点記号とは異なる文字。 したがって、「。」を押すとメモ帳でキーを押すと、「。」と書き込まれます。 文字。

一部のアプリ（Excelはそれについて最もよく知られています）は、このキーの動作を変更して、キーパッド「。」のキー押下を再解釈します。 小数点記号入力として。 キーパッドの「電卓」デザインとの互換性が高くなっています。

電卓アプリも「。」を書き直します。 を押して、小数点記号として解釈します。

ナンバーボックスは「電卓」としてより機能することが許可されるため、コントロールで「。」の使用を許可できますか。 キーパッドのキーを小数点記号として使用しますか？ または、少なくとも開発者が主要なフィルターやイベントと戦うことなくこの機能を追加する方法を提供しますか？

おそらく、プロパティは機能を有効にする（オプトインする場合）または無効にする（オプトアウトする場合）ことを許可する可能性があります。 KeyPadDotAsDecimalSeparator="false" ？

V2 NumberBoxの提案： https ：

こんにちは素晴らしいWinUIコミュニティ！ 私たちの最初のコミュニティがリリースを見るためにコントロールを提案したので、私たちが家に帰るのを手伝ってくれて本当にありがとう。 これは大規模な作業であり、皆さんが一緒に設計できるV1機能の最高のコレクションを作成するためにかなりの時間を費やしたことを私たちは知っています。

また、すべてがV1リリースに組み込まれたわけではないこともわかっています。 いくつかの非常に望ましい入力検証構成はWinUI3.0機能の作業に依存しており、いくつかの望ましい機能のニーズは検証/アプリケーションの後半に表面化し、いくつかの機能はV1リリース後にさらに調査されることがわかっています。

WinUI 3リリースで、意図したNumberBox機能の作業を完了することを目指しています。 V1にない必要な機能に関するフィードバックを収集するための問題を開きました。 NumberBoxに必要なものがない場合は、必ずここにコメントをドロップしてください： https ：