This project has moved and is read-only. For the latest updates, please go here.

Alphabetic characters in DecimalUpDown

Nov 11, 2011 at 7:25 AM
Edited Nov 11, 2011 at 7:26 AM

Hi

Is it possible to prevent entry of alphabetic characters in DecimalUpDown, IntegerUpDown, DoubleUpDown controls?

 


Nov 11, 2011 at 2:22 PM

No, you cannot prevent the entry of alphabetic characters.  This is because of the support for custom format strings that may include characters other than numeric.

Nov 12, 2011 at 3:21 PM

Thank you. But do you think it's logical? If I understand correctly "format strings" only controls output (display) data. And I think the opportunity to enter  alphabetic characters is potential error. Isn't it?

For good example we can look at analog controls developed by DevExpress (http://www.devexpress.com/Products/NET/Controls/WPF/) and Telerik (http://www.telerik.com/).

But thanks for work.

Nov 13, 2011 at 12:17 AM

Those controls use a masking feature which is different than a format string.  Format strings do format the output, but when it is in an editable control those characters that are part of the format must be taken in to account while editing the value.  If an invalid value is entered it simply reverts back to the last valid value.  If I had the resources and money that DevExpress and Telerik have then maybe it would behave differently.

Nov 14, 2011 at 5:15 AM

Thank you for answers.

Nov 17, 2011 at 5:46 AM

Hi

I decide to improve your NumericUpDown class. And now it have current features:

1) prevent entry of alphabetic characters;

2) prevent entry of alphabetic characters via i/o buffer;

3) Up/Down button spin function changes current value (befor LostFocus ot EnterPress event);

4) Prevent entry of "-", "+" and decimal separator in any places. NumericUpDown controls this input like in SpinEdit (DevExpress control).

 

I think add next features later:

5) Prevent entering value with greater precision then preset value. (Now user can input "3.121545", but really displaying only "3.12" if formatString is set to "C2". And user can never know real value in database).

 

Can I make commit this version of IntegerUpDown, DecimalUpDown, DoubleUpDown for other users on codeplex? Or just public my source code here?

 

 

Nov 17, 2011 at 2:25 PM

Great job.  You can create a ZIP file and provide a link so I can download it.  I will review your changes and if everything looks good I will merge them into the source.

Nov 18, 2011 at 6:25 AM
Edited Nov 18, 2011 at 6:27 AM

Ok. This is link to source

I commented your code that replaced by mine.

May be we can create other branch of NumericUpDown controls if you can't merge this change?

Dec 8, 2011 at 6:45 PM

Peter,
Thanks for the link to your source... that does exactly what we wanted.  Quick question though... it looks like you changed the "IsReadOnly" to "IsEditable"... Can you explain why you did that?  Just curious.

Thank you

Dec 8, 2011 at 10:32 PM

It is planned to make changes the behavior of IntegerUpDown? This is a significant improvement.

P.S. "Tab" key not work, but it is easy to fix.

Dec 8, 2011 at 11:06 PM

The particular patch doesn't line up with the quality control spec, but I am thinking of adding a property called RestrictNumericInput that when set to true would restrict all user input to numeric characters.

Dec 8, 2011 at 11:09 PM
brianlagunas wrote:

The particular patch doesn't line up with the quality control spec, but I am thinking of adding a property called RestrictNumericInput that when set to true would restrict all user input to numeric characters.


I think that would be great.  Any idea on a timeframe :)

Also, the toolkit is awesome.... thanks for the work.  We just discovered it yesterday.

Dec 8, 2011 at 11:11 PM

No timeframe.  I am not spending much time on it lately because of work and holidays.  Thanks, I am glad that you enjoy the toolkit.  You can thank me by rating the project with your impressions.  Also, don't forget to help spread the word :0)

Dec 12, 2011 at 12:32 PM

HI All,

Do you have the updated assembly with above changes done in the Updowncontrol Base?. If So please update the Link. It will be very helpful for me to fix the above issues. I too looking for the above solution.

Thanks and Regards,

Sakthi

Dec 12, 2011 at 4:06 PM

no not yet.

Dec 13, 2011 at 9:52 AM

Hi Brian,

When will be the dll's available ? Can you please tell me the appropriate time ?

Thanks and Regards,

Sakthi

Dec 13, 2011 at 2:59 PM

whenever I get time.

Dec 13, 2011 at 6:20 PM
Edited Dec 13, 2011 at 6:27 PM

dalexs wrote: It is planned to make changes the behavior of IntegerUpDown? This is a significant improvement.
P.S. "Tab" key not work, but it is easy to fix.

Hi to all

1) I fixed this bug (see attached file bellow).

2) reagan123, properties "IsEnabled" and "IsEditable" is work like in commercial RadNumericUpDown (by Telerik).

3) I add  IsAlphabInputOnly property. It's set to false by default. And if you set this value to TRUE user can input only alphabetic characters.

P.S.: But since my "patch doesn't line up with the quality control spec" I deploy my own version of WPFToolkit.Extended.dll
In order to avoid conflicts with the original version of WPFToolkit.Extended.dll I add next information to assembly:

Description: Barbanyaga
Version: 1.5.0.1

Link to my WPFToolkit.Extended.dll

Dec 13, 2011 at 10:13 PM
Edited Dec 13, 2011 at 10:14 PM

1. (IsReadOnly VS IsEditable) is religion. In “Extended WPF Toolkit” usage IsReadOnly, IsEditable break old code.

2. Faced with an interesting thing: when application usage Custom Culture (not equal any standart) this leads to a problem with delimiter.

In code: string decimalSeparator = (this as Control).Language.GetEquivalentCulture().NumberFormat.CurrencyDecimalSeparator;

But, InputBase contain CultureInfo property therefore: string decimalSeparator = base.CultureInfo.NumberFormat.CurrencyDecimalSeparator;

In any case we expected official version "Extended WPF Toolkit" with RestrictNumericInput property.

Dec 14, 2011 at 5:40 AM
dalexs wrote:

1. (IsReadOnly VS IsEditable) is religion. In “Extended WPF Toolkit” usage IsReadOnly, IsEditable break old code.

2. Faced with an interesting thing: when application usage Custom Culture (not equal any standart) this leads to a problem with delimiter.

In code: string decimalSeparator = (this as Control).Language.GetEquivalentCulture().NumberFormat.CurrencyDecimalSeparator;

But, InputBase contain CultureInfo property therefore: string decimalSeparator = base.CultureInfo.NumberFormat.CurrencyDecimalSeparator;

In any case we expected official version "Extended WPF Toolkit" with RestrictNumericInput property.

Fixed.

Link

Mar 21, 2012 at 2:33 PM

Your improvements are really useful, however the IntegerUpDown still allows entry of a decimal point.

I added this to IntegerUpDown to fix the problem:  (note I changed the name of IsAlphabInputOnly and reversed the meaning to NumericInputOnly which also defaults to true).

	protected override void OnPreviewKeyDown(KeyEventArgs e)
	{
		if (this.NumericInputOnly)
		{
			switch (e.Key)
			{
				case Key.Decimal:
				case Key.OemComma:
				case Key.OemPeriod:
				case Key.Oem2:
					e.Handled = true;
					break;
				default:
					base.OnPreviewKeyDown(e);
					break;
			}
		}
		else
		{
			base.OnPreviewKeyDown(e);
		}
	}

 

Mar 22, 2012 at 10:18 AM

Maybe I'm misunderstanding the issue here but isn't preventing alphabetic input as "easy" as using a PreviewTextInput handler like below on the DecimalUpDown? (for IntegerUpDown just int.tryParse e.Text)

 

private void DecimalUpDown_PreviewTextInput(object sender, TextCompositionEventArgs e) {
	var dud = (sender as Microsoft.Windows.Controls.DecimalUpDown);
	var decsep = CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator;

	// allow entry of exactly one decimal sepparator
	if (e.Text == decsep && !dud.Text.Contains(decsep)){
		e.Handled = true;
		return;
	}

	// deny antry of non digits and not sepparator
	int tmp;
	if (e.Text != decsep && !int.TryParse(e.Text, out tmp))
		e.Handled = true;
}

This works for me to make the DecimalUpDown only accept (positive) decimal numbers and exactly one or zero decimal separator. (Note: It allows only entering e.g. "," which isn't a valid decimal but for a starter this wfm - alas I can't find any way to tryParse the input "that would be", e.g a DecimalUpDown with the text "15" and placing the cursor between the digits and pressing "," gives e.Text="," but there's no way to see that the new value would be "1,5" - but this is a separate issue, probably me doing something wrong (I'm still learning WPF/C#) - ordinary TextBox controls behaves the same way)