Welcome aboard
The reason you can't find this information is because it is variable and depends on the state of the current record and whether any control on the current record had the focus. The most important event of a form is the FORM's BeforeUpdate event (controls have BeforeUpdate events also). It is the LAST event that fires before a record gets saved to the table and is the event you should use for most of your validation code. Especially any code that checks for null values or compares the values of multiple fields MUST go here since there are flaws with putting this code anywhere else.
The second most important form level event is the Current event. This event runs each time a new record is displayed.
There is no "I'm leaving the form" event (which many of us would like).
The OnChange event is one which you will rarely need to use. I don't think I've used it three times in 20 years of using Access. It fires once for each keystroke and so is used only when you have to validate data character-by-character as the user is typing it. Within this event, you use the .text property of the control because the data has not yet been placed in the .value property (which is the default property for controls).
The Form's AfterUpdate event runs after the record has been saved. It should NEVER be used to modify data in the current form. Many people mistakenly add code here that dirties the current record and that puts Access into an infinite loop. Luckily newer versions of Access are smart enough to detect this and break out after a certain level of recursion. Otherwise, the form would simply freeze and never come back.
To watch event processing for yourself, create a form with a control and add message boxes to various events that display the event name and watch the order they appear. If you add a subform with a control, you'll really see some strange things. Access actually loads the subforms before it loads the main form and so the subform events all fire at least twice.
