Access Cookbook - Ken Getz [229]
The code attached to txtCharTest's KeyPress event looks like this:
Sub txtCharTest_KeyPress (KeyAscii As Integer)
' Always allow a backspace.
If KeyAscii = vbKeyBack Then Exit Sub
' If txtChars is non-null and greater than 0, and txtCharTest
' is non-null and has too many characters, set KeyAscii to 0.
If Not IsNull(Me.txtChars) Then
If Me.txtChars > 0 Then
If Not IsNull(Me.txtCharTest.Text) Then
If Len(Me.txtCharTest.Text) >= Me.txtChars Then
KeyAscii = 0
End If
End If
End If
End If
' In any case, if the keypress isn't the correct type,
' set KeyAscii to 0.
If Me.grpCharType = 1 Then
If (acb_apiIsCharAlpha(KeyAscii) = 0) Then KeyAscii = 0
Else
If (acbIsCharNumeric(KeyAscii) = 0) Then KeyAscii = 0
End If
End Sub
In the KeyPress event, Access sends you the parameter KeyAscii, which contains the ANSI value of the key that was just pressed. To tell Access to disregard this key, modify its value to 0 during the event procedure. In this case, if there's no room left in the field (based on the number in Me.txtChars) or if the character is not the right type (based on calls to acb_apiIsCharAlpha and acbIsCharNumeric), the code sets the value of KeyAscii to 0, causing Access to disregard the keypress. Play with the sample form, changing the values, to see how the code works.
Discussion
Windows internally maintains information about the currently selected language and character set. For each language, certain characters are treated as uppercase and others aren't. Some characters in the character set represent alphabetic characters and others don't. It would be impractical to maintain this information for each language your application might use. Luckily, you don't have to manage this. The Access UCase and LCase functions handle case conversions for you, but Access doesn't include case-testing functions. That's the role of the functions introduced in this solution: they allow you to test the classification of characters, no matter what the language. Attempting to perform this task in VBA will cause you trouble if you plan on working internationally.
You may not need these routines often, but when you do, the API versions are both faster and more reliable than handwritten code would be. Don't count on specific ANSI values to be certain characters, uppercase or lowercase, because these values change from version to version of internationalized Windows.
11.4. Restrict Mouse Movement to a Specific Region
Problem
You'd like to be able to restrict mouse-cursor movement to certain areas of the current form. You think it would help users of your application if the mouse stays where it needs to be until they're done with it. How can you limit mouse movement in Access?
Solution
The Windows API's ClipCursor subroutine will limit the movement of the mouse to a single form or region on a form, as you'll see in this solution.
To try out this technique, load and run the frmClip form from 11-04.MDB. This form, shown in Figure 11-5, limits the mouse movement to the area of the form once you click the large button. If you click the button again or close the form, code attached to either event frees the mouse cursor to move anywhere on the screen. If you move the form, Windows frees the mouse cursor for you.
Figure 11-5. frmClip limits mouse movement to the area of the form
To use this technique in your own applications, follow these steps:
Import the module basClipCursor from 11-04.MDB. This module contains the function declarations and user-defined types that you'll need.
To limit the mouse to a single form, you'll need to get the form coordinates and tell Windows to use those coordinates as limits for the mouse. To do this, you'll need code something like the following (because this code fragment uses Me, it must be in a form's module, not a global module):
Dim typRect as acb_tagRect
Call acb_apiGetWindowRect (Me.Hwnd, typRect)
Call acb_apiClipCursor(typRect)
To free the mouse cursor, use code like this:
Call acb_apiClipCursor(ByVal vbNullString)
See Recipe 11.4.3