Building database data entry applications raises many questions. The one I want to discuss here is, "When should one validate user input?" Catching invalid data entry at the earliest possible point - while the user is typing - can have great advantages. Validating after entry such as during the
LostFocus() event works, but you are faced with difficult choices. 1) Send the focus back if data is invalid, possibly causing the user to get "stuck" in a control or 2) Allow the focus to move with invalid data and the user must return to the invalid control to correct the problem.
With the purpose of stopping invalid data entry before it happens, let's take a look at the
I wanted to be able to easily handle a variety of different .NET basic numeric data types such as various size floating point and integer types as well as Currency (internally treated as
Decimal). Adding an
IsDigit() check in the
KeyPress event could handle much of the work, but there would be a few things missing.
First, digit-only filtering doesn't allow the decimal point or the negation "-" character. With a few changes we can allow negative numbers and a the decimal point, but the code rapidly becomes messy dealing with duplicate decimals and negative characters only in the first position.
Second, and possibly more important, is the numeric value entered. If we are working with .NET 32 bit integer values for example, then we need to stop further entry once the maximum value of an integer is typed. Otherwise we will be dealing with overflow errors.
For this reason, I chose to use the
Type.Parse() method to test for valid typing. If the
Parse() method throws an exception, then we know the
KeyPress character is not valid and it should be canceled. This technique stops overflow errors when converting our
TextBox string into numeric values. It also stops duplicate decimals as well as duplicate negation ("-") characters.
Last is pasting. Using
IsDigit() in the
KeyPress event will stop Ctrl+V paste keys but your users may like using Ctrl+V paste. How would you feel if Ctrl+V paste was removed from VS.NET? Adding handling for Ctrl+V paste will make our control a finished, production ready component.
Using the Control
The beauty of this control is that you never need to think about numeric data entry again. Simply add the control, set the
InputType property and you're ready to go.
IsValid() method is the heart of the
NumEdit control. There are a few preliminary checks at the beginning of the method that handle the initial negation ("-") character, any leading "0" characters, and empty strings. The remainder of the method simply attempts to parse the string into the selected data type and returns false if any exceptions are thrown. If the
IsValid() method returns
KeyPress event removes the current keystroke.
private bool IsValid(string val)
bool ret = true;
decimal dec = decimal.Parse(val);
int pos = val.IndexOf(".");
if(pos != -1) ret = val.Substring(pos).Length <= 3;
float flt = float.Parse(val);
double dbl = double.Parse(val);
decimal dec2 = decimal.Parse(val);
short s = short.Parse(val);
int i = int.Parse(val);
long l = long.Parse(val);
throw new ApplicationException();
ret = false;
Points of Interest
After adding the Ctrl+V pasting code I discovered a default
ContextMenu for the base class
TextBox that includes a Paste command. This command bypassed all my carefully crafted code and allowed non-numeric values into the
NumEdit control. I was unable to find a way to intercept this Paste command. My solution was to simply replace the
ContextMenu with an empty menu, thereby removing the
ContextMenu. If anyone has any ideas about overriding this
ContextMenu, I would appreciate hearing from you.
After completing the
NumEdit control, I thought of a few possible enhancements.
- Min/Max property. This would allow restricting the minimum/maximum values inside the data type min/max values.
- Positive-/Negative-only property. This could be handled with the Min/Max property so it is redundant but may be easier to use.
- Scientific or Engineering notation such as 12.345E10 could be useful.
Rev 1 4/4/2003
- Fixed 0 value not allowed.
- Added OnLeave handler to avoid "-", "-0", or "000" entries
- Added handling for Shift+Insert pasting
- Added Min/Max Property IMPORTANT NOTE: This feature has been commented out in the Source Code. VS.NET crashes with no error messages when you attempt to open the visual designer for any form containing NumEdit controls with the Min/Max Property enabled. I have not determined the exact cause, but it appears to be related to the
double datatype used by the Min/Max properties. Initial searches indicate a possible bug related to the
double.MinValue, double.MaxValue static value handling. NOTE: Using Min/Max values could also be problematic. Take for example a Max value of 100. User enters 20, and the NumEdit control disallows any further entry since any additional digit would exceed 100. This behavior is likely to be confusing to the end user.