# Display only numerics in a text box

I have built a calculator and on the calculate event it verifies that the amount is numeric.  Is there an event that I can have in the change event though that will keep on numbers in the field?

I know there has to be an easy answer for this.
###### Who is Participating?

Commented:
PaulHews,

I prefer:

IF (INSTR("0123456789." & vbCR & vbBack, CHR(keyascii)) < 1) then  keyascii = 0

Simpler logic and easier to allow addition of special characters. Embedded Numeric constants (48 & 57) are a no-no.

:-)

M
0

Commented:
You can use the IsNumeric() call on the Changed event of the object in question.
0

Commented:
You can screen at the KeyPress event to keep user from entering non-numeric keys:

Private Sub Text1_KeyPress(KeyAscii As Integer)
If KeyAscii <> vbKeyBack And KeyAscii <> vbKeyReturn Then
If KeyAscii < 48 Or KeyAscii > 57 Then
KeyAscii = 0
End If
End If
End Sub

0

Commented:
Yeah, you're right, much more elegant, easier to read and easier to add to.  Use the like operator and its even faster:

Private Sub Text1_KeyPress(KeyAscii As Integer)
If Not (("0123456789." & vbCr & vbBack) Like "*" & Chr(KeyAscii) & "*") Then
KeyAscii = 0
End If

End Sub

And also

0

Commented:
Good tip, Mark2150.  You might want to add the negative sign:

If (InStr("-0123456789." & vbCr & vbBack, Chr(KeyAscii)) < 1) Then KeyAscii = 0

Of course, this will allow a negative sign in several positions.  However, both approaches allow several decimal points.
0

Commented:
PaulHews, I tried the LIKE section, but it didn't work.

If you use Chr\$() instead of Chr(), it's about 7% faster.
0

Commented:
How didn't it work, you mean it wasn't faster?  I just tested it here, and it works the way it is supposed to.  I haven't tested it for speed, but I remember reading in VBPJ that the Like operator performs the comparison much faster than Instr (not that speed is really much of an issue here.  Maybe if you had a large comparison string or pattern.)
0

Commented:
For keystroke validation I don't think it makes squat of difference.

As for multiple . and -'s, yes, but if you pull a VAL() operator on the text box contents you'll get as much legitimate number as there is. If some moron puts in three .'s everything to the right of the 2nd one will be discarded. This is such a low occurence event and since the VAL() operator will get at least *some* semblance of legitimate data I normally don't worry about it. The VAL() keeps the garbage out of the database or any subsequient calculations.

M
0

Commented:
I agree, speed in this type of thing is insignificant.  I was just throwing it in as something to use in the future (e.g., using Chr\$() instead of Chr() is usually faster).  The Like approach (see next paragraph) was 3% slower and the Chr\$ was 7% faster -- big deal.  Never be noticed with user input.  With high speed communications or processing, 10% differences would be noticed, but not in this situation.

Paul, I copied in your code verbatim and it did not screen the non-numeric entries -- the first time (last night).  I just did a copy-and-paste again, and it worked.  Chalk it up to operator error, I guess.

Mark, good point about Val().  I wouldn't worry about it either.  :)
0

Commented:
Thanx.

You can guess how I handle calls from users complaining "I put in 123.456.789 and the program only took 123.456"... (big, evil, grin)

M
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.