Currently, the control doesn't allow to paste numeric strings with leading and trailing white spaces. For example " 35 ".

To achieve this, you can subscribe the RadNumericUpDown control to the Pasting event and implement the pasting manually. 

DataObject.AddPastingHandler(this.numericUpDown, OnNumericUpDownPaste);

private void OnNumericUpDownPaste(object sender, DataObjectPastingEventArgs e)
{
	var copiedString = e.DataObject.GetData(typeof(string)) as string;
	if (copiedString != null)
	{
		copiedString = copiedString.Trim();
		double number = 0;
		var success = double.TryParse(copiedString, out number);
		if (success)
		{
			this.numericUpDown.SetCurrentValue(RadNumericUpDown.ValueProperty, number);
			e.CancelCommand();
		}
	}
}

As a workaround you can change the NumberNegativePattern to the default one like so:

System.Globalization.CultureInfo ci = (System.Globalization.CultureInfo)System.Threading.Thread.CurrentThread.CurrentCulture.Clone();

ci.NumberFormat.NumberNegativePattern = 1;

Thread.CurrentThread.CurrentCulture = ci;

Thread.CurrentThread.CurrentUICulture = ci;

Available in LIB 2016.3.919 and also it would be available in 2016 R3 SP1.

In a scenario when the current culture uses "." as a decimal separator make it possible to have "," as a parsing decimal separator and at the same time have the current culture separator displayed in the control and vice versa.

Make it possible to be notified when the Value has been changed by user interaction by using the Up/Down buttons

Currently we're parsing Key.Decimal the same way we're parsing Key.OemPeriod. 
Our clients want to always type the culture decimal separator when pressing the Numpad separator key (del). 

Currently if the client uses a French culture, which decimal separator is comma - pressing the Numpad separator key does nothing.

Workaround: Handling the RadNumericUpDown.PreviewKeyDown method:
private void RadNumericUpDown_PreviewKeyDown(object sender, KeyEventArgs e)
{
	 var num = sender as RadNumericUpDown;
	 if (e.Key == Key.Decimal || e.Key == Key.OemComma || e.Key == Key.OemPeriod)
	 {
		 var textBox = e.OriginalSource as System.Windows.Controls.TextBox;
		 if (!textBox.Text.Contains(num.NumberDecimalSeparator))
		 {
			 textBox.Text += num.NumberDecimalSeparator;
			 textBox.CaretIndex = textBox.Text.Length;
		 }

		e.Handled = true;
	 }
} 

I am in need of a two digit display format using the NumericUpDown control. As I have to display the integer value "0" as "00" in all cases. This is a big draw back as I have to be complient to other systems.

-Stefan

Hello,
it would be great if we can have more control about the formatting of the value in the up/down.
I have a scenario where I must use the control to edit a duration in minutes. When the duration is 1 hour or more, it should be displayed as 1:05, for example.
This scenario would be feasible if you had a FormatValue and a ParseValue virtual methods, so we can inherit from the base class and customize completely the display.
Patrick

Available in LIB version 2016.1.302, it will be also available in the 2016 Q2 Release.

Make the validation against Min/Max value optional as well as the replacing the typed value with the min/max if the typed value is outside of the allowed range.

Currently, the NumericUpDown supports the following two options:

1) The Min/Max possible values are set on the NumericUpDown. This has quite dangerous issue. If the user focus the control, write 4 and press Enter (or click on the OK button), the value is silently and without any warning changed to 100000 and committed.

2) No Min/Max is set on the NumericUpDown. Here, the up/down buttons does not help so much as in the first case. The first up key press sets the value to 1 which is invalid rather than to the first valid value (100000). Almost no-one would like to press 100000 times the Up button to reach the first valid value (I know there is a Page Up button as well but this requires somehow advanced user which know in advance about this feature and it might block other meaningful usage of the Page Up feature).

I would like to see a combination of the two. The NumericUpDown has the Min/Max set but it does not alter the value automatically if not valid.

Examples of the requested behavior:

Scenario 1. The value is null. User presses Up button. The value is set to 100000.

Scenario 2. User enters 4 which is forwarded to the underlying model. User commits the form. The Range(100000, 999999) results in a validation error on the DataForm and the commit is cancelled.

Scenario 3. User enters 4. User presses Up button. Here, there are two possibilities I do not have clear winner up to now. a) The first valid value is set (100000). Cons is that the user might expect change to 5 and does not notice that the value changed to 100000. b) The value is normally incremented to 5, i.e. to an invalid value.