作为起点，Telerik 有一个https://www.telerik.com/universal-windows-platform-ui/numericbox。 它也可以在开源中使用： https :

我喜欢他们的是他们使用属性 ValueFormat 进行格式化的方法。

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

还请确保这是正确本地化的。 Windows Community Toolkit 实现有一些缺点：

带有 ValidationType="Decimal" 的 TextBoxRegex 扩展不支持所有 UI 区域性。 相反，它固定为 InvariantCulture。 英文十进制值是带句点的“10.1234”。 在西班牙语或德语中，十进制值写为“10,1234”。 解析英语将是正确的； 但是，西班牙语或德语用户输入将只是“101234”，其中小数部分丢失。

请参阅： https :

向上和向下箭头应该将值增加或减少一个开发人员可以设置的值，但默认值应该是整数 1

• 环绕最小/最大值很好，例如，如果选择一个角度
• 添加后缀的能力
• 单击文本框并向上/向下拖动以更改值，Adobe XD 在数字输入中包含此值。

我在 WinRT XAML Toolkit 中的实现还支持向上/向下拖动以更改值，并且在使用鼠标时比在某些情况下单击按钮更有用。
https://github.com/xyzzer/WinRTXamlToolkit/tree/master/WinRTXamlToolkit/Controls/NumericUpDown

你好， @sonnemaf 、 @ArchieCoder 、 @robloo 、 @mdtauk 、 @adrientetar和 @xyzzer！ 我被分配到这个提案。

首先，感谢@sonnemaf提交此内容。 我上周在 Microsoft Build 2019 上展示了它，得到了观众的欢呼！ 评论中的社区反应也反映了我们必须看到 NumberBox 发生的兴奋。

我已经通读了每个人的评论并更新了范围部分以反映收到的输入。 如果每个人都可以借此机会查看

嗨@SavoySchuler ，

本周，我正在研究我的应用程序的辅助功能。 如果使用新控件正确处理可访问性，这将是一个加号，例如，可以大声说出增量而不是“加号”、“减号”。 其余的我觉得还好。

确保叙述者能够正确读出这些值，以便清楚地了解正在发生的事情是很重要的。

不确定 Xbox 控制器是否需要任何焦点点击以确保模拟摇杆和方向键正常工作

小更正 - 拖动以增加/减少应该对文本字段本身起作用，直到它被激活。 IIRC 在我的实现中，我必须在文本字段顶部放置一些透明覆盖层以启用它并在拖动时隐藏鼠标光标，以便控件或屏幕的边框不会限制拖动距离，并且当你完成拖动时然后我再次显示光标——它出现在它第一次消失的地方。

@SavoySchuler你有一个很好的任务。 我可以忍受你的范围。 计算器很好用（WinUI 3.0 或 3.1）。 我在许多桌面环境（VB6、WinForms、WPF 和 UWP）中进行过开发，但总是错过了一个 NumberBox。 最后我们会得到它。

也许您还可以为 Up/Down 添加鼠标滚轮。 Blend for Visual Studio 支持这一点。

我也喜欢 Drag-to-change，我在 Expression Blend 中经常使用它。

我不确定输入验证会做什么，不会做什么。 它只是最小/最大还是限制键盘（字母 az 等）？ 它会处理粘贴无效数字吗？

我很想阅读完整的规格。

@ArchieCoder ，我听到你的声音响亮而清晰。 可访问性是一个优先事项，最好提前处理。 我已在此提案中启动了“辅助功能和输入”部分，并在其中添加了您的注释。

@mdtauk ，一如既往的好问题。 我已将此添加到辅助功能和输入部分作为查看它的注释。

@xyzzer ，你说得对。 在重新组织范围列表时，我将向上/向下按钮和拖动更改组合为相关功能。 重新阅读后，它确实看起来好像我建议将拖动更改作为按钮上的功能。 我已将拖动更改移至其自己的部分以提供清晰度。

@sonnemaf ，太棒了。 我会在规范打开后立即发布指向该规范的链接，这可能是今天或下周。 请鼓励和我一起写吧！ 在此之前，我已将滚动更改添加到此处的范围。

全部，附有关于计算器支持的说明 - 我相信它的价值。 我正在与我的团队合作，以确定是否应该将其模块化，以防功能可以在平台中进一步利用。 此外，还有一个问题是我们在计算器支持方面能走多远？ +-/* 上的简单操作顺序可以吗？ 或者更全面的东西，例如连接到某种 wolfram alpha 服务？ 探索模块化路线或许可以让我们从更基本的案例开始，同时不阻碍更全面的计算器支持形式的机会。 我有兴趣在这里了解每个人的需求。

对于输入验证，我有同样的问题。 最小值、最大值、无字母和无效粘贴是否覆盖它？

我觉得计算器功能很可爱，但实际上用户是如何发现这个功能的？ 会有关于这个的小部件提示吗？

@ArchieCoder ，您认为

我们确实有 ToolTip 或更重的教学提示作为我们可以要求开发人员依赖的应用程序级别的指导，但我强烈倾向于在 NumberBox 本身内解决这个问题。

我很想听听您的想法！

只要由于空间限制不需要其他上下文，占位符确实是一个好方法。 例如，我认为 NumberBox 宽度会小于文本框。

除非控件支持可为空的数字 - 它将始终显示一个值，
所以里面不会有占位符字符串的空间。

2019 年 5 月 17 日星期五上午 10:14 ArchieCoder [email protected]
写道：

只要其他上下文不是，占位符确实是一个好方法
由于空间限制，需要。 我认为 NumberBox 宽度会
例如比文本框小。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMAL7LUOVPIM55PYO4LPV3RWPA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXWZG00000000000000000000000000000000000000000030000000300000000300000030000000000000000000004300000000000000000000000000000000000000300000同
或静音线程
https://github.com/notifications/unsubscribe-auth/AANMBMBKHP7GP5WUHLPWNZLPV3RWPANCNFSM4HA4PBNA
.

@ArchieCoder ，作为@sonnemaf的例子（再次感谢你），任何不够宽以显示“a + b - c”占位符文本的

@xyzzer ，感谢您提出这个问题。 让我们首先确保这是正确的用户体验，然后我们可以从那里找出实现！ 由于我们可能能够缓解的技术限制，还没有必要限制我们对 _right_ 用户体验的搜索。 ：轻松：

我有一个更高优先级的问题要问大家：

您更愿意拥有一个独立于标准 TextBox 来整合这些功能的 NumberBox 控件，还是希望将这些功能作为可通过 API 或 InputScope 激活的本机功能嵌入到 TextBox 中？

（ @sonnemaf 、 @ArchieCoder 、 @robloo 、 @mdtauk 、 @adrientetar和 @xyzzer）

将所有这些都放入一个 TextBox 控件是一个重大的变化。

输入字符的验证。

对 InputScope 使用正确的键盘布局

不同的鼠标行为。

能够像 FabricWeb 版本一样显示微调按钮。

如果可以添加所有这些内容，并使用行为枚举来定义 TextBox 类型，而不会对当前在其应用程序中使用 TextBox 的其他所有人产生影响，那就太好了。

您甚至可以考虑组合其他 TextBox 行为，例如可以表示搜索的图标或充当按钮的日历。 诸如 IP 地址或 URL 之类的掩码，当您在旁边的文本中输入时，它们以占位符文本的样式显示“http://”。

FabricWeb 的 TextField 种类繁多。

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

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

我肯定会使用自己的 NumberBox 控件，而不是将所有这些功能烘焙到 TextBox 控件中（类似于 PasswordBox 控件而不是带有输入模式“密码”的 TextBox）。

例如，NumberBox 控件将不仅仅是一个简单的 IP 地址输入字段。 它将带有自己的可访问性/独特的滚动和拖动功能、计算器支持……所有这些都将使它与我目前使用 TextBox 的方式有很大不同（情况就像为组指定表示名称一样简单数据的）。 随着为 NumberBox 控件提出更多特殊功能/要求，我们可以在 NumberBox 和 TextBox 之间保持良好和干净的分离。

这种差异也会出现在文档和应用程序 xaml 布局中（NumberBox 比具有一堆属性的 TextBox 更容易检测，其中一个属性指定输入模式）。 而不是阅读有关其数字输入功能的 TextBox 文档，该部分在特定的 NumberBox 控件文档中会很好而且整洁（就像今天的 PasswordBox 一样）。

关于控件的外观，我认为单位/后缀可以用较小的尺寸/不饱和的颜色显示在一边，以便它与值本身区分开来：

当鼠标悬停在控件上时，向上/向下箭头可以淡入代替单位：

另一种选择是来自 figma.com 的数字控件，当您将鼠标悬停在单位上时，您可以单击+向左/向右拖动以更改值。

向左/向右很有趣，因为向左/向右移动鼠标比向上/向下移动更容易（您不需要抬起手腕）。

其他事情：

• 单击未聚焦的文本区域时，应选择所有内容。 以便单击+键入值+输入更改值
• 当焦点增加或减少 10 时，Shift+单击箭头或 Shift+Up/Down（我认为该值也应该是可自定义的）。
• 我不认为向上/向下箭头对用户非常有用。 如果用户想要一个精确的值，他们只需输入它，如果他们不确定他们想要什么值，他们可以通过单击+拖动来可视化一系列值变化。 所以向上/向下箭头应该至少是可选的。

@adrientetar在控件内放置一个单位的指示会产生很多额外的问题：

• 本土化
• 可达性
• 选择
• 粘贴
• 转换

这些都可以通过将其放在标题、描述或单独的 TextBlock 中来避免。

我会选择一个单独的 NumberBox 控件，它带有一个 Value 属性，可能不是一个 Text 属性。 Value 应该是一个 Double 以便我们可以对其进行数据绑定 (x:Bind)。 我不确定我们是否也应该支持 Decimal 数据类型，以及如何支持。

我认为必须支持可空数字（感谢@xyzzer）。 Value 属性应该是 Nullable数据类型。 我不确定在将其绑定到不可为空的值时是否会导致绑定问题。

虽然组合有好处并且有编号的附加行为
模式可以实现并附加到 TextBox - 我认为它会使
它不必要地复杂和有限。
您在实施过程中可能遇到的一些最大问题与
可访问性。 我相信支持一些可访问性模式 -
您需要将某些接口的实现烘焙到 TextBox 中
如果 TextBox 不是数字框模式，那会让人感到困惑。

2019 年 5 月 20 日星期一凌晨 2:33 Fons Sonnemans通知@ github.com
写道：

我认为必须支持可空数字（感谢@xyzzer
https://github.com/xyzzer ）。 Value 属性应该是 Nullable
数据类型。 我不确定这是否会在将其绑定到时导致绑定问题
不可为空的值。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMBGVIQ36CDPQO6CWKLPWJV55A5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW6DVJLOMNXPY43VMVBW63KDMNXPY43VMVBW63KDMNXPY3VWJDVJLOMNXPY4
或静音线程
https://github.com/notifications/unsubscribe-auth/AANMBMBTHT2UXOAGRTEDF7LPWJV55ANCNFSM4HA4PBNA
.

我还有一个问题要问大家。 您是否需要/更喜欢输入验证或屏蔽？

（@sonnemaf，@ArchieCoder，@robloo，@mdtauk，@adrientetar，@xyzzer，和@费利克斯-DEV）

验证是必不可少的，因为您不能向字符串添加数字。 并且需要评估和处理数学运算符。

如果无法计算，是否需要显示错误消息，我不太确定。

掩码会很有用，但它可能应该内置到文本框本身中，以便可以处理 URL 和电子邮件条目。 NumberBox 将是电话号码、IP 等

我不认为 N​​umberBox 应该用于电话号码或 IP。 这些看起来更像是 TextBox 的简单屏蔽/过滤扩展。 NumberBox 是您想要用于输入单个值的东西。
也许有一个货币盒控件的潜力，但我也觉得它应该是一个与 TB 或 NB 不同的单独控件。

@xyzzer让

NumberBox 上的一些属性可能是：

• 显示/隐藏微调按钮
• 允许增加和减少值
• 允许计算值
• 允许屏蔽输入
• 本地化掩码，例如电话号码或 IP 地址

可以添加到 TextBox 的属性可以是：

• 掩码属性 - 用于定义自定义格式 ([email protected]) 以及本地化掩码（例如邮政/邮政编码）的 XAML 字符串
• 前缀/后缀文本显示（例如_http://_ 作为前缀）
• 操作按钮显示/隐藏 - 带有图标和单击事件属性
• 图标（Fabric UI 搜索框在左侧显示其图标，并在框获得焦点时关闭动画）

这些图像是 Fabric UI TextField 的 - 它支持所有这些不同的状态 - 我们应该尽可能将 Fluent WinUI 3.0 控件带到同等水平

Fabric UI Spinner 按钮太小无法触摸，所以我会采用不同的格式，使上下按钮并排，而不是堆叠在一起

对我来说，验证是必须的，而掩码是很好的。 我从不喜欢掩饰； 它太死板了。

@rudyhuyn在Windows Calculator存储库中提出了一个不错的功能。 @mdtauk对此发表了评论。

您可以从 NumberBox 中打开一个类似于日期/时间/日历选择器的计算器弹出窗口。

类似于上面@xyzzer所说的。 数字和包含数字序列的字符串之间存在根本区别。
我听说过所描述的差异的最好方法是您可以对数字执行乘法和除法运算。 你可以要求一个数的一半，然后除以二。 你不能要求半个邮政编码或“电话号码”就得到有意义的东西。

将具有数学能力的特定NumberBox与捕获由数字组成的其他值的功能混合也会导致其他问题。
“电话号码”可能以前导零（或加号）开头，并且它们具有含义。 对于_number_，他们不会并且会被剥夺。
“电话号码”通常也用括号和连字符格式化。 当作为数学运算处理时，这些很容易最终被解释为需要乘法和减法。

允许以与TextBox相同的方式进行掩码并作为一种格式化输入的方式可能会混淆NumberBox和TextBox之间的区别以及何时应该使用它们。

简单的验证是必须的，但需要注意的是，当验证进入平台时，这不会导致验证方法发生冲突，或者很容易最终促使开发人员将他们的验证传播到多个位置.

我会保持验证仅基于这些属性：

• 最大值
• 最小值
• 允许小数位数

需要单独说明

• 计算的无效输出
• 如何处理输入/粘贴/计算的值以及绑定中使用的内容。 需要显示计算或无效值以表明它无效，但这不能传递给任何支持属性，

掩码需要视觉可供性来明确需要什么，而基本计算输入不会与掩码输入一起使用。

Fabric Web 文本控件似乎很好地处理了这个问题——当然，NumberBox 的范围与对默认 TextBox 控件的一般适配和完成改进是分开的。

微调按钮（可能还有可选的计算器弹出按钮）是似乎特定于 NumberBox 的唯一视觉内容。

至于属性，也许如果启用了键盘向上和向下按钮来更改值 - 可以包含一个Step值，以便您可以选择在按键时增加或减少多少。

@mdtauk ，我喜欢Step值，但不仅仅是在按键时。 也在滚动和向上/向下按钮上。

@sonnemaf当然，该步骤适用于诸如鼠标滚轮滴答、按键或按键之类的二进制内容。 也许拖离盒子的距离可以增加步数？

那么StepMinimum和StepMaximum可能吗？

那么 StepMinimum 和 StepMaximum 可能吗？

我不知道这些价值观可能与什么有关，也不知道对它们有什么期望。
如果“Step”的目的是定义增量，则称其为“Increment”。

这将允许Max:100 Min:0 Increment:10仅允许指定值 0、10、20、30、40、50、60、70、80、90 和 100。

根据拖动的距离来改变步长/增量可能会导致不可预测的值变化。 如果此控件的目的是更轻松地指定数值，那么如果该值开始以不同的量发生变化，那么我可能会发现这非常令人沮丧，这将违背拥有专用控件以使其变得容易的基本目标。

@mrlacey我使用 Step 因为它是为滑块和进度条命名的属性，但如果愿意，可以使用增量。 该值确实会上下波动，只要增量不会与仅值的增加混淆。

有一个建议，单击并向上或向下拖动以增加或减少值。 如果用户希望该值更改得更快，则您向上或向下拖动得越远，那么拥有 Stap Min 和 Max 值将允许开发人员在 delta 更改时控制它。 因此，小的拖动距离可以步进0.1或1 - 但进一步拖动可以例如步进5或10 。

我并不是说拖动距离必须改变值变化的速度 - 只是它的想法可能会有所帮助，如果它感觉自然并且给用户一些信心和控制感。

很棒的反馈，大家！ 我已经打开了一个规范和公关来开始敲定细节。

@KevinTXY将作为此控件的开发人员加入我。 我们将在此处继续进行需求对话，并在 PR 上开始 API/示例特定对话。

请与我一起编写规范。

教学提示的规范是一个完整

• 描述
• 每个 API/功能的示例
• 指南
• API (IDL)

好主意，我喜欢这一切的发展方向。 加上我的两分钱：

• 毫无疑问，我认为这应该是一个单独的 NumberBox，而不是与 TextBox 集成。 此外，这里讨论了很多好的特性，但我们也应该保持 NumberBox 的轻量级。 因此，我建议从 NumberBox 派生一个 CalculatorBox 或类似的东西，并且可以具有高级的“2+3”输入或用于打开计算器的按钮。
• 本地化需要提前在规范中深思熟虑。 此外，在某些情况下，您可能希望覆盖本地 UI。 因此，设置 NumberformatInfo 属性或 CultureInfo 可能非常有用。 例如，在某些应用程序中，外部值和本地值都被跟踪。 每个都可能是不同的格式。
• 控件需要支持移动小数位。 这比简单地验证每个更改的文本的格式更棘手。 需要跟踪每个字符输入并根据需要替换前一个小数位。
• 任何递增/递减箭头都应该可配置为关闭以仅具有一个简单的输入框——同样，我们需要一个轻量级控件，用于需要作为其他控件的一部分的情况。
• 还没有讨论过的其他事情是我们需要理想地支持多种类型——Decimal、Integer 和潜在的 Long、Double 等......这可能会从根本上改变很多事情，我自己还没有完全考虑过.
• 该值肯定需要可以为空。 未设置的值不同于零。
• 另一个不重要的想法是允许为小数、双精度或浮点类型指定小数精度。

我相信会有更多的想法出现。 我期待阅读规范！

（@mdtauk，@xyzzer，@mrlacey，@sonnemaf，@robloo，@费利克斯-DEV，@adrientetar，@ArchieCoder）

我在规范/ PR 中填写了每个 API 和示例。 我想我已经使用基本预定义类型（仍在进行中）的枚举以及将覆盖预定义类型（如果设置）的自定义格式属性解决了您的规范的格式问题。

请检查一下，如果它不能解决您的疑虑，或者是否可以添加或改进，请告诉我。 我将接受有助于此处要求的规范的拉取请求。

• 确认是必须的。 我已指定此控件从 TextBox 派生，以免费获取屏蔽和其他支持属性。

• 对于@mrlacey的关注，我添加了一个用于启用/禁用去除前导零的 API，该 API 可以与自定义格式字符串结合使用以启用自定义数字字符串输入的场景（注意国际电话号码和 IP 地址已经在可能的基本格式类型列表中）。

• 这与启用/禁用计算器支持的能力相结合，对我来说，这是一个控件的交集，它既可以减轻数值/字符串的重量，又可以提供足够的计算和自定义支持。 我相信示例的简洁突出了这一点，但我很想听听任何认为这会使预期控制使用起来更麻烦的人的意见。

• @sonnemaf我很欣赏图标 > 弹出式计算器示例的新颖性和直观性。 对我来说，这源于 CalendarDatePicker 的概念，这可能是 V2 功能的一个很好的考虑，除非这里的每个人都强烈推动它应该被考虑用于 V1？

如果与计算器开源工作协调，弹出计算器可能会有意义。 既要保持 Calculator Flyout 外观的一致性，又要保持其背后的引擎的一致性。

不确定这是否是发布此图像的地方，但这里是符合规范的各种状态的设计。

图像比例为 200%

@mdtauk你的模型的目的是什么？

每个图像试图显示什么状态？ 如果您不澄清这一点，我们可能会做出与您不同的假设。

这些是否旨在成为像素完美的参考？

您能否指出图像中的某些内容与平台或基本控件的默认值不同的地方，以便您添加或更改的内容（如果有）一目了然。

@mrlacey如果有帮助，我可以做更全面的细分吗？ 我只是想说明规范中提到的一些例子。

它们的目的是尝试说明这些控件如何使用提议的各种控件元素，例如前缀、后缀、掩码、向上和向下按钮。 它们是从 FabricWeb 控件设计中推断出来的，但使用了像 FocusReveal 这样的 XAML 元素和按钮的控件大小。

示例显示 Rest - Focus - Disabled 状态

弹出式计算器将是 V2 的一个不错的功能。

我不知道该把我的评论放在哪里。 我必须对规范进行 PR 还是我可以继续在这个问题上写下我的想法？

整数

NumberBoxFormatType 的整数值有用吗？

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

语

您会使用该语言来指定货币、十进制数字分组符号吗？

在下一个示例中，语言设置为 nl-NL。 这是否意味着前缀是欧元符号，十进制符号是一个逗号，后面有两位小数，数字分组是一个点？ 负货币前面有一个减号，没有像美国那样的括号。

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

这是否足够，因为 Windows 中有许多数字和货币格式选项。

值属性或属性

我们是否需要 Value 属性以及它是什么（数字）类型。 我会用它来数据绑定它。 它应该是双精度数、十进制数还是整数。 我们是否需要 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" />

如果 Employee 的 Salary 属性是 Nullable 呢？（十进制？）。 我们是否需要 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 也是一样。 它们现在在规范中是 Integer ，但这不应该是 Double 吗？

@sonnemaf因为规范说该控件适用于可以输入数字的任何内容，我认为这意味着它将“值”视为文本并依赖于使用代码进行必要的转换。 这并不理想，但即使Value属性是 long 或 float，仍然会有很多情况需要转换。
它比每种数字类型的重载都要好。
然后是控件设计用于无法转换为“数字”类型的内容，例如美国邮政编码、电话号码或 IP 地址。 对于这些类型的值，获取文本似乎是最好的（唯一的）选项。
我认为它更简单（至少在初始版本中，有一种方法可以访问输入的值并在必要时依赖转换器。我可以看到一个位置，用于最初进入工具包的助手（或子类）集合，然后是一些它们根据反馈被纳入主控制。

是否需要Language属性？ 为什么这与 UILocale 不同？ 可能有很好的理由，但似乎这应该是用户可配置的（在操作系统级别），并且当格式与其他地方或用户的格式不匹配时，提供指定特定格式的能力可能会给开发人员带来更多问题应用程序想要。 在我的脑海里：如果有人以不同的格式粘贴一个值怎么办？

@mdtauk你的模型的目的是什么？

每个图像试图显示什么状态？ 如果您不澄清这一点，我们可能会做出与您不同的假设。

这些是否旨在成为像素完美的参考？

您能否指出图像中的某些内容与平台或基本控件的默认值不同的地方，以便您添加或更改的内容（如果有）一目了然。

@mrlacey这是你想要的那种东西吗？

@mdtauk好一点，因为它解释了您想要展示的一些内容。

不过，潜在的问题仍然存在：您展示这一点的目标是什么？ 这只是一个想法吗？ 在探索了不同的想法后，这是您的首选版本吗？ 如果是这样，为什么这些是最好的/首选的？

将当前控件与您希望新控件以您喜欢的新系统范围样式显示的方式进行比较意味着无法将特定于控件的内容与您喜欢的新系统范围样式中的内容分开。

例如，您提到更改边框的透明度。 此更改是针对所有控件还是仅针对此控件？ 在哪些州？

给出明确的大小（按钮）在设计合成中可能会出现问题，因为它们并不总是根据容器的大小调整均匀地转换。 它们应该总是方形的吗？ 还是它们的宽度是基于默认控件高度固定的？

你是如何确定前缀和后缀的背景画笔的？ 我假设一个现有的系统刷，但哪个？

本规范不包括掩蔽。 您的“屏蔽”示例是否旨在与格式字符串相关？
你如何被屏蔽的例子对应于一种格式？
我假设您的示例显示了第 4 版 IP 地址的条目，但根据一切似乎都适合的程度，那里看起来有很多假设。 所有不可输入的值都应该有背景和边距吗？ 如果它们不总是显示怎么办？ 是否应该拉伸内容以适应所有可用空间，就像您的示例中那样？ 当平移比可用空间宽的内容时，如何处理为不可输入值分配的空间？

@mdtauk好一点，因为它解释了您想要展示的一些内容。

不过，潜在的问题仍然存在：您展示这一点的目标是什么？ 这只是一个想法吗？ 在探索了不同的想法后，这是您的首选版本吗？ 如果是这样，为什么这些是最好的/首选的？

将当前控件与您希望新控件以您喜欢的新系统范围样式显示的方式进行比较意味着无法将特定于控件的内容与您喜欢的新系统范围样式中的内容分开。

例如，您提到更改边框的透明度。 此更改是针对所有控件还是仅针对此控件？ 在哪些州？

NumberBox规范不包括任何视觉示例，原始提案中的图像是功能的粗略示例。 还有另一个 PR #524，其中控制模板更新为 2epx 的 CornerRadius 值，这也与 Fabric Web 使用的舍入相同。

因此，假设 TextBox 派生控件也将进行类似更新，我以此为指导来展示 NumberBox 的建议功能如何适应它。 Fabric Web 文本字段已经支持 Prefix 和 Suffix 值，所以我只是采用了这种设计，并使用了 XAML 指标。

给出明确的大小（按钮）在设计合成中可能会出现问题，因为它们并不总是根据容器的大小调整均匀地转换。 它们应该总是方形的吗？ 还是它们的宽度是基于默认控件高度固定的？

当前的TextBox 有一些集成的按钮，例如SearchBox、Password Reveal 按钮和Clear Text 按钮。 XAML 的触摸目标建议按钮为 32 x 32 epx - 我只是让它们保持方形并使用该指导。

你是如何确定前缀和后缀的背景画笔的？ 我假设一个现有的系统刷，但哪个？

在我的示例中，我使用了主题前景色，但使用了 15% 的不透明度。 FabricWeb 使用接近 10%，而 XAML 按钮使用 20%。
有类似 ListLowBrush 的画笔值，但它可能需要一个新的 TextBoxAppendixBackground 画笔。 Text Foreground 将使用相同的 PlaceholderTextForeground 画笔。

本规范不包括掩蔽。 您的“屏蔽”示例是否旨在与格式字符串相关？
你如何被屏蔽的例子对应于一种格式？
我假设您的示例显示了第 4 版 IP 地址的条目，但根据一切似乎都适合的程度，那里看起来有很多假设。 所有不可输入的值都应该有背景和边距吗？ 如果它们不总是显示怎么办？ 是否应该拉伸内容以适应所有可用空间，就像您的示例中那样？ 当平移比可用空间宽的内容时，如何处理为不可输入值分配的空间？

我不会假装我有所有的答案，它如何在控件上可见地显示将归结为如何在控件中实现掩码格式。

我使用了 IP v4 地址，因为它是规范中的示例，我的初衷是说明所提出的内容（尽管缺少前缀和后缀示例，因此我选择了其他值）

我查看了其他控件如何处理屏蔽，有些使用内联文本，在输入值时移动插入符号。 其他人在输入电话号码时会输入括号和连字符等内容。 有些使用 Tab 键或箭头键在段之间移动。 想到的最接近 Microsoft 的示例是在 Windows 安装期间输入产品密钥。

我认为使用与附加元素相同的样式会符合审美，但我知道这会增加控件的长度以适应所有内容，并且内联可能会更好地利用空间。

请注意，因为我现在正在使用 TextBox，它没有单个事件来表示用户更改的值（即失去焦点和按下的返回键的联合），类似于https://doc.qt.io /qt-5/qlineedit.html#textEdited将它

@adrientetar NumberBox作为一个名字看起来不错，因为它所有的输入都算作数字。 IP 地址有 4 个数字，电话号码，货币，测量等。

DigitBox、NumeralBox 等都是不太符合 Microsoft 命名风格的变体。

值本质上也不必是数字，因此 ValueBox 也可能有点误导。

@sonnemaf和@mdtauk ，我和我的团队讨论了嵌入式计算器的想法，简而言之，我们喜欢它 - 毫不夸张。 我们对你们如何提高我们提供的控件的质量和创造力感到非常兴奋。

我需要你的一些帮助才能做到这一点。 我们保持在通过我们的仓库出现的一连串很棒的想法之上的方式不仅是想法驱动的，而且也是场景驱动的。 （我分享这一点是因为说这种语言将使您的功能请求在我们的整个存储库中具有具体的影响力。）

你们中的任何一个都可以在您开发的任何应用程序中为我提供嵌入式计算器的真实场景吗？ 上下文、屏幕截图、用户配置文件都有帮助。 （我的电子邮件也对我的GitHub的个人资料，如果您喜欢在细节保密。）@xyzzer，@mrlacey，@robloo，@费利克斯-开发，@adrientetar和@ArchieCoder，请随时鼓励，如果此功能来分享您的使用方案你也感兴趣。

除了这一步之外，唯一可能会阻碍此功能的因素是计算器应用程序引擎会增加 WinUI DLL 大小的风险。 我将同时研究这一点，以确定可行性。

我之前提出过处理这个控件不仅仅是数字类型的问题。

数字和包含数字序列的字符串之间存在根本区别。

这是在规范的初稿发布之前，所以我认为已经考虑过这一点，并且决定让这个控件处理“传统数值”和“包含数字的字符串”。

我认为没有人会真正尝试争辩说 IPv4 地址是任何其他定义的“数字”，而不是通常不表示为格式化的数字序列。 实际上它只是一个 4 字节的值。

@萨沃伊舒勒

• 可能输入费用 - 从收据中输入这些项目，其中一些项目是个人项目，而其他项目是工作的一部分。
• 分摊账单时的餐厅应用程序，或者小费计算？
• 十六进制编辑应用程序，计算将选择移动到的偏移值？

拥有支持 IP 地址的控件将是对平台的一个很好的补充，但我认为 NumberBox 不是这种情况的正确控件。

如前所述，NumberBox 控件将：

• 在没有物理键盘的设备上使用时使用Number虚拟键盘
• 有 2 个按钮 -/+
• 显示带有计算器的弹出窗口或允许用户键入基本的算术运算

这些功能对 IP 地址都没有意义。 甚至控件的设计也大不相同。

而且要记住，如果我们支持IPv4地址，我们也必须支持IPv6地址，不是使用数字而是使用十六进制。

我认为在此控件中不包含 IP 地址支持更有意义，而是为 UWP 开发一个新的MaskedTextBox控件（支持 IPv4、IPv6、电话号码、邮政编码、SSN 等...）使用丰富的用户界面（如@mdtauk 演示）替换/改进社区工具包中的TextBoxMask (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

拥有支持 IP 地址的控件将是对平台的一个很好的补充，但我认为 NumberBox 不是这种情况的正确控件。

如前所述，NumberBox 控件将：

• 在没有物理键盘的设备上使用时使用Number虚拟键盘
• 有 2 个按钮 -/+
• 显示带有计算器的弹出窗口或允许用户键入基本的算术运算

这些功能对 IP 地址都没有意义。 甚至控件的设计也大不相同。

而且要记住，如果我们支持IPv4地址，我们也必须支持IPv6地址，不是使用数字而是使用十六进制。

认为在此控件中不包含 IP 地址支持更有意义，而是为 UWP 开发新的MaskedTextBox控件（支持 IPv4、IPv6、电话号码、邮政编码、SSN 等）丰富的用户界面（由@mdtauk 演示）并替换/改进社区工具包中的TextBoxMask (https://docs.microsoft.com/en-us/windows/communitytoolkit/extensions/textboxmask)

@rudyhuyn我主要同意你刚才在这里所说的，我的插图是针对提议的规范。

但正如其他人所提到的，蒙面文本框不必仅限于数字，也可以包括字符串。 Microsoft 产品密钥框就是一个很好的例子，它接受 5 组 0-9 AZ 字符。

即使将 Masking 分离出来，我仍然认为有很好的用例可以将 PrefixText 和 SuffixText 属性包含到 NumberBox 控件中。 货币、度量，都需要某种背景。

Spin Buttons 纯粹用于增加和减少值，因此它们也在 NumberBox 控件的范围内。

Prefix 和 Suffix 可以成为 TextBox 控件本身的属性，从而被其他控件继承。 （如果 PasswordBox 打开了任何漏洞，则可能需要对其进行例外处理）

通用值的掩码可以是此分离控件的枚举（以及 CustomFormatMask）。 其中一些掩码可能涉及文化背景，例如英国邮政编码是字母数字，英国国民保险号码遵循特殊格式等。

SW1A 2AA

英国邮政编码示例（唐宁街 10 号）

看来我今天早上没有成功刷新页面，然后才发送我的回复......感谢所有摇滚明星将这个提议提升到一个全新的水平！ 我知道在 GitHub 上过度使用这些词，但我是认真的！

@mdtauk - 你的模型太棒了。 我还没有为这个控件起草原型设计。 我可以分解你的模型并将它们添加到规范中作为我们的设计师开始他们的调色板的原型吗？ 我今天会联系并请求一位设计师，看看我是否可以让他们在这里用@mrlacey回复您的帖子。 我会尽快阅读您的帖子并以更细粒度的细节回复。

@sonnemaf ，再次感谢您！ 我鼓励您复制您的评论并将其重新发布到Pull Request 的对话选项卡上。 这是我们的工程团队将开始参与 API 和实施级别的地方。 为了提供全面的答案，这也是我开始起草指南和文档的地方。 我将以 [DEV] 为前者和 [PM] 为后者作为前言。 否则，这仍然是高级需求讨论的正确论坛（例如嵌入式计算器和@mdtauk的模型）。

@mdtauk ：我同意你的看法，前缀/后缀是TextBox一个很好的补充，不限于数字，一些例子：

• 当域始终相同（例如@microsoft.com）时，要求员工输入他们的电子邮件地址。
• 当表单总是以W-开头时，输入表单的名称

等等...

你应该再开一张票，这样我们就可以开始讨论了！

@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 应该是一个双精度值，而不是一个字符串。

@mrlacey电话号码（除了格式字符）是纯数字 - 但它们不属于任何类型的计算用例，所以它是否更适合掩码 TextBox，或者在 NumberBox 中提供对这些的支持是否有价值？

电话号码可能完全由数字（加上格式）组成，但这不会使它们成为数字。 你不能对它们进行任何算术运算并得到一些有意义的东西。
此外，有些可以以加号开头。
此外，电话号码中前导零的数量是有意义的。 对于数值，它不是。
控件中的其他功能，例如计算或向上和向下按钮，对于“电话号码”没有任何意义。

此控件应仅限于可以转换为 int/uint 或十进制而不会有丢失信息风险的值。

为确保我正确地综合了此反馈，如果您认为这是通过格式类型和拇指输入所有类型数字字符串（例如电话号码和 IPv4）的最佳位置，请在此评论上竖起大拇指 -下来，如果该功能应推迟到另一个或新的控制，使NumberBox只关注数学和数学值捕获。 （注意支持数学运算的功能，例如计算器模式和向上/向下按钮，需要通过相应的 API 启用。）

我不能保证这会以民主方式决定，因为我会做出为全球客户带来最佳投资回报的决定——但这将有助于验证我在这里看到的：没有人要求这样做来支持数字字符串，并希望为此使用专用控件。

@SavoySchuler可以操作、递增和递减的数字，以及为值添加上下文和含义的前缀和后缀。

我刚刚与这里的团队同步，并想就我们的一些未决问题分享更新：

• 我们正在倾听您的反馈，我们同意 NumberBox 不是数字字符串的正确位置。 FormatKinds 和 CustomFormat 属性已被更具体的 API 取代，以便以更直观的方式控制数字格式。
• Prefix 和 Suffix 确实属于 TextBox（NumberBox 将从中继承它们）。 我会给@mdtauk 、 @mrlacey或其他任何人
• NumberBox 中的最终提要（在计算、舍入等之后）将作为 TextBox 中的 String 保留，并作为新 Value 属性中的 Double 保留。 我们打算让这些反馈相互传递，因此对一个的更改将反映在另一个中。 这样做的目的是尽可能减少您的工作，并准备好在您需要时访问价值。
• StepSize 作为规范中的一个属性缺失。
• 整数类型将更改为 Double。
• 我们仍然对嵌入式计算器的想法大肆宣传，并正在寻找更多场景来帮助我们改进它。 @mdtauk ，感谢您已经回复了这一点反馈！
• 关于输入验证，我们的想法是首先发送一个 ValueChanged 类型的事件，这将使开发人员有机会操纵输入或根据需要在他们的结束/块表单提交时处理它。 如果没有采取纠正措施（例如将其强制在最小/最大范围内，删除无效字符等），则 NumberBox 将向用户显示有关其输入的错误指示。 这种双重方法使开发人员可以根据需要做出响应，但也允许将更正延迟给用户。

有大量的反馈，我仍在回应。 感谢您的耐心等待，我会在这里回复每个人，也会在规范存储库上回复！

“带有嵌入式计算器的 NumberBox 概念艺术。” WinUI 社区，2019 年 5 月。（彩色）

（ @ryandemopoulos 的赞美）

@SavoySchuler您要求提供一些可以使用我们正在讨论的控件类型的场景示例。 我的应用程序中有两个可能是很好的例子。

案例 1：有一个用于 2D 图形的设置编辑器，您可以在其中调整轴。

• 这只需要一个简单的数字输入。 增量 +/- 按钮在这里很有用。
• double 值会很好，但输入需要在字符按下时进行验证。 用户甚至不应该能够按“a”并将其显示在输入框中。 输入验证不应该使边框变红并给用户一个警告——它根本不应该输入无效值。
• 本地化必须由控件支持并移动小数位（无论是逗号，句点等）作为特殊情况处理（我一直提出这一点，因为它很容易错过）

案例 2：有一个货币值的输入字段，如下所示。 这是一个自定义控件“CurrencyBox”

• 这可以使用计算器按钮，输入方程 2+3 的能力在这里会有一些价值（我仍然觉得这应该是一个单独的控件）
• double 值对此并不理想。 我建议将 Value 的规范从 double 更改为 decimal 以支持这种类型的用例。 否则，由开发人员来解析字符串文本。
• 这里有一个特殊情况，负号是单独处理的。 这使得用户更容易在符号上不犯错误。 不过，我实际上并不希望 NumberBox 支持开箱即用。
• 设置文本对齐很重要，前缀/后缀对于显示货币符号非常有用（本地化仍然可能是一个问题，知道是在右侧还是左侧显示符号；但是，应用程序本身可能具有该逻辑）
• 用户可以输入外部值或本地值。 这两个值的 NumberFormatInfo 和 CultureInfo 可以与 UI 区域性不同。 因此，对于本地化，控件必须支持覆盖自定义 NumberFormatInfo。

现在在应用程序中，Windows Community Toolkit 用于两种情况，并将属性附加到 TextBox，如下所示：
TextBoxRegex.ValidationMode="动态"
TextBoxRegex.ValidationType="十进制"

一些最后的评论（对不起，太长了！）

• 我认为我们在这里讨论了潜在的 3 种不同的控件。 一个简单的 NumberBox，一个可以有方程和高级数字输入的 CalculatorBox（计算器按钮！），最后是一个用于非数字输入的 MaskedTextBox，如电话号码和 IP 地址。 我们不应该让他们感到困惑，并且就如何拆分这些概念达成一致是推进规范的关键。
• 我们不能忽视最基本且可以说是最有用的用例：一个普通的文本框，只有输入过滤，所以只能输入一个有效的数字。 应该可以关闭所有其他选项（我正在考虑增量 +/- 按钮）
• 我仍然建议在规范中从 double 更改为 decimal 以在解析的 Value 中准确捕获十进制精度。 此外，我们可能应该考虑与有理数输入不同的整数输入。 这可能是 API "IsInteger = true" 中的一个新属性，用于更改十进制默认值。

编辑：删除了将 NumberBox.Value 类型从双精度切换到十进制的想法。 我假设这存在于 C++ WinRT 世界中是不正确的。 它没有，而是仅在 .net 核心/框架中。

@robloo ，关于最后的评论，WinRT 中没有 Decimal 类型。

XAML 工具包的可视化树调试器是一种严重依赖工具包的 NumericUpDown 控件的工具，其中使用鼠标拖动、按钮、键盘进行递增/递减都很重要。 计算器输入也可能有帮助：

@robloo和@xyzzer ，这正是我正在寻找的信息！

验证/屏蔽

@robloo ，我对案例 1：子弹 2 - 验证与屏蔽特别感兴趣。 让我们来谈谈目前“不良输入”的场景：

• 新用户在您的 NumberBox 中键入“二”。
• NumberBox 引发“ValueChanged”事件，让您有机会将非数字输入返回到“0” - 或者如果您愿意的话。 如果不采取任何措施，那么...
• NumberBox 中的验证会亮起红色并向用户显示一条错误消息，通知他们只允许数字输入（这部分实际上还没有完全合理化，所以这只是一个假设）。

这一系列活动是否让您有能力创造您需要创造的体验？

我确实理解屏蔽可能是理想的默认设置，但让我分享一下我的团队上周讨论的内容 - 我们确定了在 Fluent 控件中首选验证（错误指示器/消息）作为替代方法，屏蔽可能令人沮丧和当他们的键盘输入没有输出时，最终用户会感到困惑。 另一种思考方式是，验证为用户提供了一定程度的透明度和信息，使他们更加了解体验，而不是被默默地胁迫。 因此，我们当前的行动方针是构建基本验证，同时不阻止开发人员根据需要添加高级验证（即将推出 TextBox）或通过 ValueChanged 事件进行屏蔽的机会。 要理解，这足够灵活，可以满足所有需求，同时提供推荐的体验作为默认值。

你在这里有什么想法？ 如果可以的话，我会对您进一步包含这些概念或构建更好体验的任何想法感兴趣。

值格式

对于您的其他观点， @robloo ，我在Spec 中添加了一个 DecimalPrecision 精度属性。 设置这个=“0”将实现整数。 此外，设置 MinValue="0" 可以帮助保持数字非负（或者 ValueChanged 事件是另一个将输入强制为绝对值的机会）。

你看过规范了吗？ 我相信我已经包含了完全启用您的体验所需的所有属性（等待验证与屏蔽讨论），但我很想知道您是否认为我遗漏了什么。

屏蔽，当最终用户遇到键盘输入没有输出时，他们可能会感到沮丧和困惑。

100% 同意是的。 更好的做法是在 LosingFocus/EnterPressed 上验证并在键入的值未验证时恢复 oldValue，这就是为什么在 LosingFocus/EnterPressed 上触发并包含 oldValue/newValue 的信号将是完美的原因。

@adrientetar ，好点！ 这是您需要创造的体验吗？ 如果是这样，我会看看我们需要做什么让 ValueChanged 事件同时发送旧值和新值。

@SavoySchuler这确实是我想在我的应用程序中做的事情，除非控件默认执行，否则我会自己构建该行为。

我想要的另一件事是 Shift+↑/↓ 为 10 的增量和 Ctrl+Shift+↑/↓ 为 100 的增量，尽管我认为 100 的增量并不总是有意义的。

好点子！ 我们应该确保控件来自 RangeBase
定义了 SmallChange 和 LargeChange 并且我们在
最起码。
是否有用于调用的标准键盘组合示例
UWP 的 RangeBase 或 WinForms/ComCtl(?) NumericUpDown 有很大变化吗？

2019 年 6 月 3 日星期一下午 3:50 Adrien Tétar通知@github.com
写道：

@SavoySchuler https://github.com/SavoySchuler这是我想要的
确实在我的应用程序中执行，除非控件执行，否则我会自己构建该行为
默认情况下。

我想要的另一件事是 Shift+↑/↓ 以 10 为增量
Ctrl+Shift+↑/↓ 以 100 为增量，但我认为增量为 100
拥有并不总是有意义的。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/microsoft/microsoft-ui-xaml/issues/483?email_source=notifications&email_token=AANMBMFZBHJIE4DR2KN46TTPYWN3BA5CNFSM4HA4PBNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63KDNXW4W3VMVBW63KDNXW4W2GOBW63KDNXPY240000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
或静音线程
https://github.com/notifications/unsubscribe-auth/AANMBMG4AWBK44VE4O4GYR3PYWN3BANCNFSM4HA4PBNA
.

我会检查以验证，但我相当有信心键盘快捷键必须留给应用程序来实现。 我在 #21 的可访问性理由中尝试了这一点，并且引入新的键盘快捷键是一个冒险的游戏，因为几乎所有 Windows 未声明的快捷键现在都已在应用程序级别使用（据说TeachingTip 可以继续使用） F6 潮流） - 但我会检查控制焦点是否允许这里出现任何异常！

Build 2018 是使用 INotifyDataErrorInfo 宣布 TextBox 控件的验证状态的时候。
这将很好地与掩码一起使用来验证或使当前文本字符串无效。

编辑：使用图标和较厚的底部边框颜色，有助于在色盲情况下以及在黑白情况下进行识别。 如果空间有限，底部错误文本可以作为图标上的工具提示完成。

@mdtauk你在这些标记方面

@SavoySchuler基于 Build 2018 中显示的示例轻松外推

还有很多例子可以看:)

抱歉，这是另一个长篇！

@SavoySchuler @adrientetar我肯定知道你在下面的陈述中来自哪里。 我不会争辩说，在绝大多数情况下，这是处理验证的最佳方式。 但是，我不得不认为在某些特殊情况下，它显然只是一个数字输入，您实际上是在帮用户一个忙，不允许他们对错误的字符进行粗指。

屏蔽，当最终用户遇到键盘输入没有输出时，他们可能会感到沮丧和困惑。

100% 同意是的。 更好的做法是在 LosingFocus/EnterPressed 上验证并在键入的值未验证时恢复 oldValue，这就是为什么在 LosingFocus/EnterPressed 上触发并包含 oldValue/newValue 的信号将是完美的原因。

尽管如此，我还是决定在其他应用程序中四处看看它是如何处理的。 我认为没有人比微软在用户交互方面做了更多的研究，所以我拉了桌面 64 位版本的 Word，然后是 OneNote 的 UWP 版本以供参考。 它或多或少完全同意你们所说的。 我可以在字体大小或形状大小输入框中输入任何文本，这些输入框显然只是数字输入。 它在很大程度上验证失去焦点并恢复到最后一个有效输入。

| 标题 | 图片 | 评论 |
|------|-----|------------|
| UWP OneNote 字体大小输入| | 任何值都可以从键盘输入，它会自动验证并在失去焦点时重置为最后一个有效值 |
| 桌面 Word 字体大小条目 | | 任何值都可以从键盘输入，它会在失去焦点时自动验证，如果无效则会出现错误消息。 单击 [确定] 将重置为最后一个有效值。 |
| UWP OneNote 二维图 | | 可以从键盘输入任何值。 无效值将被简单地忽略，并在计算中使用最后一个有效输入（不会在失去焦点时进行验证）。 按下增量 +/- 按钮将使用最后一个有效输入进行增量。 |
| 桌面字形状大小条目 | | 任何值都可以从键盘输入，它在失去焦点时自动验证并在失去焦点时重置为最后一个有效值。 |

所以我想我只是证明自己错了，这意味着我应该同意你的看法！

侧面评论：

• 正如其他人之前提到的，当 NumberBox 具有触摸/虚拟键盘的键盘焦点时，只应显示数字键盘。
• 左边的向下增量和右边的增量是一个有趣的想法，可以在这里讨论样式方面的问题。 我喜欢！
  

• 新用户在您的 NumberBox 中键入“二”。
• NumberBox 引发“ValueChanged”事件，让您有机会将非数字输入返回到“0” - 或者如果您愿意的话。 如果不采取任何措施，那么...
• NumberBox 中的验证会亮起红色并向用户显示一条错误消息，通知他们只允许数字输入（这部分实际上还没有完全合理化，所以这只是一个假设）。
  这一系列活动是否让您有能力创造您需要创造的体验？
  你在这里有什么想法？ 如果可以的话，我会对您进一步包含这些概念或构建更好体验的任何想法感兴趣。

我完全理解并同意添加输入验证对整个平台非常有用。 但是，您基本上只是描述了输入验证，没有对数字进行特殊处理。 因此，除了自动解析值之外，NumberBox 有什么用？ 作为开发人员，似乎带有数据验证的 TextBox 或多或少是相同的。

我认为基于我上面的例子，开箱即用的功能应该是我们的想法和@adrientetar所说的混合。 用户可以输入任何值，以便他们获得视觉反馈。 但是，在失去焦点时，该值会自动验证，并且会自动恢复为之前的有效数字（或空值）。 这为开发人员节省了必须自己处理输入验证的麻烦（我们已经知道它应该是 NumberBox 中的数字）。 它还与仅具有数据验证功能的 TextBox 有明显区别。

在事件方面，如果用例变得更加清晰，我仍然希望有机会取消文本更改。 因此，除了 ValueChanged 之外，我还建议使用 ValueChanging 和 TextChanging 事件来允许比较和取消输入。 无论如何，肯定需要 OldValue 和 NewValue，这至少允许我们在需要时快速将其改回 OldValue（尽管 UWP 喜欢在您修改事件中的 TextValue 时崩溃）。

关于规范：DecimalPrecision 的好主意，我需要更多时间来完成它并添加我的评论。 有很多细微差别，例如默认值应该是 String=Empty、Value=Null，并且当按下增量 +/- 按钮时，该值应该被视为零而不是空。

@mdtauk这么快就做出这么好的插图是人类不可能的:)

@robloo感谢您的
最好坚持使用当前旋转按钮中使用的向上和向下符号，以避免与 NumberBox 可以执行的数学运算混淆。

iOS 使用了“步进”控件，但文本输入是独立的，并且没有内联计算。

这是我发现的更多设计

我选择的设计似乎符合微软对此控件的典型风格，但它是最好的选择，还是正确的选择。 我很想听听其他人的看法。

编辑：添加了一些替代形式的模型（但我认为第一个想法是最好的......）

我同意@mdtauk的 +/- 位置，第一个是最好的。

有一个 XAML ControlTemplate，因此用户（开发人员）始终可以为其他两个布局创建自定义模板。

@robloo ，您无需为详细的回复道歉-尤其是当他们发出一些好笑的声音时！ 触摸/虚拟键盘的好主意 - 我已将它添加到规范的开放问题部分，由开发人员/团队运行，并确保这样做不会有不可接受的性能开销。 我认为如果我们能够做到这一点，对用户来说将是一个极大的便利。

你在验证方面提出了一个很好的观点......

[1] 提问时间：是否有人反对验证系统，该系统会自动将不可接受的输入恢复为之前的值，同时公开允许开发人员取消此行为并决定做什么/引发错误指示器或消息的事件？

从视觉上看，我在您发布的示例中看到了不相交的 UpDownButtons 的优点。 我相信@mdtauk和@sonnemaf在默认情况下是正确的。 UpDownButtons 的接近性是它们真正的方便，无论是测试不同（但不是远距离）输入的来回结果还是纠正越级输入。 除非改进设计或功能，否则距离似乎会增加体验的可避免劳动，并且还可能损害前缀/后缀属性/标签的清晰度，因为它反对将其明确分组为控件的功能部分，例如：$ [ - ] 192 [+]

我相信有一些不相交的 UpDownButtons 的情况。 我的想法是那些期望最少和单向输入的任务，或者开发人员试图使输入错误更难犯的任务。 我相信这是一些应用程序和网站在购买电影或音乐会门票时提供的体验。

那么我的问题是...

[2] 提问时间：我们是否应该依赖 Xaml ControlTemplate 来创建一个带有不相交的 UpDownButtons 的 NumberBox（即，这不足以证明支持开箱即用），或者我们是否应该包含一个属性来设置 UpDownButtons 是否出现连续与不相交？

我将针对这个问题 ping @chigy ，因为 Fluent Design System 指南可能会覆盖第二个问题。

我应该包括 UpDownButtons 对话的可访问性注意事项：UpDownButtons 彼此接近使讲述人/屏幕阅读器用户的概念清晰，同时还保持键盘导航用户的导航效率，并且不妥协这一点也很重要。

如果控件不是很宽，您可能希望箭头垂直堆叠（我知道我的应用程序中需要它）。 也许控制可以响应其设置的宽度？ 如果他们认为有意义的话，这取决于流畅的设计指南以这种方式进行规范。

我已经用我们的 3 个开放性问题更新了提案。

谢谢@mdtauk的概念设计！

@adrientetar我很高兴你指出这是必要的。 听起来我们可能需要这三种配置的枚举？

如果控件不是很宽，您可能希望箭头垂直堆叠（我知道我的应用程序中需要它）。 也许控制可以响应其设置的宽度？ 如果他们认为有意义的话，这取决于流畅的设计指南以这种方式进行规范。

有一项建议允许控件了解并响应它们可用的空间量#677 这可用于在控件变窄时重新定位旋转按钮。 也许 NarrowWidth 需要一个类似于 MinWidth 的属性，或者甚至一个 NumberOfDigits 来充当提示？

关于灰色文本示例 - 我担心这可能会鼓励用户填写出现的值，而不是作为最终结果的提示。 它看起来就像 PlaceholderText。

如何使用 AccentColor 和不同的字体粗细使其脱颖而出

很好的链接，@mdtauk。 我想，如果这是我们要走的路，我们可以用一个枚举来处理这个问题，该枚举具有诸如 [Auto, Vertical, Horizo​​ntal, Detached] 之类的值，其中 Auto 将更喜欢 Horizo​​ntal，直到紧凑性要求 Vertical。 想法？

另外，我更新了图片！ 我认为您是对的，灰色文本可能看起来像一个提示，如果遵循该提示，则会由于“=”而导致错误。

很好的链接，@mdtauk。 我想，如果这是我们要走的路，我们可以用一个枚举来处理这个问题，该枚举具有诸如 [Auto, Vertical, Horizo​​ntal, Detached] 之类的值，其中 Auto 将更喜欢 Horizo​​ntal，直到紧凑性要求 Vertical。 想法？

最初的想法是，在需要垂直方向的情况下，容器中的数量是否足够大？ AutoCompleteBox 不会移动它的搜索按钮，并且字符串通常比数字长。

如果它完全取决于可用空间，那么自动响应行为（如果该提案被批准）将比枚举更好。 在控件本身中为开发人员提供选项可能会导致控件的使用不一致，但我认为这需要成为用户研究必须考虑的东西，而不是由我们在 github 上单独规定。

开发人员总是可以选择重新模板化控件，如果他们_真的_需要控件的不同布局，并且可以包含一个替代样式，如果你想 A) 努力使默认和垂直样式和模板 - 和 B) 确保正确测试两种样式

@mdtauk我同意向上/向下符号是最好的。 我只是想展示一个例子，箭头在输入的两侧。 如前所述，这有助于确保用户不会按错，这在基于触摸的 UI 中几乎是强制性的。 我从 OneNote 给出的示例碰巧有 +/- 符号，但我应该添加以忽略符号本身。

@萨沃伊舒勒

[2] 提问时间：我们是否应该依赖 Xaml ControlTemplate 来创建一个带有不相交的 UpDownButtons 的 NumberBox（即，这不足以证明支持开箱即用），或者我们是否应该包含一个属性来设置 UpDownButtons 是否出现连续与不相交？

我知道 UWP 最初创建时首先是触摸 - 因此脱节的 UpDownButtons 可以说会更好。 从那时起，触摸优先的要求就放宽了，当用户使用鼠标等精确输入方法（移动距离更短）时，彼此相邻的按钮肯定会更好。 由于这取决于用例，我同意枚举对于指定 UpDownButtons 应如何显示很有用。

对于枚举值，我们已经讨论了几种状态，概括地说，我们可以添加更多状态：

• SeparatedHorizo​​ntal ：左侧向下箭头，右侧向上箭头
• 分离垂直：底部的向下箭头，顶部的向上箭头
• 左 ：在左侧彼此相邻的向下和向上箭头（水平方向）
• 右 ：在右侧彼此相邻的向下和向上箭头（水平方向）
• 顶部 ：向下和向上箭头在顶部彼此相邻（垂直方向）
• 底部 ：向下和向上箭头在底部彼此相邻（垂直方向）

如果所有这些都变得太复杂（因为它很快），我很乐意在 XAML 中为我自己的用例重新模板化控件。

只是抛出另一个想法：改变脱节的 UpDownButtons 符号的方向也可能有意义 [<] 123 [>] 。 随意忽略这种增加的复杂性，因为这当然可以在每个应用程序的基础上重新设计。

此外，一些可访问性问题可能已经在 OneNote 中得到解决，这是我从中提取示例的地方。

@robloo我认为您提到的左右位置应该保留用于 RtL 和 LtR 本地化 - 而不是谨慎的设置。

以下是我的意见

我也不确定将按钮放在文本字段上方是否在语义上有意义，更不用说当您将手指放在按钮上时，可能很难看到数字的变化。

将每个组合都内置到控件中会导致使用混乱，如果有迫切需要，所有这些事情都可以通过重新模板来完成。

文本字段下方的按钮可能在空间受限的区域中使用，并且作为控件本身的一个选项，因为它使按钮变得更大以供点击。 无论是作为与控件捆绑的样式，还是介于两者之间的枚举：

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

只是一个简单的问题可能的建议：理论上，在数字框中，一个人应该只能在数字框中输入数字。 解析书面数字并将它们转换为这些字段的实际数字有多难？

例如：
一 + 二 = 3
翻译
1 + 2 = 3

或者
一加二等于三
翻译成
1 + 2 = 3

这只是一个想法。

只是一个简单的问题可能的建议：理论上，在数字框中，一个人应该只能在数字框中输入数字。 解析书面数字并将它们转换为这些字段的实际数字有多难？

例如：
一 + 二 = 3
翻译
1 + 2 = 3

或者
一加二等于三
翻译成
1 + 2 = 3

这只是一个想法。

这对英语来说是有道理的。 当您需要为其他语言翻译和解析这些字符串时，这就会成为一个问题。 一个波兰语用户，输入英文单词呢？

现在，只讨论了数字 0-9、小数、数字分隔符和数学运算符的形式。 但其他数字系统可能需要满足。

添加语言翻译将是一项巨大的努力，目前尚不清楚会有什么好处。

现在，如果要通过音频输入操作此控件，那么说出数字或操作 - 这可能涉及解释所讲的语言。

叙述者：
“没有值的像素 NumberBox”

用户：
《一百二十八个像素》

[ 128 _________ | 像素]

用户：
“添加六十四个像素”

[ 192 _________ | 像素]

叙述者：
《一百九十二个像素》

[1] 提问时间：是否有人反对验证系统，该系统会自动将不可接受的输入恢复为之前的值，同时公开允许开发人员取消此行为并决定做什么/引发错误指示器或消息的事件？

如果输入的Text无效，为什么Value会更改为旧的？ 我不认为试图保持“最后知道的好Value ”是控件需要负责的事情。 让控件处理单个当前值（或错误状态），并让应用根据需要通过ValueChanged事件处理任何额外的历史处理。

对于初始版本，我认为只支持向上/向下按钮的单个位置就可以了，因为它们可以在必要时重新模板化。
如果确定向上/向下按钮的位置的能力被认为是必要的，那么添加的任何枚举都应该消除对UpDownButtonsEnabled属性的需求，并且Hidden的枚举值可以是代替。
另请注意，内置对操纵向上/向下按钮位置的支持将增加复杂性，任何需要为提供的选项以外的任何内容调整模板的人都会增加复杂性。

@shaheedmalik ，以及出色而直观的想法。 你检查过规格吗？ 我们有一个 ValueChanged 事件，它允许您拦截该输入并手动将键入的数字解析为数字值 - 这将是一种可能的体验，尤其是当您考虑使用特定语言时。 至于在控件的默认 V1 中烘焙全局语言解析器 - @mdtauk是正确的，它会增加复杂性和开销，需要大量论证。 开源这些控件的一个好处是它们可以由社区分叉。 在这种情况下，您或其他社区成员可以创建此控件的特定于语言的变体。 我相信这将是使 NumberBox 的语言解析版本民主化的最现实的途径。

@mrlacey ，您是否有机会回顾@robloo对整个 Windows 中使用的NumberBox类似控件的比较分析？ 将这些字段重置为最后一个有效的仅数字输入的行为实际上在系统范围内具有先例 - 这意味着将按下控件本身或开发人员指南以与此模式对齐。 我的倾向是将这种控制与标准 Windows 体验保持一致，并为必要的偏差创造一条途径，而不是标准化偏离生态系统其余部分的行为，并主张创建此系统默认行为的指南，因为后者会创建对于普通情况，简单而高效。 我鼓励不同意见，所以如果您认为这给控制增加了不必要的复杂性，或者，也许我们应该重新评估这个先例，请告诉我？

| 标题 | 图片 | 评论 |
|------|-----|------------|
| UWP OneNote 字体大小输入| | 任何值都可以从键盘输入，它会自动验证并在失去焦点时重置为最后一个有效值 |
| 桌面 Word 字体大小条目 | | 任何值都可以从键盘输入，它会在失去焦点时自动验证，如果无效则会出现错误消息。 单击 [确定] 将重置为最后一个有效值。 |
| UWP OneNote 二维图 | | 可以从键盘输入任何值。 无效值将被简单地忽略，并在计算中使用最后一个有效输入（不会在失去焦点时进行验证）。 按下增量 +/- 按钮将使用最后一个有效输入进行增量。 |
| 桌面字形状大小条目 | | 任何值都可以从键盘输入，它在失去焦点时自动验证并在失去焦点时重置为最后一个有效值。 |

@mdtauk ，请注意您对 LTR 和 RTL 语言的评论以及出现 UpDownButtons 的控件一侧。 我将由本地化专家来运行它，以确保这是一个需要考虑的考虑因素。

@mrlacey你也对，布尔值对于枚举来说是多余的。 我会尽快验证是否需要任何替代配置。

@adrientetar ，您是我们垂直按钮的主要客户。 你有屏幕截图或上下文可以帮助我更好地了解你的空间限制吗？ @mdtauk 早些时候让我想到了这个回复：

最初的想法是，在需要垂直方向的情况下，容器中的数量是否足够大？ AutoCompleteBox 不会移动它的搜索按钮，并且字符串通常比数字长。

@SavoySchuler （关于重置为最后一个好的值）由于规范将为@robloo评论中的控件，我希望能够更多地利用这些功能。

考虑一下：

1. 带有AllowsCalculations=True NumberBox
2. 手动输入 1100 和 Tab 到下一个控件
3. 意识到这不是想要进入的
4. 返回控件并输入“99 x 12”
5. 选项卡到下一个控件，并且值恢复为显示“1100”（“x”与“*”不同，因此它将在计算步骤中失败。或者考虑任何其他无效计算，如果“x”不会失败）如果按下则不显示。）
6. 它现在显示一个不是计算结果的值，不显示错误消息，并且输入的总和丢失，因此没有发生什么的记录。

当第 5 步的下一个控件的选项卡时我想要发生的事情是

• "99 x 12" 仍然是Text值
• 显示错误状态。
• ValueChanged事件触发并传递（Text='99 x 12', OldValue=1100, NewValue=Double.NaN）
• 然后用户可以看到有问题
• 用户无需重新输入整个金额即可更正问题。
• 如有必要，代码/应用程序逻辑能够做一些适当的事情。

如果要在进入时自动恢复到最后一个已知的好值：

• 除了在必填字段中未输入任何值时，是否会指示错误状态？
• ValueChanged事件的价值不是因为它永远不会报告无效状态而大大减少了吗？

@SavoySchuler @mrlacey在其他 Microsoft 应用程序中查看这些示例...

应排除任何模式弹出窗口。 相反，这应该由控件本身的验证状态来处理。

图片

如果存在无效的值，则内容可能应该保持无效状态，但仅当控件处于焦点时。 如果焦点丢失，文本字段值会恢复，但验证通知会显示用户输入的内容？

InputScope：数字还是公式数字？

如前所述（在 PR 评论中）， FormulaNumber不包括此处和规范中所有计算示例都包含的“空间”。 FormulaNumber 还包括此控件不支持的数学符号

我投票给“数字”

数字

公式编号

@SavoySchuler我的意思是我只是在制作一个桌面应用程序（不是试图制作我自己的 Excel 版本或任何东西）。 我想我会完全禁用箭头，我认为鼠标拖动就足够了。 如果计划了鼠标拖动，那么可能应该在每次更改时触发值更改，因为在这种情况下用户希望预览一系列可能的更改。 侧边栏：

顺便说一句，TextBox 内容不会垂直居中，这是 VerticalContentAlignment="Center"。

它看起来类似于 Paint 3D 使用的那种属性侧边栏（它也使用它自己的控件样式和更薄的轻边框，以及看起来像后缀属性的东西）

如果不实现拖动，那么您始终可以执行 Paint 3D 所做的操作，并将滑块绑定到 NumberBox。

它也类似于 Adob​​e 在其控件上有一个下拉滑块。

@adrientetar你似乎在那里做你自己的

对于 NumberBox，可能存在具有视觉居中字符的情况，但是这些 NumberBox 在放置在标准 TextBox 或 TextBox 派生控件（如 ComboBox）旁边时不会对齐。

在制作默认模板和样式时，您应该考虑各种Windows.UI.Xaml.Documents.Typography属性...

• Typography.CaseSensitiveForms
• Typography.NumeralAlignment + Typography.NumeralStyle（表格可能比比例更可取）

@mrlacey ，你提出了一个有效的论点。 根据来自@adrientetar的回复，以下场景如何：

值/文本更改事件在 _every_ 更改时触发（对于拖动/滚动用户测试范围的情况），因此，在显示错误消息和指示符的情况下，可以持续进行验证，直到按下“Enter”/焦点丢失，在在这种情况下，验证值覆盖开始并覆盖最后一个好的值（除非该行为被其各自的属性禁用）。

今天下午我将与团队聊天，以验证持续事件触发/验证是否是一个现实的想法 - 否则我们可能会以另一种方式构建范围边界。

@mdtauk ，但我相信您对验证的视觉表示的断言是正确的。 @LucasHaines ，你能仔细检查一下吗？

@jevansaks ，您能否权衡下面的 InputScope 考虑因素？

如前所述（在 PR 评论中）， FormulaNumber不包括此处和规范中所有计算示例都包含的“空间”。 FormulaNumber 还包括此控件不支持的数学符号

我投票给“数字”

数字

公式编号

@SavoySchuler这个

每次更改时都会触发值/文本更改事件（对于拖动/滚动用户测试范围的情况），因此，可以在显示错误消息和指示器的情况下持续进行验证，直到按下“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 事件在开发人员端实现，并进行额外的工作。

抄送@SavoySchuler

很棒的主意，@KevinTXY。 如果我们这里的任何开发人员需要类似的东西，我们可以考虑添加它！

提问时间：有没有人有任何真实的应用场景证明需要支持十六进制或二进制？ 包装最大值/最小值？

我想看看像 ValuesWrap 属性这样的东西在这里是否有意义。

是的，如果你喜欢一个角度属性，你想要 359 → 0，基本上是 mod 360。有趣的是我仍然必须对控件进行子类化（在 Qt 中），因为 MaxValue 只能包含在内，所以我可以指定 359 或360，但我真的希望能够写 359.99 而不是 360（即我想要 <，而不是 ≤）。

QSpinBox 确实具有用于此目的的包装属性https://doc.qt.io/qt-5/qabstractspinbox.html#wrapping -prop

@SavoySchuler关于十六进制，我怀疑十六进制编辑器可能需要它，但它似乎是一个非常小众的用例，您不必支持所有可能的东西，只需确保控件易于子类化即可。 在 Qt 中，控件有一个方法可以将文本框字符串转换为可以被覆盖的数值（int 或 double）。

例如，如果启用了 IsInvalidInputOverwritten，StepSize=0.2，MaxValue=3.0，并且值 2.9 递增，则 3.1 将注册为无效，并将被覆盖回 2.9。

在这种情况下，您可能会钳制 MaxValue。

@SavoySchler @xyzzer @mrlacey我在 twitter 上看到

这可能会干扰我们谈到的预览完成功能，并且可能需要在 NumberBox 控件中进行一些抑制。 来到 Win32 和 XAML 控件似乎......

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

我认为处理十六进制或二进制比处理电话号码和邮政编码等“看起来像数字的字符串”更专业。 （并带来自己的复杂性）
因此，我认为它们应该超出 NumberBox 控件的范围。

说到预览计算功能，万一错过了，我建议让用户选择打开/关闭它。 所以也许添加一个属性

public bool ShowPreviewResult { get; set; }

为什么要显示预览结果？ 🤔 不像用户会根据结果改变他们的公式，如果他们知道他们想要的结果，他们会直接输入

为什么要显示预览结果？ 🤔 不像用户会根据结果输入什么，如果他们知道他们想要什么，他们就会直接输入

控件的功能之一是能够输入计算，如32 * 4将解析为128 - 预览功能将显示当控件失去焦点或按下 Enter 时的结果。

@adrientetar预览目前是一个暂定功能。 我相信在控件的验证开始之前，该值将部分存在于面向用户的验证中，例如，它仅显示输入的内容是否可以计算/在边界内； 例如，验证期望（“我击中了时间而不是加号？”）。 这里的利息和投资回报尚不清楚。

再次感谢大家的反馈！ 看起来目前没有迫切需要或保证对二进制或十六进制支持的兴趣。 也可以根据需要对其进行子类化、建议为新控件或建议用于 V2。

@SavoySchuler关于“有没有人有任何真实的应用程序场景证明需要支持十六进制或二进制？”，一个例子是 WinUI 自己的 ColorPicker 控件。 它包括一个十六进制输入框。 它还包括许多其他数字条目文本框。 可能值得研究更新 ColorPicker 以使用新的 NumberBox 控件作为验证新控件的方法的可能性。 如果 NumberBox 可以简化 ColorPicker 的当前实现，那将是一个胜利。

如果文本框的更薄边框样式没有通过@chigy和 WinUI 设计团队的决策 - 我想我应该准备一个与当前文本框设计建议相匹配的设计模型。

@kmahone - 同意。 正如你今天早上在饮水机上提到的那样，通过用 NumberBox 替换它的 TextBox 实例和本地验证逻辑，能够从 ColorPicker 中删除大量代码，这本身就是一种胜利。

@mdtauk - 我告诉过你太多次你的模型看起来不可思议吗？ 我很快就会把这些纳入规范！

@SavoySchuler如果 Windows 设计团队决定站在 Fabric Web 团队一边，从 2 epx 粗边框移动到 1epx 边框 - 我认为这最适合 NumberBox - 但实际上，Windows 设计团队可能会挖掘他们的脚后跟并保持较厚的边框。

当然，@mdtauk！ 我希望在不久的将来在这里锁定@KevinTXY的功能需求，然后我将转移到与@chigy （他一直忙于在#524 上做了一件了不起的工作）的设计融合对话！

感谢大家的所有讨论，我很高兴能在今年夏天以实习生的身份参与此功能的开发！

如果它与任何人相关，我已经在以下存储库中启动了控件的 C# 原型。
https://github.com/KevinTXY/NumberBox

这基本上是我第一次学习 C#/UWP，所以它会慢慢来，如果有人看它，我很高兴得到关于可以做得更好的反馈！

大致实现了以下功能：

• 数字输入验证（尚未遵循验证建议规范，将等待代码）
• 值存储/绑定
• 调零
• 完整的计算器/公式输入支持

目前正在研究微调按钮和测试应用程序以及最小/最大验证。

干杯!

时间线更新！

我已经将一些更新、建议和反馈整合到规范中，我将在今天（星期四）与 WinUI 团队进行验证。 我希望或多或少地完成 V1 的 API 和行为组件。

现在，我将进入输入和可访问性、数据和智能以及可视化组件。

最后一步将是整理文档和形成指南。

我认为脱节和连续的选项非常小众，没有微软的第一方应用程序/外壳 UI 在 WPF 或 Win32 中需要做的用例。

如果你想包含它，我宁愿它是一个可以应用于控件的包含样式，而不是一个选项。 在新模板中，重新模板化的 NumberBox 控件将如何处理该属性？

如果一致认为应该包含此模式，那么我是否建议将其作为SpinButtonPlacementMode 的一部分作为枚举值。 不确定这个选项会被称为什么。 _Straddled_ 可能不够专业，哈哈，我不确定 _Bookended_ 是否更好。

我只是在查看 Edge 的最新 Canary 版本，并看到了最接近 NumberBox 控件的<input type="number"/>的设计。

只是想我会分享它的这张图片。

@mdtauk - 同意，SpinButtonPlacementMode 将是添加备用 SpinButton 放置选项的正确位置。

关于名称的话题，@Felix-Dev 在规范中正确地指出 SpinButton 可能不是最直观或最知名的名称。 SpinBox 和 UpDownButtons 在 Windows 生态系统中也具有优先权。 我将很快对此进行探讨，但请让我知道是否有人反对这些选项中的任何一个。

@mdtauk - 感谢您分享！ 我也在运行 Canary，所以我会看看是否有我们可以学习的东西，或者是否有任何建议调整发展的空间！

@SavoySchuler我正在使用Fluent Controls 标志Enabled（包括实验性控件）

我认为 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 属性来指定数字和分组分隔符吗？

这些设置通常来自“区域”，所以我认为我们只需将HomeGeographicRegion传递给 DecimalFormatter 构造函数。 我在 API 中没有看到允许用户自定义区域的任何其他地方（我们的日期/时间格式化程序似乎不可自定义？），但是选择器确实允许自定义格式字符串，所以也许我们可以允许这里也是。

我没有看到在 DecimalFormatter API 中自定义分隔符的方法，因此必须从语言设置中提取这些字符。 😖

@jevansaks ，感谢您的洞察力！ 我会标记@sonnemaf以确保他看到回复。

@jevansaks你能写一个 xaml 示例如何为

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

很抱歉打断我刚刚发现这个话题，但 YES YES YES。 两者都在数字控件中经常丢失，我和 github 上的许多其他开发人员必须为它构建解决方法。 特别是对于计算器示例，它不仅应该以十六进制格式化数字，而且还应该完全支持输入。

此时我想建议您使十六进制的前缀可自定义。 在某些时候，最好完全没有前缀，而在其他方面，它并不总是0x

你能写一个 xaml 例子如何为 NumberBox 设置 DecimalFormatter 吗？ 我想在 XAML 中而不是从代码隐藏中定义它。 拥有 DecimalSymbol 和 GroupingSymbol 属性也适用于我。 不过，这可能太容易了。

@sonnemaf我们在 WinRT 中必须使用的只是 DecimalFormatter，不幸的是它不允许您自定义这些设置。 自定义十进制符号或分组符号的唯一方法是通过操作系统区域控制面板中的用户设置（据我所知）。

尊重用户区域的这些设置似乎是正确的——您是否有需要覆盖它们的场景？

@sonnemaf

有没有人有任何真实的应用场景证明需要支持十六进制或二进制？

抱歉，我注意到了这一点，回复得有点晚。 我相信十六进制/二进制支持会非常有帮助。 我大量参与了.NET IoT项目，我们主要在十六进制/二进制世界中工作，因为我们正在操纵读取/写入寄存器和引脚以控制事物的位/字节。

支持十六进制/二进制将非常感激。 😄😄

我不需要十六进制或二进制。 这将是一个“很好的拥有”，尤其是二进制。

开发更新

嗨，大家好！ 我们对 NumberBox 规范感到满意，我只想提请注意，我正在积极致力于控制，理想情况下，最重要功能的第一个 PR 将很快发布，可能是今晚。

一些注意事项：

• 我们选择不继承 TextBox，特别是由于 InputValidation 的一些设计复杂性，NumberBox 将是它自己的包含 TextBox 的控件。
  
  
  
  • 这确实意味着不会公开所有 TextBox 属性。 我很想知道这些是否对 NumberBox 很重要 - 我可以看到对 _Header、PlaceHolderText_ 和 _Text_ 的渴望？ 绝对想稍微打开这个，因为对我来说这是一个非常容易的改变。
  
  
• 我一直在对规范进行非常小的编辑，目前这些主要只是措辞上的更正，但仍然存在诸如值预览之类的悬而未决的问题，并且在我编写控件时，我正在生成一些我自己的设计问题。 这仍然是添加输入的好时机😄

@KevinTXY有一个建议是从 Slider 基础而不是 TextBox 派生 - 这是已选择的吗？

• 占位符文本
• 标题
• 文本
• 验证图标
• 验证消息
• 选择前景
• 选择背景
• 焦点状态/资源等

这些是我认为需要的一些 TextBox 东西。 不确定“清除文本”按钮，这对于长文本字符串更有意义。

价值预览我认为是 V2 的功能，但这有改变吗？ 当拇指滑动时，Slider 控件有一个显示值的工具提示。 我建议将此作为处理它的一种方法，以及使用验证消息来处理此问题，或将其显示为内联。

Inline 存在一个问题，即 Windows Insider 构建了对预测性文本补全的试验，无论是作为工具提示出现，还是出现在文本字段中。 无论选择哪种预览方法，它都不应与这些方法冲突，也不应与为此控件关闭的预测功能发生冲突。

@KevinTXY有一个建议是从 Slider 基础而不是 TextBox 派生 - 这是已选择的吗？

NumberBox 目前是它自己的控件（扩展 Windows.UI.Xaml.Controls.Control），它在其标记中包含一个 TextBox，而不是扩展 TextBox。 Slider 听起来很有趣，但我认为它会导致实现有点笨拙，这些控件中还有很多我们觉得不属于 NumberBox 的属性。 我不是 PM，但根据我的开发经验，我觉得这是简化开发和未来可扩展性的好方法。

这些是我认为需要的一些 TextBox 东西。 不确定“清除文本”按钮，这对于长文本字符串更有意义。

这太棒了——正是我想要的！ 我同意所有这些都是有价值的。 Clear All 按钮目前存在，因为它是 TextBox 的默认功能 - 我认为它对大条目或触摸屏用户有价值，尽管我还没有真正考虑禁用它。 我绝对至少会尝试将我提到的三个（标题、占位符文本、文本）放入预览中。

至于价值预览，那里没有最终确定，它只是在规范中作为一个悬而未决的问题。 我想最简单的临时解决方案是简单地为开发人员公开预览值以按他们的意愿显示 - 这可能很容易在预览版本的范围内，但我会将它留给@SavoySchuler & Co. 进行调用。 无论如何，在我研究数学引擎的过程中，计算可能至少在几天内都无法进入我的 PR，所以这不是一个紧迫的细节。 我很欣赏所做的研究，这里有很多有趣的想法！

@KevinTXY理想情况下，将与 Calculator 团队合作，创建一个可以嵌入的基本计算引擎 - 以及供将来与与此控件一起讨论的CalculatorPicker想法一起使用。 （带有计算器按钮的控件，显示带有标准计算器的弹出按钮）

实际上，与 Calculator 维护者合作听起来是个好主意。 您可以从 Calculator 公开一个应用程序服务来执行数学计算，因此您甚至不需要加载 WinUI 二进制文件 - 如果应用程序已安装，只需与应用程序服务交谈，否则 - 只是静默失败。

至于从 Slider 派生 - 我确实说过RangeBase并且我仍然非常有信心这是正确的做法，因为该控件基本上提供了您需要的几乎所有属性和可访问性功能，并且从中派生将提供一致的 API 表面您的控件和滑块使它们成为易于更换的替代品。

啊，是的，RangeBase，就是这样。

计算器最近刚刚完成了支持始终在顶部的 CompactOverlay 模式的工作 - 因此将较小的键盘放入与 CalendarFlyout 大小相似的弹出窗口 - 更容易实现。 （如果 CalculatorBox 控件被批准包含在内。

不确定它是否是一个应用程序服务（它将链接 WinUI 更新，半依赖于计算器存储更新 - 或者它是否是一个可以添加到 WinUI 并从计算器引擎派生的服务二进制文件。

更新：代码公关现已存在🎆！

我正在跟踪那里的一些问题，尽管大多数与设计无关。

谢谢@xyzzer和@mdtauk！ 我们已经检查了 RangeBase，它似乎承载了与子类化 TextBox 一样多的包袱。 到目前为止，我们将坚持在控件中包含一个 TextBox 并仅添加必要的属性和辅助功能。 这仍然是一个值得考虑的问题，并有助于告知我们现在正在进行的可访问性对话。

@mdtauk ，谢谢你的起始名单！ @KevinTXY已开始公开您列出的 API，我将很快审查其余部分。

预览和弹出计算器，如@KevinTXY提到的，在会谈中（虽然这里没有 v1 保证）。 我们正在积极与 Calculator 讨论对齐和可利用的工作。 你们真棒！ 感谢您继续推动此控件的创新。 这很棒。 @KevinTXY在上面发布了他的代码公关。 在进行指导和文档起草之前不久，我将整理规范中所有剩余的松散部分。

命名

规范远离我的评论太多了，所以我只是在事情安定下来后才开始看看。 首先，我注意到一些命名并不真正遵循 C# 约定——是的，我知道这些控件是用 C++ 编写的，但我仍然认为它与平台中的其他命名不一致。

| 类型 | 当前名称 | 提议名称 |
|-------|----------------|-------------------|
| 布尔值 | 接受计算 | IsCalculationAccepted |
| 布尔值 | HyperDragEnabled | IsHyperDragEnabled |
| 布尔值 | HyperScrollEnabled | IsHyperScrollEnabled |

步进频率

另外，什么是步进频率？ 这在规范中没有定义，我对“XAML 工具包的 NumericUpDown”没有任何经验。 根据它的作用，添加单词频率可能没有意义。 这可能只是一个“步骤”？ 在 Slider 控件中，TickFrequency 是有意义的，因为刻度显示在整个 max-min 范围的模数上。 但是，在此控件中，我认为这只是最小增量/步长。 从根本上说，用户是否能够输入步骤之外的值？

例如 MinValue = 0, MaxValue = 6, StepFrequency = 2。使用向上箭头值将是 {2, 4, 6} 足够公平。 用户可以输入 0.5 作为有效值吗？ 还是会根据 RoundingMode 舍入为 0 或 2？

最小值/最大值

对于下面的两个属性，我认为它们应该像其他控件（Slider、RangeBase）一样是最小值和最大值。 API 应该是一致的。
双最小值；
双最大值；

UpDown 重复按钮

据我所知，另一个尚未讨论的功能是是否使向上/向下按钮实际上是RepeatButtons（我认为它们应该是）。 如果它们是重复按钮，则应像 Slider 控件一样添加 Delay/Interval 属性： Slider.Interval Slider.Delay

数字

您能否为 IntegerDigits 和 FractionDigits 所代表的内容添加说明？ 我的猜测是他们限制了数字每个部分的位数。 IntegerDigits = 2 表示最大值可以是 99。FractionDigits = 3 表示 MaxValue 可以是 0.999。 另外，重要数字如何覆盖这两个属性？

负零？

为什么需要这个属性？ 那是本地化本身吗？ 我从未见过“-0.0”或“-0”。 它始终只是“0”。
布尔值 IsZeroSigned；

本土化

我坚信我需要这个控件来支持覆盖 UI 本地化和数字格式。 我有多种用途（金融应用程序），我需要以不同方式显示的本地和外国金额。 我在规范中的任何地方都没有看到这一点。

本着 Slider.ThumbToolTipValueConverter 的精神，从 double 转换为文本应该可以通过 ValueConverter 进行自定义。 这样，最复杂的部分可以根据任何需求进行定制，就像下面的一些现实世界的例子：

请注意，数字和货币的小数分隔符以及负和的指定可能不同，因此对于没有 ValueConverter 的 NumericBox 来说，最安全的方法可能是在整数模式下运行。 Calculator 也可以作为 ValueConverter 来实现，没有必要用这个工作来重载控制。

@eugenegff您有一个非常好的主意，可以将数字转换为字符串通用。 这将让我处理本地化，但也允许开发人员做任何他们想做的事情，比如添加单位。

我看到的唯一复杂性是保持与控件相关的 Culture/NumberFormatInfo。 我想这可能是 XAML 中的一个转换器参数，用于自定义 IValueConverter，但可能应该有一种更清晰的方法来在控件本身中处理此问题。

为什么需要这个属性？ 那是本地化本身吗？ 我从未见过“-0.0”或“-0”。 它始终只是“0”。

它是 Windows 中DecimalFormatter类的一个属性。 很奇怪吗？ 大概。 我们遗漏了一些属性，例如 IsGrouped 和本地化属性，因此也许这也不是必需的。 同时它也已经实现，因此删除它除了解压 3 行代码之外没有任何意义。 有趣的是，有符号零的用法和 IEEE 先决条件。

我坚信我需要这个控件来支持覆盖 UI 本地化和数字格式。 我有多种用途（金融应用程序），我需要以不同方式显示的本地和外国金额。 我在规范中的任何地方都没有看到这一点。

@SavoySchuler也许我们应该考虑支持 DecimalFormatter 类中的语言设置？ 我不熟悉它的行为方式。

好的，我想我明白这里的根本问题了。 在 C++ 世界中，您可以访问 DecimalFormatter，但在 C# 世界中（如果我使用 WinUI），我通常会使用 IFormatProvider（来自指定文化的 NumberFormatInfo）。 NumberFormatInfo 已经拥有大部分属性（巧合的是缺少 IsZeroSigned）所以我在想只允许开发人员指定该属性或 IFormatProvider。 好吧，问题来了，C++ 不能使用 IFormatProvider，因为它来自 .net 世界。

那么，考虑到 C# 和 C++ 有两种不同的实现方式，该控件如何完全支持本地化？ 好吧，除非微软有一个聪明的解决方案，否则我只能想到两种可能性：

1. 完全添加数字格式的所有属性（有效地重新实现 NumberFormatInfo 和 DecimalFormatter）。 仅添加 IsZeroSigned、IntegerDigits、FractionalDigits 等不会涵盖它。 NumberNegativePattern、NumberGroupSeparator、NumberGroupSizes 等也是必需的。
2. 按照@eugenegff 的建议进行操作，并允许开发人员使用某种回调覆盖格式。 老实说，这似乎是最简单的方法。

我有点担心本地化在这个控件中是如何形成的。 我从一开始就提出本地化（关于这个话题的第三条评论！）。 当控件转换为字符串时，必须有某种方法来完全自定义数字格式。 否则，这种控制在现实世界中的使用将非常有限。

那么，考虑到 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 进行 value <=> 文本转换，否则 NumberBox 不适合我们。

我认为这些功能的使用非常罕见，我的应用程序中有一个角度输入，但它只是一个度数值。 对我来说最重要的用途是能够为现有值添加一个值或将现有值除以一个数字，只是为了节省时间并避免在头脑中进行计算。 （顺便说一句，我认为这就是 Adob​​e 应用程序所拥有的 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 进行 value <=> 文本转换，否则 NumberBox 不适合我们。

我查看了您提供的 Slider 示例，这听起来很合理 - 我可以在 NumBox 的 IValueConverter 中看到值。 我很快就会研究它，我们将尝试确定它是否适合规范。 不过还没有任何承诺！

@KevinTXY我怀疑添加你上面提到的功能会打开比它可能提供的价值更多的问题的大门。 这是因为它允许在控件中输入更多的字符（基本上是任何字母）。 反过来，这会使意外输入无效内容变得更容易，并且还会增加验证和解析的复杂性。
它还会破坏规范开头的描述的第一行“数字框是仅数字文本控件......”。

我很惊讶还有关于本地化的问题。 由于控件将（必须？）从FrameworkElement继承，它可以访问Language 属性，因此，与其他所有 FrameworkElement 一样，支持直接设置区域设置，而不依赖于系统区域设置 UI 设置。
这意味着可以在每个实例的基础上设置十进制和分组字符等内容。

我很惊讶还有关于本地化的问题。

问题是语言不是控制格式的东西，而是区域/文化设置。 本地化是将 UI 字符串更新为以正确的语言显示，而数字/货币/日期时间格式由区域控制。 更多信息请访问： https :

问题是语言不是控制格式的东西，而是区域/文化设置。 本地化是将 UI 字符串更新为以正确的语言显示，而数字/货币/日期时间格式由区域控制。 更多信息请访问： https :

Language接受一个转换为CultureInfo注意，在非托管代码开发中，文化被称为语言环境。 这包含NumberFormat属性，该属性是NumberFormatInfo类型，其中包含小数、分组、负号等属性。

我的理解是，如果您想在控件上强制使用特定格式或其他本地化细节，而不是依赖系统设置，那么这样做的方法是指定Language 。

该属性的描述明确指出它“设置适用于 FrameworkElement 的本地化/全球化语言信息”

或者，也许我误解了我引用的文档，但它们似乎都支持您链接到的页面中所涵盖的内容。
也许这是 C++ 和 C# 使用不同术语的术语问题。
我所知道的是，在 XAML 中设置语言是我如何在任何其他应用程序和任何其他控件中强制使用文化/区域设置。

我在本地化方面看到的问题是关于强制使用特定的数字格式，或组和小数点分隔符。 或者是真正的问题，如何在不影响控件的基于文本的属性（Header、PlaceholderText 等）的本地化的情况下控制这些？

Language需要一个被转换成CultureInfo

不是在本机/WinRT 中，我们只是得到一个 BCP-47 langs 字符串。 这就是问题所在。 在 .NET 中，您捆绑了具有语言设置和格式设置的 CultureInfo。 在 WinRT 中，它是独立的，并且没有与 CultureInfo 对象等效的对象。

我听说ICU API可以实现我们正在寻找的功能，但我们还没有机会对此进行调查。

我认为微软将不得不考虑在这个问题上咬紧牙关，全面实现 .net 文化/本地化 (CultureInfo) 和本机/WinRT 之间的转换机制。 理想情况下，您不会考虑采用新的做事方式：

我认为大多数 LOB 应用程序都是用托管代码编写的，这需要从一开始就正确完成。 WinRT 需要获得与 .net 相同的本地化机制/技术，并且转换需要是自动的。

那会是更多的工作吗？ 短期：是，长期：否。 这可能会延迟 NumberBox 控件的发布吗？ 可能，除非在短期内使用回调。

不过，这需要正确完成，否则其他地方就会出现问题。 我已经可以预见其他场景的一些类似问题，如可编辑的 CalendarDatePicker 等。 (#735)

@SavoySchuler @jevansaks @chigy @mrlacey @KevinTXY
显然 FastDNA 团队也在为他们的 Input Number Field 设计做 Spinner 控件的工作，他们提出了一个可能值得考虑的建议。

他们还问我们为什么使用 V 形而不是箭头。

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

即使我们将按钮并排放置，将堆叠扩展设计作为悬停，当控件宽度太窄时可能是一个想法？ 也许可以就适用于所有 Microsoft UI 框架的布局达成一些共识？

@mdtauk ，感谢您让我们知道。
如果这是他们正在测试和验证可用性的设计，请与 FastDNA 人员核对。

回到 NumberBox

好的团队，

为意外的休息道歉。 我回到了NumberBox 全速前进， 行列，成为我们的功能开发人员！ 我们仍将这个控件的预览版定在 11 月底，这将使我们看到 WinUI 2.4 的稳定版本。

旧工作流程中有很多包袱，因此我将保留所有未解决或已回答的问题，并将它们移植到新的规范 PR 中， @teaP和我将完成解决有关以下方面的剩余

• 本土化
• 设计（特别是关于向上/向下按钮）
• 超滚动/超拖拽

请注意，验证主题已解决。 随着@LucasHaines的输入验证工作计划在 WinUI 3.0 和 NumberBox 计划发布之前进行，我们已将 NumberBox V1 支持的验证模式减少到：

枚举 NumberBoxBasicValidationMode
{
残障人士，
无效输入覆盖，
};

随着 WinUI 3.0 和并存的输入验证工作的到来，我们将寻求在 NumberBox V2 中使用最初计划的 IconMessage 和 TextBlockMessage 验证模式扩展该枚举。

我现在将结束我们以前的所有进展，我将发布问题并征求相关的反馈。 感谢您与我们在一起。 😄

呼。 尝试自己做这件事离我越来越近了。

哈哈，我本来想被动地继续做这件事，但这个学期让我筋疲力尽。 很高兴看到它被包裹起来，我会密切关注它！

NumberBox 的初始提交现已上线！

请 - 请记住，这仍然是一项正在进行的工作，在开发和PM方面都进行了积极的问题跟踪。 如果您在任何适当的链接中都没有注意到功能上的错误或一般松散的结局，请随时告诉我们。 😊

@SavoySchuler ，你会为规范打开一个新的 PR 吗？ 另外，您是否注意到我在此评论中特别是围绕 NaN 显示所写的内容？ 谢谢。

@SavoySchuler到目前为止对规范/

步进频率

在这里使用“频率”这个词并不适合我。 在 Slider 控件中，TickFrequency 是有意义的，因为刻度是根据整个 max-min 范围的模数计算和显示的。 然而，在这个控件中，它只是增量/步长。 它更像是“StepAmount”或“StepValue”——更好的是“Step”类似于“Minimum”而不是“MinimumValue”。

此外，用户是否能够输入定义步骤之外的值？
例如最小值 = 0，最大值 = 6，StepFrequency = 2。使用向上箭头值将是 {2, 4, 6} 足够公平。 用户可以输入 0.5 作为有效值吗？ 还是会四舍五入为 0 或 2？

四舍五入

如何处理数学四舍五入？ 这在使用表达式输入货币值时尤其重要。 我们需要能够在计算表达式后指定 -- 或提供 -- 自定义舍入。 HalfAwayFromZero 是我想要开始的，但也应该允许其他舍入模式。

本土化

请确认 NumberBox 将接受任何 INumberFormatter/ INumberFormatter2实现——并将在未来继续这样做（这就是它在代码中的实现方式，我只是想确保规范也将其标出）。 与使用现有的 CurrencyFormatter/DecimalFormatter 相比，这应该允许完全控制文本的本地化。 太好了，我们有解决方案！

文字环绕

编辑：下次我应该阅读整个规范。

为什么要创建新的“IsWrapEnabled”属性？ 是不是因为您觉得“文本”一词不适用于 NumberBox？

另外，我知道 Wrap 和 WrapWithOverflow 的实现可能相同，但只允许两个枚举值相等并在文档中描述功能。

正确处理键盘加速器

请确保此控件比 TextBox 更支持使用键盘加速器。 也许这在/如果 TextBox 被修复之前无法完成，但 #1435 对我来说确实是一个问题，会导致很多丑陋的解决方法。 TextBox 将自行处理“Ctrl+V”粘贴，然后将引发任何 KeyboardAccelerator。 但是，在 KeyboardAccelerator 中无法知道 TextBox 只是做了它自己的事情。

一个快速的想法。 是否应该有一个角度模式将度数字形附加到值（以及 360° 环绕的任何逻辑）

°

或者这个附属物将来会通过我对 TextBox 的后缀建议得到更好的处理 #784

@mdtauk ，可以使用

对于包装，实际上这就是 IsWrapEnabled 属性的用途......下次我需要阅读文档的末尾。

底线我认为我们可以用现有的 API 做你想做的一切。

@mdtauk ，可以使用

对于包装，实际上这就是 IsWrapEnabled 属性的用途......下次我需要阅读文档的末尾。

底线我认为我们可以用现有的 API 做你想做的一切。

我知道 Min、Max、Wrap 可以处理它，但是度数是否足够常见，可以为盒子提供明确的角度模式？ 并且它应该在TextBox Text中显示符号，而内部Value只是数字。

@teaP看看新的 Compact SpinButtonMode，是否可以向叠加的 Spin Buttons 添加显示和隐藏动画？

您是否也考虑过为此添加 Acrylic，以更好地匹配 ComboBox 和其他带有弹出元素的表单字段？

编辑：它将解决黑暗主题中的可见性问题。 是要匹配 TextBox 的焦点颜色还是匹配当前主题颜色？ 不管怎样，亚克力解决了这个问题。

@SavoySchuler ，你会为规范打开一个新的 PR 吗？ 另外，您是否注意到我在此评论中特别是围绕 NaN 显示所写的内容？ 谢谢。

@adrientetar是肯定的。 当 NumberBox 为空时， Value将设置为 NaN（如您所要求的）并且PlaceholderText将显示。

@SavoySchuler到目前为止对规范/

步进频率

在这里使用“频率”这个词并不适合我。 在 Slider 控件中，TickFrequency 是有意义的，因为刻度是根据整个 max-min 范围的模数计算和显示的。 然而，在这个控件中，它只是增量/步长。 它更像是“StepAmount”或“StepValue”——更好的是“Step”类似于“Minimum”而不是“MinimumValue”。

我已经与@MikeHillberg分享了这个反馈，我们现在正在讨论它。 为了在此处的所有其他属性中进行自我记录，我们正在考虑类似于“SpinButtonStep”的内容，如果这种推理足以证明有偏差的话。 我会告诉你。 感谢您提出问题！

此外，用户是否能够输入定义步骤之外的值？
例如最小值 = 0，最大值 = 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 和 TextWrapping Enum 的 TextBox/XAML 约定。 是不是因为你觉得‘Text’这个词不太适用于NumberBox？~

~另外，我理解也许 Wrap 和 WrapWithOverflow 的实现是相同的，但只是允许两个枚举值相等并在文档中描述功能。 在这里创建一个新属性只是意味着我们需要新的值转换器等等……我认为没有理由打破现有的约定。~

正确处理键盘加速器

请确保此控件比 TextBox 更支持使用键盘加速器。 也许这在/如果 TextBox 被修复之前无法完成，但 #1435 对我来说确实是一个问题，会导致很多丑陋的解决方法。 TextBox 将自行处理“Ctrl+V”粘贴，然后将引发任何 KeyboardAccelerator。 但是，在 KeyboardAccelerator 中无法知道 TextBox 只是做了它自己的事情。

NumberBox 包含一个 TextBox 并在顶部添加属性和配置。 我会标记@jevan，因为他可能有更全面的理解，但我的直觉是这可能需要在 TextBox 级别进行修复。

总而言之，很棒的反馈@robloo！ 我感谢您花时间帮助确保我们尽可能全面和完整地使用 V1 NumberBox！ 如果您还有其他问题，请告诉我。 😊

@mdtauk

一个快速的想法。 是否应该有一个角度模式将度数字形附加到值（以及 360° 环绕的任何逻辑）

°

或者这个附属物将来会通过我对 TextBox 的后缀建议得到更好的处理 #784

到目前为止，NumberBox 不支持任何非数字字符的显示（因为在计算表达式时甚至删除了公式字符）。

我认为您对#784 的提议是迄今为止我们平台最全面的提议。 如果该提案没有得到落实，我觉得它是一个合适的 V2 功能 NumberBox 作为后备。

我们已经计划在 WinUI 3.0 旁边或之后不久发布 V2，因为 NumberBox 的两个高度要求的输入验证模式在需要 WinUI 3.0 时被阻止。 所以我会在 V1 上线后打开一个 V2 问题，我会尽量确保在那里也注意到这一点。

为了在此处的所有其他属性中进行自我记录，我们正在考虑类似于“SpinButtonStep”的内容，如果这种推理足以证明偏离

我看到 StepFrequency 是 Slider 使用的，所以我认为我们试图与该术语保持一致。 不要忘记它不仅适用于旋转按钮，还适用于拖动和 UIAutomation 提供程序更改值。

@robloo和@mdtauk ，我应该在回复°之前进一步阅读线程。 我认为目前不支持在Text显示此符号，因为 NumberBox 保持Text和Value紧密同步，以便让您作为开发人员可以抓住您需要哪种类型而无需转换开销。 我没有看到通过可用的格式属性来实现这一点的方法，但是如果您知道一种方法，请告诉我！

我们现在正面临 V1 版本，但对于 V2，我们将再次查看前缀/后缀/特殊字符。 同时，我相信@mdtauk对#784 的提议是迄今为止为该平台提出的最全面的解决方案。 如果这是您需要的功能，请对该提案竖起大拇指并发表评论。

@adrientetar ，滚动更改已用于 V1，但拖动更改已延迟到 V2。 由于我们仍在寻求完成这些功能，因此我们尚未讨论您的要求，即 Shift+Up/Down 以 10 为单位步进，而 Ctrl+Shift+Up/Down 以 100 为单位步进。

你能给我更多关于你会在哪些场景中使用这个功能的背景信息吗？ 您的用户如何知道这是可用的？ 与在您的解决方案中本地实现相比，您能否帮助我理解为什么这应该是所有 NumberBoxes 中的默认值（或至少可用）？

@萨沃伊舒勒

非常感谢您的评论。

为了在此处的所有其他属性中进行自我记录，我们正在考虑类似于“SpinButtonStep”的内容，如果这种推理足以证明偏离

我非常喜欢这个术语，但我错过了 Slider 已经具有 StepFrequency 属性。 既然是这样，那么像@jevansaks所说的那样偏离惯例是没有意义的。

四舍五入是通过格式化处理的。 下面是可以为 DecimalFormatter 设置的舍入属性的示例。

假设用户在 NumberBox 中输入“1 / 3”。 那么下面的顺序是否正确：

• 在失去焦点/输入时，将计算表达式并计算双精度值 0.33333333...34
• 0.33333333...34 将传递给 DecimalFormatter
• 0.33333333...34，根据您的设置，可以四舍五入为“0.30”（只是有点困难）
• 然后将“0.30”值放入文本框以显示给用户
• 双Value现在是 {0.33333333...34} 而Text值现在是“0.30”
• 读取双Value不会返回Text显示的四舍五入数字
  （或者是十进制格式的值在转换为字符串后以某种方式再次解析？然后整个事情重新评估？）

我还担心 Value 和 Text 属性在内部是如此紧密地耦合在一起。 文档没有定义这种耦合，如果它不是高度结构化的双向依赖关系，就永远不会有趣。

我还不确定这是如何在内部实现的，但似乎正确的方法是将 double Value 视为唯一的不动产。 Text 只是 Value 的格式化版本。 然后开发人员将能够格式化该值，但他们希望它显示在 TextBox 和 Text 属性中（我们将获得先前要求的度数符号或英尺/英寸符号）。 如果一切都已经在内部由 Value 属性驱动，那么这根本就不难做到。 来自用户的文本输入无论如何都不会保留，只会用于重新计算值，然后再次格式化以进行显示。

顺序应该是：

• 用户文本输入 -> 解析器 -> 双值 -> 格式 -> 文本

从代码中更改 Text 值就像用户输入了一些文本一样。 直接更改值只会通过格式和文本步骤。

为了保持 Value 和 Text 序列之间的舍入准确，更像是：

• 用户文本输入 -> 解析器 -> 值 -> 舍入 -> 值 -> 格式 -> 文本

编辑：要在表达式/输入解析器和计算引擎（无论它叫什么）中实现舍入，您可能需要添加一个新属性来定义像RoundingAlgorithm这样的算法。 正如您所指出的，该枚举已在 Windows.Globalization.NumberFormatting 中定义。 INumberFormatter2 应该用于格式化而不是其他任何东西——再次保持计算和最终显示文本之间的阶段解耦。

@adrientetar ，滚动更改已用于 V1，但拖动更改已延迟到 V2。 由于我们仍在寻求完成这些功能，因此我们尚未讨论您的要求，即 Shift+Up/Down 以 10 为单位步进，而 Ctrl+Shift+Up/Down 以 100 为单位步进。

你能给我更多关于你会在哪些场景中使用这个功能的背景信息吗？ 您的用户如何知道这是可用的？ 与在您的解决方案中本地实现相比，您能否帮助我理解为什么这应该是所有 NumberBoxes 中的默认值（或至少可用）？

一个应该是一个更大的增量，另一个应该是更小——类似于在 Adob​​e 应用程序中轻推选定的区域/对象

你能给我更多关于你会在哪些场景中使用这个功能的背景信息吗？

当您想更改具有视觉含义的值（例如对象的旋转）但不确定要走多远时，这很好。 所以它有利于视觉设计。

您的用户如何知道这是可用的？

这只是现代工具所具有的功能，例如 Adob​​e XD、Framer...

与在您的解决方案中本地实现相比，您能否帮助我理解为什么这应该是所有 NumberBoxes 中的默认值（或至少可用）？

我认为当您在触摸设备上时使用它是很好的，这是一种方便的方式，点击拖动来调整给定的值（有点像您点击拖动滚动值的电话时间选择器小部件）。

一个应该是一个更大的增量，另一个应该是更小——类似于在 Adob​​e 应用程序中轻推选定的区域/对象

RangeBase 具有 SmallChange 和 LargeChange 属性。 我们 BeLight Software 的 NumericUpDown 版本是从 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

在社区电话会议期间我想到了关于键盘数字小键盘的一句话......

在大多数应用程序中，“.” 键盘按钮仍然映射到“。” 字符，当使用非英语语言（例如法语中的“,”）时，它与小数点分隔符不同。 所以当你按下“。” 在记事本中键入，它写了一个“。” 字符。

一些应用程序（Excel 是最著名的应用程序）更改此键行为以重新解释键盘上的任何按键“。” 作为十进制分隔符输入。 更符合键盘的“计算器”设计。

计算器应用程序还重写了“.”。 按 将其解释为小数分隔符。

因为数字框将被允许更多地作为“计算器”工作，所以控件是否允许使用“。” 键入小键盘作为小数点分隔符 ? 或者至少为开发人员提供一种添加此功能的方法，而不必与关键过滤器和事件作斗争？

也许一个属性可以允许启用（如果选择加入）或禁用（如果选择退出）该功能。 比如KeyPadDotAsDecimalSeparator="false" ？

V2 NumberBox 提案： https :

你好精彩的 WinUI 社区！ 真诚地感谢您帮助我们将我们的第一个社区建议控制释放回家。 我们知道这是一项艰巨的任务，你们所有人都投入了大量时间来制作我们可以共同设计的最佳 V1 功能集合。

我们也知道并非所有内容都包含在 V1 版本中。 一些非常需要的输入验证配置依赖于 WinUI 3.0 的功能工作，一些需要的功能需求在验证/应用程序后期才浮出水面，还有一些我们知道在 V1 发布后会更好地探索的功能。

我们希望在 WinUI 3 版本中完成我们预期的 NumberBox 功能工作。 我已经打开了一个问题，用于收集有关 V1 中缺少的所需功能的反馈。 如果 NumberBox 缺少您需要的东西，请务必在此处发表评论： https :