I'm not aware of a list of things that trigger other events, and it's not
always consistent between versions.
If you think about it, the example you give kinda makes sense. The subform
is linked to the main form via LinkMasterFields/LinkChildFields. Change
these properties, and Access has to re-link them, and the linking code
probably executes when the form opens.
Part of your experience as a developer is becoming aware of what triggers
what events, and even the queue of events that could be triggered by other
events. For example, if you use the KeyDown event of a continuous form to
move down to the next record (as happens in a Datasheet), the event
happens while focus is in a particular control. Many of the control's own
events may be triggered by the keystroke (KeyDown, KeyPress, KeyUp, Dirty,
Change, BeforeUpdate, AfterUpdate, Exit, and Lost Focus), as well as
several events for the form (KeyDown, KeyPress, KeyUp, Dirty,
BeforeUpdate, AfterUpdate, possibly AfterInsert or Undo, and then Current
as the form moves record.)
So one event procedure can trigger an entire queue of other events. AFAIK,
there's no specific list of these events, and what documentation is
available is not alway accurate (e.g. there are cases where the form's
events do not occur in the order contained in the documentation.)
That's one of the reasons why I recommend explicitly saving a record
before anyththing that requires the save to take place (such as changing a
filter, sort order, Record Source, moving record, closing form, ...)
Explicitly saving triggers these pending events, and lets you trap any
problems with the existing data before you try to perform the operation
you want.
I can't think of a particular case where firing Form_Open would have
tragic consequences, but if it really is important, you may be able to set
a boolean variable before assigning the values for
LinkMasterFields/LinkChildFields, check the boolean in Form_Open, and
reset it immediately afterwards.
Hope that helps.
