5.2.4 Event sequence for text box
We have now looked at two events for the text box,
Change and AfterUpdate. However, there are many
more, as you can tell from the Event tab in the property
box. (Select the event procedure and click F1 to get an
explanation of the event.) Figure 5.2D shows typical
event sequences for a text box. We will explain what
User clicks in the text box. First, the text box's Form
object may get a Current event. This happens if the
text box is in a record that wasn't selected before.
Next, the text box receives two events, Enter and
GotFocus. Enter signals that now the control is
active. Before calling the Enter event-procedure,
Access creates the Text property and sets it to the
current Value of the text box. GotFocus signals that
typing will now go to this control.
Then the textbox receives this series of events:
MouseDown, MouseUp, Click and maybe also a
User types an Ascii character. The text box receives
four events: KeyDown, KeyPress, Change, KeyUp
(plus mouse events if the mouse is used). KeyDown
occurs when the user depresses any key. The event
procedure has parameters that give details of the
physical key and other keys depressed at the same
time, for instance Shift and Ctrl. KeyPress occurs
when the key has generated an Ascii character, for
instance a letter, digit, space, tab or backspace. All
of these correspond to characters in the Ascii al-
The Change event occurs when the visible content
of the control has changed, for instance that a char-
acter was added to the text or a character was de-
leted. Before calling this event procedure, Access
updates the Text property so that it contains what
the user sees.
The KeyUp event occurs when the user releases the
key. If the user keeps the key down to generate for
instance a whole sequence of x's, each x generates
KeyDown, KeyPress and Change. The KeyUp oc-
curs only when the user releases the key.
User types a non-Ascii character, for instance Arrow
left or F6. This generates only the KeyDown-event
(and the KeyUp). Nothing happens to Text or
Value, and no Change event is generated.
User types Delete. Delete is not an Ascii character, so
no KeyPress-event occurs. However, one or more
characters may be deleted, and then a Change event
occurs. KeyDown and KeyUp occur too.
User tabs to the next field. Access generates several
events. KeyDown occurs since the user pressed the
Tab key. BeforeUpdate shows that the user has fin-
ished the field, but it is not yet accepted. Before
calling the event procedure, Access has copied Text
to Value. BeforeUpdate may check the value, and
in case something is wrong reject the update.
Rejecting the update means that focus remains on
the text box and no AfterUpdate event is generated
yet. The user may edit the field or click Esc to set
the value back to its old value.
If it is an unbound control (not connected to a
database record), Access will also copy Text to
OldValue before calling the procedure. This is quite
illogical because OldValue is intended for letting
the program restore an erroneous field. This is not
possible for unbound controls.
Next comes the AfterUpdate-event. The value has
been checked and the procedure may act on it. In
the example above we used this opportunity to re-
compute the stay list. If it is a bound control, the
value will not yet be stored in the database, nor will
OldValue be changed. Storing the value in the
database doesn't happen until the user moves to
another record or explicitly saves the record with
Shift+Enter (or Records -> Save Record).
Next comes the Exit event. It signals that the field is
not active anymore. Finally, LostFocus occurs and
signals that typing will go to another control. When
both events have occurred, the Text property disap-
What about KeyUp? It happens in the next field,
which accordingly receives the KeyUp event.
Before that, the next field receives Enter and
GotFocus - in the same way as if the user clicked in
the next field.
What about errors in what the user has typed, for
instance an incorrect date? Access shows an error
message to the user instead of calling Before-
Update, and the cursor remains in the field. Can't
the program interfere before this error message?
Yes it can. The form receives a Form_Error event,
which may take action and cancel the error message
that Access was about to show (see section 5.5.10).
User clicks in next field. Access does almost the same
as when the user tabs to the next field. The only dif-
ference is that there is no KeyDown event.
User moves to next record. First the text box in focus
will receive the same events as if the user moved to
another control in the same record.
Next, the Form object receives three events.
BeforeUpdate signals that the record is about to be
saved and that the program may check that values
are correct and consistent with each other. The Be-
5. Access through Visual Basic