Writing simple form and control event procedures
Writing simple procedures to verify a form or control's event sequence is quite easy. Use the preceding information to determine which event should be harnessed in your application. Very often unexpected behavior can be traced to an event procedure attached to an event that occurs too late - or too early! - to capture the information that is needed by the application.
For example, clicking the command button one time, and then tabbing to the text box and pressing one key on the keyboard fires the following events:
- cmdButton_MouseDown
- cmdButton_MouseUp
- cmdButton_Click
- cmdButton_KeyDown
- cmdButton_Exit
- cmdButton_LostFocus
- txtText1_Enter
- txtText1_GotFocus
- txtText1_KeyPress
- txtText1_KeyPress
- txtText1_KeyUp
- txtText1_KeyDown
- txtText1_KeyPress
- txtText1_Change
- txtText1_KeyUp
You'll have to open the code editor and display the Immediate window to see these events displayed. 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 command 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 are specifically provided for the purpose of controlling the user interface, while the Enter and Exit events are more "conceptual" in nature and are not often programmed in Access applications.
This small example helps explain, perhaps, why Access supports so many different events. Microsoft has carefully designed Access to handle different categories of events, such as data or user-interface tasks. These events provide you with a rich programming environment. You'll almost always find exactly the right control, event, or programming trick to get Access to do what you need.