cancel all but hex characters

[twas via AccessMonster.com]

How do I drop all but hex characters (0-9, A-F) from a text box while
allowing use of copy paste, and delete keys? I was thinking that a routine
like
Private Sub txtControl_KeyPress(KeyAscii As Integer)
dim strChar as string
strChar = UCase$(Chr$(KeyAscii))
If (strChar >= "0" And strChar <= "9") _
Or (strChar >= "A" And strChar <= "F") then
' good hex character
Else
KeyAscii = 0 ' cancel keystroke
End If
End Sub

might work, but how do I:
1) convert all the input characters to upper case
2) make sure that the user pasting a string into the control works
3) warn the user if the length of the resultant entry in the text box is
incorrect (a validation rule would force compliance, but that might
compromise interface usability)

thanks

 

[Guest]

How do I drop all but hex characters (0-9, A-F) from a text box while
allowing use of copy paste, and delete keys? I was thinking that a routine
like
Private Sub txtControl_KeyPress(KeyAscii As Integer)
dim strChar as string
strChar = KeyAscii strChar = UCase(strChar)
If (strChar >= "0" And strChar <= "9") _
Or (strChar >= "A" And strChar <= "F") then
' good hex character
Else
KeyAscii = 0 ' cancel keystroke
End If
End Sub

might work, but how do I:
1) convert all the input characters to upper case

see code changed above

2) make sure that the user pasting a string into the control works

either don't let them paste, or, you will need to set up a loop if/then or
probably better select case routine to iterate thru the characters 1 by 1.
AND the keypress events are NOT fired by right mouse click paste options. So
I would move all code to On_Change event, the added bonus is that you also
have access to the oldvalue as well as the newvalue entered in code.

3) warn the user if the length of the resultant entry in the text box is
incorrect (a validation rule would force compliance, but that might
compromise interface usability)

if Len(strChar) > 12 Then
msgbox"Too many characters entered"
End if

TonyT..

 

[onedaywhen]

a validation rule would force compliance, but that might
compromise interface usability

I agree interface usability is important but don't you agree that
ultimately data integrity is trumps? You are referring to one user
interface but the database may be accessed from other Access front
ends, Excel, ADO, etc. See:

Mop the Floor and Fix the Leak
by Joe Celko

"The poster was asked about some basic data integrity issue and in the
discussion, he replied that all the validation would be done in the
front end application program, so we did not have to bother with
constraints on the [database] side. Golly gee whiz, do you suppose that
might be a bad idea...?"

I'm sure even in Access there is a way of coding the UI to handle bad
data before the validation rule kicks in...

Private Sub txtControl_KeyPress(KeyAscii As Integer)
dim strChar as string
strChar = UCase$(Chr$(KeyAscii))
If (strChar >= "0" And strChar <= "9") _
Or (strChar >= "A" And strChar <= "F") then
' good hex character
Else
KeyAscii = 0 ' cancel keystroke
End If
End Sub

....but the above might not be it e.g. what about when the user *pastes*
in some bad data...?

A validation rule (or CHECK constraint) would catch such a front end
bug e.g.

NOT LIKE '*[!0-9A-F]*'

However, that assumes the ANSI Query Mode will be ANSI-89 (e.g. DAO).
Using ANSI-92 Query Mode (e.g. ADO) would effectively circumvent the
validation - not good. This would handle both modes:

CurrentProject.Connection.Execute _
"ALTER TABLE MyTable ADD" & _
" CONSTRAINT my_col__hex_chars_only" & _
" CHECK (my_col NOT LIKE '*[!0-9A-F]*'" & _
" AND my_col NOT LIKE '%[!0-9A-F]%')"

Jamie.

--