Here are designs for the various states that conform to the specs.

Prefix, Suffix, Masked String - could all be ContentPresenters and have their own templates which define the padding foreground and background colours.

Image is at 200% scale

Team Spec Review # 3 Summary

Hi, everyone! Below, I am adding some short notes to give a progress update on the Open Questions section. The spec, proposal, and related unresolved conversations will be updated shortly.

• Enter: Should this break the tradition of single-line TextBox not eating the Enter key (form submission) to the broaden/purify the user's means of invoking calculation?

Yes. Enter will invoke evaluation, but in return "=" will be not be reserved.

• Escape: Should this key purge un-evaluated input and return the Text to the last stored value (Value)?

Not at this time. As @YuliKl noted earlier, Escape is reserved for canceling transient UI which is disjoint from the concept of "Undo" which is served by Ctrl-Z. That being said, this use of Escape could be configured at an application level may

• How should SpinButton styling be exposed?

Two separate style properties, one for increment and one for decrement.

• Should NumberBox request a configered DecimalFormatter/NumberRounder or expose aligned properties and configure these classes internally? Both?

Expose aligned and relevant DecimalFormatter/NumberRounder properties rather than request/accept pre-configured DecimalFormatter/NumberRounder at this time.

• Should the validation step resize the width of the control? Or should it wrap onto multiple lines?

Width, not at this time. Multi-line will be allowed and configurable by properties coming off TextBox.

• Is there value in creating a preview for calculation results? @mdtauk created a few example visualizations:

Still in discussion, likely a future feature or suggested community development.

• Can touch/virtual keyboards intelligently adapt to numeral-formulaic input?

Still in discussion.

@SavoySchuler Just responding to the relevant bits from here.

• Holding down on up and down (keyboard) keys should repeatedly alter the value. The same with maintaining mouse-down on the actual buttons.

I am hesitant on this one as the LinkedIn profile picture zoom slider (which implements this) delivers a painful accuracy experience. I find myself in a race to click as briefly as possible to avoid massively over-sending input. A small pause before embarking on a resend could resolve this but accessibility would still need some vetting. Do you think this behavior could compromise for a settable property? Do have any app scenarios on hand to help understand more fully?

I've just known lots of controls do this in the past and so expect it. However, if there are accessibility issues then that's a good reason not to do it.

Validation

• Doing validation after every key press seems the most flexible approach. Text Changing/Changed events need to fire while modifying the text value and it feels weird/wrong if the equivalent Value events don't also fire. (I determined Value based on attempting the resolve the sum if it wasn't a valid double value.)

I will conduct a re-evaluate our consensus on this tomorrow.

Based on how I read the spec at the moment, it appears the result of your re-evaluation was to not do this. ok.

• Entering a zero before a decimal place (for a value such as "0.4") shouldn't be necessary but it feels good when the zero is added when the entered value is resolved as it makes the fact it is a decimal value clearer. (This is something I think the control should do automatically.)

Added under Decimal Precision.

I see it there but thought it would be more related to the AreLeadingZerosTrimmed property but the spec now seems unclear on whether this will be included.

Calculations

• I found having the preview value displayed really useful.

I am eager to hear more. What was useful about it? Where in your apps might you use this feature?

As I experimented with my own implementation, practicing entering different values, I found that as I became more comfortable with using the calculator entry, I used that more and more but could become confused when the sum resulted in a value higher than MaxValue and so was clamped. Seeing the preview of the sum helped me understand why the actual/correct result of the sum wasn't displayed. Not the app use scenario you wanted but a personal anecdote based on usage.
I suspect this is a bit of a niche scenario that doesn't really warrant support in the initial release.

• Having a press of the equals key trigger the calculation of the sum feels natural. (I wanted to press the equals button just like on a "real" calculator.) Having this also advance focus seemed appropriate and natural.

I have added definitions for evaluation triggers as the first bullet point of Events and included "=".

It's not there now. Was it removed again?

• I'm used to large forms where users expect enter to advance focus on single line textboxes. This stops accidental entry/submission on incomplete forms. I built my sample like this but understand that's not always appropriate. If some functionality is built into the control that relates to the action of the Enter button it needs to not prevent the developer from allowing or disabling the way the enter button can influence focus advancement.

I have added a settable Boolean property called EnterTriggersEvaluation. This tentative pending approval of keyboard interactions, but please continue to let me know what you think as you explore the prototype.

The new property isn't there now so I guess it didn't make the grade. I'm happy with your decision as long as the final control doesn't prevent me from attaching behaviors that listen for the enter key and try and advance focus.

Having been away from what's happening (for <2 weeks) I'm finding it impossible to catch up. Here's what's making it hard:

• Discussion is spread to broadly. There are threads that are spread across the proposal, the PR, and inline comments on the PR file. Knowing what the latest thoughts, decisions, and questions are is too had to follow.
• There's a lack of detail on many things in the spec. I've noticed new properties have been added since I last looked but there's no explanation of what they do and I can't see any discussion about them. I've given up adding review comments along the lines of "the spec needs to document this" but it should.
• There seems a lack of a need to justify any suggestion regardless of where in the process we are. I'm fine with all ideas being welcome in the early stages but I'm not sure that when it comes to specifying what the control should do and how it should do it, that then is the best time to accept and start discussing new suggestions without good initial justification for why the new idea should be considered. I hope a precedent hasn't been set here and that future controls/features/whatever can spend more time clarifying what should be included while in the proposal stage so the spec can focus on how without be overwhelmed by side discussions or "what if"s.

There are lots of things in the spec I have questions about or feel need clarifying. I can't believe that the points I want to make haven't been brought up or discussed already though. However, there's only so much time I can spend looking through everything here and I've spent several hours on this already today.

Hopefully it won't be too long before you get to a point where the spec is "complete" or at least doesn't have a lot of ongoing discussion. Maybe then it will be realistic for me to look at it again.

If this comes across as an old man complaining then it probably is. On the other hand, I'm engaged, knowledgeable (I hope), and keen to see this be successful. If it's got to the stage that I'm put off from being involved then I expect it to have put off people who are more casually interested but might have something valuable to contribute. I know that the way that new controls and the project as a whole handled being open source is still a learning process for everybody so hopefully my points can help refine things for the future.

Thank you, @mrlacey, I took this to heart:

There are lots of things in the spec I have questions about or feel need clarifying. I can't believe that the points I want to make haven't been brought up or discussed already though. However, there's only so much time I can spend looking through everything here and I've spent several hours on this already today.

Hopefully it won't be too long before you get to a point where the spec is "complete" or at least doesn't have a lot of ongoing discussion. Maybe then it will be realistic for me to look at it again.

If this comes across as an old man complaining then it probably is. On the other hand, I'm engaged, knowledgeable (I hope), and keen to see this be successful. If it's got to the stage that I'm put off from being involved then I expect it to have put off people who are more casually interested but might have something valuable to contribute. I know that the way that new controls and the project as a whole handled being open source is still a learning process for everybody so hopefully my points can help refine things for the future.

This hasn't, to my knowledge, been a problem in the first 6 months of our open source experience as none of our technical feature developments have been this popular before. The volume of contributions on NumberBox are revealing faults in the system that I am committed to fixing so that myself and the WinUI team can keep the time you (and other valuable contributors like you) are willing to spend with us as meaningful as possible. I have some ideas in mind, but as to not pollute this thread further, I will take them to Twitter to see what we can solve together.

Back on NumberBox

Alright Team,

Apologies for the unexpected break. I am back on NumberBox full throttle and @teaP is joining me as our feature developer! We are still targeting the end of November for this control's preview, which will have us looking at a stable release with WinUI 2.4.

There's a lot of baggage in the old workflow, so I will be preserving any open or answered questions and porting them to a fresh spec PR where @teaP and I will finish resolving our remaining open topics regarding:

• localization
• design (particularly with regard to Up/Down buttons)
• hyperscroll/hyperdrag
• validation (with respect to Input Validation now being slated for WinUI 3.0 which means NumberBox may require 3.0 V2 for full input validation functionality)

I'm going to be winding back up on all of our former progress now, and I'll be posting questions and soliciting feedback as its relevant. Thanks for sticking with us. 😄

Closing for now - please preserve until a new pull request is live.