Add StringFormat dependency property to NumericUpDown and DecimalUpDown

[jamesport079]

Text in NumericUpDown should be able to be formatted to represent currency for example or to format the number of decimal places in DecimalUpDown.

Ideally a StringFormat gets added as a dependency property to these controls to be able to format the number accordingly.

[nicolaihenriksen]

@jamesport079 Although not exactly what you're requesting, there are attached properties available that allow you to set a prefix/suffix text... So you could do something like this:

<materialDesign:NumericUpDown Style="{StaticResource MaterialDesignFilledNumericUpDown}"
                              materialDesign:TextFieldAssist.PrefixText="$"
                              Value="100" />

Which would give you a control with a dollar sign prefixed before the actual value:

And if you want decimals as well, using the DecimalUpDown is the better option.

[jamesport079]

@jamesport079 Although not exactly what you're requesting, there are attached properties available that allow you to set a prefix/suffix text... So you could do something like this:

<materialDesign:NumericUpDown Style="{StaticResource MaterialDesignFilledNumericUpDown}"
                              materialDesign:TextFieldAssist.PrefixText="$"
                              Value="100" />

Which would give you a control with a dollar sign prefixed before the actual value:

And if you want decimals as well, using the DecimalUpDown is the better option.

Thank you! Didn't know about this. This partially solves my problem.

Having said that I still think that having direct access to StringFormat in the text displayed is the way to go. With DecimalUpDown there is no way to format the number of decimal places for example. Also, different countries represent money differently which is nicely handled by StringFormat in WPF.

[corvinsz]

Unless I'm missing something, there is 2 types of formatting:
1. Formatting decimal places of a floating point number:

Unformatted value	Formatted value to 2 decimal places
3.141592	3.14

2. Formatting a numeric value by concatting with a string

Unformatted value	Formatted value appended with a unit
420	420 Euro

(This could of cause be any string, not just "Euro")

For the "first type of formatting" I don't see a problem.

The "second type of formatting" I tested with a normal WPF TextBox and it feels kind of weird. When only editing the numeric value, an error is displayed saying it can't be converted.

This, default WPF behavior, is already not a great UX. Again, please correct me if I am missing something.
It would probably be more reasonable to implement a StringFormat if the internal TextBox of the NumericUpDown / DecimalUpDown could be made readonly via a DP, so that the user can only adjust the value via the up/down-buttons, resulting in the format being untouched.

[jamesport079]

Unless I'm missing something, there is 2 types of formatting: 1. Formatting decimal places of a floating point number:

Unformatted value Formatted value to 2 decimal places
3.141592 3.14
2. Formatting a numeric value by concatting with a string

Unformatted value Formatted value appended with a unit
420 420 Euro
(This could of cause be any string, not just "Euro")

For the "first type of formatting" I don't see a problem.

The "second type of formatting" I tested with a normal WPF TextBox and it feels kind of weird. When only editing the numeric value, an error is displayed saying it can't be converted.

This, default WPF behavior, is already not a great UX. Again, please correct me if I am missing something. It would probably be more reasonable to implement a StringFormat if the internal TextBox of the NumericUpDown / DecimalUpDown could be made readonly via a DP, so that the user can only adjust the value via the up/down-buttons, resulting in the format being untouched.

No, you're missing a lot. First of all that is not the proper way how to represent currency in Euro. Second of all, the way Euro currency is represented varies from country to country within the same European Union. So in Italy it would be 40 Euros will be represented as "40,00 €" but in Ireland it will be "€ 40.00" ..... See the difference? Italy has the Euro sign after and uses comma and Ireland uses fullstop with the euro sign before. There are a lot of other nuisances when representing currency that I don't want to waste time to handle them myself when WPF and Windows itself does a nice job with StringFormat.

You can read more about the how Euro is written in different countries in this article.... https://en.wikipedia.org/wiki/Language_and_the_euro

[corvinsz]

This is harder to implement than I expected it to be.
I was taking a look at how MahApps was implementing their StringFormat for the NumericUpDown control.

A few things I have noticed:

1. It's an enormous amount of code to get the StringFormat to work. In MahApps specifically, they extract numbers from the control using Regex patterns. My semi-working "solution" is partially based on how they did it.
2. From what I have seen, even with the Regex patterns etc. in place, not all Standard numeric format strings and custom formats (e.g. StringFormat={}{0}°C) are supported.
3. Additionally, if I set the culture to CultureInfo.CurrentUICulture = new CultureInfo("en-EN") and the StringFormat to StringFormat='C' it just displays the generic currency sign:

(Though this could be due to my implementation)

4. The default WPF TextBox (and most likely other controls too) aren't fully supporting culture based formatting.
   Both my CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture are set to de-DE and with the standard numeric currency format ("C" or "c") it displays the value in dollars, which is wrong (it should be Euro €):

<TextBox Style="{x:Null}" Text="{Binding MyDecimal, StringFormat='{}{0:c}'}" />

(Note: this issue can be fixed as described here, but I think this is besides the point and not viable for this issue.)

This is the branch I was testing/working with, but at this point I think it's easier to start fresh:
https://github.com/corvinsz/MaterialDesignInXamlToolkit/tree/fix3758_3