How Can I Prevent Users From Typing Anything But Numbers Into an HTA Text Box?
Hey, Scripting Guy! We have an HTA we use for data input. In one of the text boxes our users are only supposed to type numbers. How can I prevent users from typing anything except numbers in that text box?
— KV
Hey, KV. You know that’s a pretty good question: is there a way to prevent users from typing anything except numbers into a text box? And the answer to your question is this: yes, yes there is a way to prevent users from typing anything except numbers into a text box. Thanks for the question, KV; we’ll see everyone tomorrow!
Hold on a second here; the Scripting Editor seems to have a problem with today’s column. (God forbid we dangled a participle or something!) What’s that? No, no, if KV wanted to know how to prevent users from typing anything except numbers into a text box then she would have asked how to do that.
Oh, she did not; go back and read the question again and see for yourself.
Oh. Well, she must have added that later, because we’re pretty sure that wasn’t in her original question.
At any rate, we’re back. As we were about to say (before we were so rudely interrupted), KV wants to know how to prevent users from typing anything except numbers into a text box. (Obviously.) How can she do that? To tell you the truth, we have no idea; heck, if we knew how to do things like that we’d have real jobs.
|
Note. In case you’ve been thinking, “I bet Microsoft only allows the best and the brightest of their employees to write the Hey, Scripting Guy! column,” well, let’s just say that you might want to think again. |
The truth is, KV, we don’t know how to prevent users from typing anything except numbers into a text box. But let’s try a few things and see what happens. Nope … Nope … Close, but not quite … Ouch! that hurt … No … Ah, there we go: we did it!
Oops. False alarm; apparently W isn’t a number. Back to the old drawing board ….
Hold the phone, KV; we just might have something for you after all:
<SCRIPT Language =”VBScript”>
Sub KeyCheck
If Window.Event.KeyCode < 48 OR Window.Event.KeyCode > 57 Then
Window.Event.returnValue = False
End If
End Sub
</SCRIPT>
<BODY>
<INPUT TYPE=text onKeyPress=”KeyCheck”>
</BODY>
It took a little poking around through the HTML and DHTML Reference on MSDN, but this looks like this will do the trick. As you can see, we have a very simple little HTA here consisting of a single text box and a single subroutine. (What’s that? You don’t know what HTAs even are? Then you should take a look at our HTA Developers Zone.) Let’s start off by eyeballing the code that creates the text box:
<INPUT TYPE=text onKeyPress=”KeyCheck”>
Nothing too fancy there: we simply use the INPUT tag to create the text box, adding the TYPE=text parameter to ensure that we get a text box. (If you’re new to HTML, the INPUT tag can also be used to add controls like buttons, checkboxes, and radio buttons to an HTA.) We then tack this parameter on to the end of the INPUT tag:
onKeyPress=”KeyCheck”
What does this do? Well, any time a user presses a key while working in an HTA (or on a Web page, for that matter), the onKeyPress event is fired. This parameter simply says, “OK, HTA; here’s the deal. If the onKeyPress event gets fired and if the focus happens to be in our text box, then run the subroutine named KeyCheck.” In other words, if you’re typing something in the text box, each time you press a key the HTA will call the KeyCheck subroutine.
So then what does the KeyCheck subroutine do? Well, as you probably know, each key on the keyboard has a value assigned to it. (You can also find a list of keys – and their corresponding values – on MSDN.) The first thing we do in this subroutine is check to see if the KeyCode (which happens to be a property of the onKeyPress event) is less than 48 or greater than 57:
If Window.Event.KeyCode < 48 OR Window.Event.KeyCode > 57 Then
Why would we do a crazy thing like that? To answer that, take a look at the values assigned to keyboard keys 0 through 9:
|
Key |
Value |
|
0 |
48 |
|
1 |
49 |
|
2 |
50 |
|
3 |
51 |
|
4 |
52 |
|
5 |
53 |
|
6 |
54 |
|
7 |
55 |
|
8 |
56 |
|
9 |
57 |
In other words, if a key has a value of 48 through 57, then it has to be one of the numbers 0 through 9. By extension, that means that any key with a value less than 48, or any key with a value greater than 57, can’t be one of the numbers 0 through 9. By checking the value of the KeyCode property we can determine which key the user typed.
Now, if the user types a number between 0 and 9 that’s fine; in that case we don’t do anything except exit the subroutine. However, let’s assume the user has pressed a key that isn’t one of the numbers 0 through 9. For example, suppose the user types x, which has a value of 120. What happens then?
This is what happens then:
Window.Event.returnValue = False
Interestingly enough, events have all sorts of properties associated with them, including returnValue. What does the returnValue property do? Well, when set to True (the default value) it returns the value of the event; in this case, that means it will return the fact that the user pressed a key on the keyboard. However, if returnValue is set to False then the event value is not returned; in a sense, it’s as though the event never occurred. If a user presses any key other than one of the numbers 0 through 9, we set returnValue to False and the event value is discarded; that means that no character gets typed into the text box.
Confused? Give it a try and see for yourself. If you type any of the numbers between 0 and 9 (inclusive) those values will appear in the text box. But if you type anything other than those numbers ….
Anyway, we hope that helps, KV. And we apologize for the confusion at the beginning of today’s column; we had no idea that we were expected to explain how to prevent users from typing anything except numbers into a text box. Fortunately, the Scripting Editor was on the ball, and thanks to her diligence we ended up doing a bunch of research and hard work that we hadn’t planned on doing, and on what could end up being the only nice day we ever get here in Redmond. (As we sit here typing, it’s 70 degrees and sunny.) But duty is far more important than a sunny day in May, isn’t it Scripting Editor?
|
Note. Can we tell that it’s 70 degrees and sunny just by looking out our window? You bet we can. Or at least we could, if we actually had a window. In case you’re wondering, the Scripting Guy who writes this column (despite having single-handedly invented the Script Center) doesn’t have a window office. Interestingly, the Scripting Editor, whose claim to fame is that she … did … something … at some point in her life … does have a window office. But, then again, she deserves a window office. Come to think of it, she deserves a lot of things. Wouldn’t you agree, Scripting Editor? Editor’s Reply: Absolutely. Probably not anything the Scripting Guy who writes this column is thinking of, but yes, the Scripting Editor deserves a lot of things – especially her window office. |
Light
Dark
0 comments