This project has moved. For the latest updates, please go here.

IntegerUpDown functionality

Nov 9, 2012 at 10:12 PM

With 1.7, I submitted issue 18801 (IntegerUpDown: Text property and actual text gets unsynchronized).  Using my solution, the control seemed to work just like IntegerUpDown's found in standard Windows dialogs.  That is, the only time the control could possibly have an invalid value is if it was empty, and the value updated as the user was typing.

With 1.8, the control only updates the value on lost focus.  The control allows the user to type in whatever they want.  I don't think the developer should have to figure out when the user typed in an invalid character.  As I was typing this, I found that the control throws an exception when using the mouse to scroll if the value is null.  I think that last point really shows that this is a step in the wrong direction.

I appreciate the work you're doing, but I'm going to have to stick with my slightly modified 1.7 version for now.

Nov 13, 2012 at 3:44 PM
Edited Nov 13, 2012 at 4:35 PM

Thanks for your feedback.

The Following Issue has been created based on your last post:

http://wpftoolkit.codeplex.com/workitem/18910

 

The problem with the NumericUpDown (base for all numeric "UpDown" control), is that we must consider all possible scenarios for all possible "cultures". The case of the IntegerUpDown seems simple but we modified the NumericUpDown considering the worst case which is the DoubleUpDown.

In some cultures, they may use a "," to separate decimals, others a "." . Some may use a separator for the thousand (eg. "1,200.34"), and to some point the input may be invalid but "on the way" to be a valid one. like "1,", "1,2", "1,200." or even "1,.34". The issue of a thousand separator even apply to an IntegerUpDown. We also need to consider some scenarios where text is "pasted" into the editor.

Not helping us here, the NumericUpDown was initially implemented with a "FormatString" property that allow the user to format the output in endless ways. But having something else than some of the very standard format strings would have crashed/bug the NumericUpDown anyway in the previous versions.

We implemented the actual behavior based on the only standard "validated text box control" in the WPF library which is the DatePicker. This control actually allow any input and update the value on lost focus, or revert back to the previous value if the input is not correctly formatted.

But you are not the only one that seems to need a "value as you type" feature. I am in reflection on how we could implement such a behavior. For sure one or more new properties will let you choose the desired behavior.  In order to accommodate those who already use the "FormatString" property, I expect to have some "display vs input" scheme where the format string would be used to display the value, but it would automatically be converted to a more "parsable" version once the element get the focus.

Since we don't want to get into the overwhelming and bug-prone job of creating our own parsing system, you can see here the API provided by the framework to parse an integer. It accept a "NumberStyles" value as parameter:

http://msdn.microsoft.com/en-us/library/zf50za27.aspx

But the "ToString()" implementation accept a "format string":

http://msdn.microsoft.com/en-us/library/d830955a.aspx

I didn't get deep into it yet, but we need to understand how to make work the "NumberStyles" parsing parameter work properly with some specific "Format string"...

Nov 13, 2012 at 10:22 PM

According to your documentation, the DoubleUpDown and IntegerUpDown controls only support the following FormatStrings: C, F, G, N, P.  I recommend that you enforce this limitation, which would allow you to easily figure out which NumberStyles to apply.  It's not possible to use the framework's TryParse method together with any possible FormatString.  I think if you still want to expose this functionality, then you should make the developer provide the code to parse the text.

Nov 21, 2012 at 3:09 PM

Will be fixed in v1.9.

The behavior will be the following:

On each user input (text change), we try to parse the input string to a valid number.

If it succeed, the Value property will be updated. If it failed, the actual state of Value will not be affected. This is much like the behavior of version 1.7

On LostFocus, if the actual text input is invalid, InputValidationError event is raised. Also, In all cases (valid/invalid), the content of "Value" is formatted according to "FormatString" and set as Text. So if the actual text input was invalid, it will be reverted to the display of the previous value.

Mar 14, 2013 at 4:37 PM
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:
  1. Initial state
    Text="" Value=null (invalid value - red)
  2. User types 1
    Text="1" Value=1 (parsed Successfully - green)
  3. User types 1
    Test="10" Value=10 (parsed Successfully, Coerced down - green)
released v1.9 code:
  1. Initial state
    Text="" Value=null (invalid value - red)
  2. User types 1
    Text="1" Value=1 (parsed successfully - green)
  3. 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.
Mar 15, 2013 at 4:46 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.