From [this discussion](http://wpftoolkit.codeplex.com/discussions/402630)
Maybe also revert to the original value when the the element first got the focus? or fall on the DefaultValue ?
-=-=-=-=
I looked at v1.9 today. It's still not quite there for me. I want to be able to continuously know whether the user has put in a valid integer. For example, let's say I want to show a red X next to the control when the input is invalid and a green checkmark when it's valid. With my modified v1.7 code, I can do this by showing the red X when the Value property is null, and the green checkmark otherwise. In v1.9, I would have to parse the Text property myself to be able to tell whether to show the red X or the green checkmark.
I'll give a concrete example. Consider an IntegerUpDown initially empty, with the maximum set to 10. Show red if value is null, otherwise green.
My modified v1.7 code:
0. Initial state
Text="" Value=null (invalid value - red)
1. User types 1
Text="1" Value=1 (parsed Successfully - green)
2. User types 1
Test="10" Value=10 (parsed Successfully, Coerced down - green)
released v1.9 code:
0. Initial state
Text="" Value=null (invalid value - red)
1. User types 1
Text="1" Value=1 (parsed successfully - green)
2. User types 1
Text="11" Value=1 (out of range - should be red but will still show green)
As you can see in http://wpftoolkit.codeplex.com/discussions/434918, there is a desire for an IntegerUpDown control that never allows invalid characters. For DoubleUpDown, it makes sense to model the behavior from the DatePicker control because you can't validate the input until the user types the whole string. But for IntegerUpDown, there are no problems when you parse as you go. Maybe you can create a standalone StrictIntegerUpDown that models its behavior from the WinForms NumericUpDown and doesn't have any of the backwards compatibility problems of deriving from your NumericUpDown.
Maybe also revert to the original value when the the element first got the focus? or fall on the DefaultValue ?
-=-=-=-=
I looked at v1.9 today. It's still not quite there for me. I want to be able to continuously know whether the user has put in a valid integer. For example, let's say I want to show a red X next to the control when the input is invalid and a green checkmark when it's valid. With my modified v1.7 code, I can do this by showing the red X when the Value property is null, and the green checkmark otherwise. In v1.9, I would have to parse the Text property myself to be able to tell whether to show the red X or the green checkmark.
I'll give a concrete example. Consider an IntegerUpDown initially empty, with the maximum set to 10. Show red if value is null, otherwise green.
My modified v1.7 code:
0. Initial state
Text="" Value=null (invalid value - red)
1. User types 1
Text="1" Value=1 (parsed Successfully - green)
2. User types 1
Test="10" Value=10 (parsed Successfully, Coerced down - green)
released v1.9 code:
0. Initial state
Text="" Value=null (invalid value - red)
1. User types 1
Text="1" Value=1 (parsed successfully - green)
2. User types 1
Text="11" Value=1 (out of range - should be red but will still show green)
As you can see in http://wpftoolkit.codeplex.com/discussions/434918, there is a desire for an IntegerUpDown control that never allows invalid characters. For DoubleUpDown, it makes sense to model the behavior from the DatePicker control because you can't validate the input until the user types the whole string. But for IntegerUpDown, there are no problems when you parse as you go. Maybe you can create a standalone StrictIntegerUpDown that models its behavior from the WinForms NumericUpDown and doesn't have any of the backwards compatibility problems of deriving from your NumericUpDown.