Add InputScope Property To NumberBox

[robloo]

Add InputScope Property To NumberBox

Adds the following API to NumberBox

DependencyProperty InputScopeProperty { get; }
InputScope InputScope { get; set; }

Motivation and Context

Closes #2710 , relates to #3158

Also relates to the previous discussions in #1912 and PR #2605 where the InputScope was fixed to Number.

How Has This Been Tested?

1. The property has been added to the MUXControlsTestApp in the NumberBoxPage and manually tested
2. A VerifyInputScopePropogates() API test was added and passes

Screenshots (if appropriate):

[ghost]

All CLA requirements met.

[robloo]

I have no idea how to set a default value for an InputScope type in the IDL to 'Number' since InputScope is a class that only has a parameterless constructor and requires the Names property to be set see how 'To change the input scope in code'. This may not be supported? It looks like TextBox itself defaults to null.

If someone confirms this isn't possible I guess the work-around is to set the value in OnApplyTemplate().

[Felix-Dev]

@robloo You could set the default value in the NumberBox constructor. If you set it in OnApplyTemplate() you could end up overwriting the custom value supplied by a developer (without further checks, for example). Furthermore, if you set in in the NumberBox constructor, it acts as the de-facto default value as NumberBox.InputScope will be set even if the NumberBox has only be constructed as a standalone object and not yet added to the visual tree (so no Loaded event raised or OnApplyTemplate() called). It will also make sure custom values set by developers will take precedence over the default value which is what we want.

(NumberBox, for example, also sets its NumberFormatter in the constructor. We would do the following for the InputScope API.)

[robloo]

@Felix-Dev Yes, not sure why I was thinking to put it in the OnApplyTemplate() now -- if I would have thought it through it will be fine in the constructor even before the TextBox is materialized.

I'll go ahead and set the default in the constructor if you also can't think of how to do this in the IDL.

[Felix-Dev]

I'll go ahead and set the default in the constructor if you also can't think of how to do this in the IDL.

@robloo Yeah, right now I don't know how to do it it purely in the IDL either so I would just go with the constructor approach here.

[StephenLPeters]

I'll go ahead and set the default in the constructor if you also can't think of how to do this in the IDL.

@robloo Yeah, right now I don't know how to do it it purely in the IDL either so I would just go with the constructor approach here.

The other option, which I think I like better, would be to leave the property null and put a setter in the default style which sets it to number. That way a controls library could change the default for their customers with an updated style.

[StephenLPeters]

Names [](start = 15, length = 5)

I'm not that familiar with inputScope, does this mean that you can apply multiple input scopes? like you can have number and currency at the same time.

[robloo]

does this mean that you can apply multiple input scopes?
Yes, you can apply multiple name values to the same input scope.

It's certainly an interesting design decision, one which I've never understood myself. However, my assumption has always been it's for the cases where the user can switch the keyboard. It simply limits what keyboards you are allowed to switch between. You might have to reach out to the Windows team to understand the thinking here though. I don't recall ever seeing documented reasons why this is a collection.

[StephenLPeters]

@MikeHillberg do you happen to know?

[robloo]

I'll go ahead and set the default in the constructor if you also can't think of how to do this in the IDL.

@robloo Yeah, right now I don't know how to do it it purely in the IDL either so I would just go with the constructor approach here.

The other option, which I think I like better, would be to leave the property null and put a setter in the default style which sets it to number. That way a controls library could change the default for their customers with an updated style.

Good idea, that is a cleaner approach.

[robloo]

@StephenLPeters

    <Style TargetType="local:NumberBox">
        <Setter Property="InputScope" Value="Number" />

I'm getting a XAML compile error "The TypeConverter for "InputScope" does not support converting from a string". This works fine in C# but looks like another one of those random missing features for C++ developers.

Edit: Actually I can't explain why this doesn't work considering setting the InputBox TextBox's InputScope to Number works just fine.

[StephenLPeters]

Edit: Actually I can't explain why this doesn't work considering setting the InputBox TextBox's InputScope to Number works just fine.

hmm and the property types are the same right? @fabiant3 is there something we need to to in the IDL to get the type conversion to work?

[StephenLPeters]

we prefer using auto and const for the local variable types.

[robloo]

Not a problem, should I pursue this now though or wait for potential work-arounds setting in the default style?

[robloo]

I just did it now so hopefully we can close this. There is no response on work-arounds for the XAML bugs.

[StephenLPeters]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[fabiant3]

@StephenLPeters

    <Style TargetType="local:NumberBox">
        <Setter Property="InputScope" Value="Number" />

I'm getting a XAML compile error "The TypeConverter for "InputScope" does not support converting from a string". This works fine in C# but looks like another one of those random missing features for C++ developers.

Edit: Actually I can't explain why this doesn't work considering setting the InputBox TextBox's InputScope to Number works just fine.

If direct conversion does not work, you can provide a custom conversion function essentially using x:Bind syntax. @RealTommyKlein

[StephenLPeters]

@fabiant3 This is a change to a templated control, x:Bind isn't supported in templates. I think we probably could using binding with a converter, however I'm not sure we should publish a new converter to work around this, given that setting the default from the constructor seems to work alright?

[Felix-Dev]

@StephenLPeters Can you check and see what the TextBox implementation is doing as you can set TextBox.InputScope in XAML for it just fine?

[RealTommyKlein]

I wasn't able to repro the error you're seeing with an InputScope property/type in a Setter, even for a custom class with its own custom InputScope DP to mimic this NumberBox setup. Can you share the exact error message/code you're getting?

[StephenLPeters]

Thanks for looking into this tommy, I confirmed that in my test app, if I add a second copy of my templated control to my page I get the same error the MUX controls test app is getting. @MikeHillberg or @Austin-Lamb do you know why input scope is behaving weirdly here? @robloo I think we should go back to setting the default value in the constructor.

[robloo]

Should this be considered a bug to be closed with WinUI 3? I can't imagine this behavior is an optimization.

[StephenLPeters]

I think so, but I'm hoping other team members might have a better idea what is going on.

[robloo]

@StephenLPeters I reverted the last commit, should be ready

[StephenLPeters]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[StephenLPeters]