Chapter 12: The Access Event Model
467
l (^) cmdButton_Click
l cmdButton_KeyDown
l (^) cmdButton_Exit
l cmdButton_LostFocus
l (^) txtText1_Enter
l txtText1_GotFocus
l (^) txtText1_KeyPress
l txtText1_KeyPress
l (^) txtText1_KeyUp
l txtText1_KeyDown
l (^) txtText1_KeyPress
l txtText1_Change
l (^) txtText1_KeyUp
You’ll have to open the code editor and display the Immediate window to see these events dis-
played. From anywhere in the Access environment, press Ctrl+G and the code editor instantly
opens with the Immediate window displayed. Then, Alt+Tab back to the main Access screen, open
the form, and click on the various controls and type something into the text box. You’ll see a long
list of event messages when you use Ctrl+G to return to the Immediate window.
Obviously, this is far more events than you’ll ever want to program. Notice that, on the command
button, both the MouseDown and MouseUp events fire before the Click event. Also, a KeyDown
event occurs as the Tab key is pushed, and then the command button’s Exit event fires before its
LostFocus event. (The focus, of course, moves off the command button to the text box as the
Tab key is pressed.)
Also, notice that the text box raises two KeyPress events. The first is the KeyPress from the Tab
key, and the second is the KeyPress that occurs as a character on the keyboard is pressed. Although
it may seem strange that the Tab key’s KeyPress event is caught by a text box and not by the com-
mand button, it makes sense when you consider what is happening under the surface. The Tab key is
a directive to move the focus to the next control in the tab sequence. Access actually moves the focus
before passing the KeyPress event to the controls on the form. This means that the focus moves to
the text box, and the text box receives the KeyPress raised by the Tab key.
Keep in mind that you only write code for events that are meaningful to your application. Any
event that does not contain code is ignored by Access and has no effect on the application.
Also, it’s entirely likely that you’ll occasionally program the wrong event for a particular task. You
may, for example, be tempted to change the control’s appearance by adding code to a control’s
Enter event. (Many developers change a control’s BackColor or ForeColor to make it easy
for the user to see which control has the focus.) You’ll soon discover that the Enter event is an
unreliable indicator of when a control has gained focus. The GotFocus and LostFocus events