Data Events

Access being a database, you should not be surprised to discover that many of its events involve the data that the user is entering, or that's being saved to or retrieved from the database. There are actually two sets of data events. The first set applies to any control that is bound to data:

• BeforeUpdate Fired after the user changes data, but before the data is committed to the form.

• AfterUpdate Fired after data changes are committed to the form.

The second set of data events apply only to controls where you can type data (text boxes or combo boxes):

• KeyDown Fired every time the user presses a key.

• KeyPress Fired when the key's value is sent to Access.

• Dirty Fired when the form is marked dirty (the editing pencil appears in the form's record selector).

• Change Fired when the keystroke changes the value displayed onscreen.

• KeyUp Fired when the user releases the key.

To see these events in action, here's some code that you can hook up to the Phone text box on the Clients form:

 Private Sub Phone_AfterUpdate()   Debug.Print "Phone AfterUpdate" End Sub Private Sub Phone_BeforeUpdate(Cancel As Integer)   Debug.Print "Phone BeforeUpdate" End Sub Private Sub Phone_Change()   Debug.Print "Phone Change" End Sub Private Sub Phone_Dirty(Cancel As Integer)   Debug.Print "Phone Dirty" End Sub Private Sub Phone_KeyDown(KeyCode As Integer, Shift As Integer)   Debug.Print "Phone KeyDown"   Debug.Print "  KeyCode = " & CStr(KeyCode)   Debug.Print "  Shift = " & CStr(Shift) End Sub Private Sub Phone_KeyPress(KeyAscii As Integer)   Debug.Print "Phone KeyPress"   Debug.Print "  KeyAscii = " & CStr(KeyAscii) End Sub Private Sub Phone_KeyUp(KeyCode As Integer, Shift As Integer)   Debug.Print "Phone KeyUp"   Debug.Print "  KeyCode = " & CStr(KeyCode)   Debug.Print "  Shift = " & CStr(Shift) End Sub 

Save the form with this code and type a character in the Phone text box. You'll see events similar to this:

 Phone KeyDown   KeyCode = 50   Shift = 0 Phone KeyPress   KeyAscii = 50 Phone Dirty Phone Change 

Type more characters, and you'll see the same events repeat, except for the Dirty event (after the control is dirty, it won't get dirty again until you save its value). Now tab to the next control to see the data events:

 Phone BeforeUpdate Phone AfterUpdate 

You probably noticed that the code for the KeyDown, KeyPress, and KeyUp events prints some extra data. Rather than implement different events for each key on the keyboard, the Access team chose to use the Key events for every key. To allow your code to tell which key was pressed, these events pass in arguments (KeyCode and Shift in the case of KeyDown and KeyUp, KeyAscii in the case of KeyPress) that Access fills in with information on the current key. The KeyCode and KeyAscii parameters tell you the ASCII code of the key that was pressed, whereas the Shift parameter is set to indicate which (if any) of the Ctrl, Alt, and Shift keys were being held down at the same time. Refer to the help on the KeyDown event for details on decoding these parameters.

Control-Specific Events

Some controls have particular events associated closely with them. A good example is the button control, whose Click event you've already seen more than once. Most of a user's interaction with button controls involves clicking the buttons, which fires the Click event.

For toggle buttons, check boxes, and option buttons, the usual event fired by user interaction is the Click event. This event fires when the user clicks on one of these controls. But there's a catch: the click event exists only when these controls are placed directly on a form. If these controls are placed within an option group (which is the more usual way to use them), clicking the controls fires the data events of the parent option group.

Combo box controls have a somewhat peculiar event: the NotInList event. This event is fired when the user types something in the text portion of the combo box that's not contained in the list portion of the combo box. You can use this event to automatically add new data to the list when the user types a new entry. Schematically, you might take these steps:

1. Handle the NotInList event.
   
   

2. Ask the users whether they want to add the new entry to the list.
   
   

3. If the users agree, run code to add the new entry to the table that supplies data for the combo box.
   
   

4. Refresh the combo box.
   
   

This sequence is covered in more detail in Chapter 12, "Working with List and Combo Boxes." The NotInList event fires after the KeyUp event.