Microsoft Access更新事件与失焦事件触发顺序及控件调用逻辑问题

1. 能否防止Lost Focus事件在Update事件前后触发？ #

Access控件的事件触发有固定顺序：BeforeUpdate → AfterUpdate → LostFocus（当控件确实失去焦点时）。无法直接阻止LostFocus事件本身触发，但可以通过标志位跳过事件内的业务逻辑，避免不必要的执行：

Private blnSkipLostFocus As Boolean

Private Sub ComboBox_BeforeUpdate(Cancel As Integer)
    blnSkipLostFocus = True
End Sub

Private Sub ComboBox_AfterUpdate()
    ' 你的业务代码
    blnSkipLostFocus = False
End Sub

Private Sub ComboBox_LostFocus()
    If blnSkipLostFocus Then Exit Sub
    ' 原本的LostFocus业务逻辑
End Sub

通过在Update事件前后设置标志位，让LostFocus触发时直接跳过核心逻辑，达到类似"阻止"的效果。

2. 组合框AfterUpdate调用过程是否会触发表单Before/After Update？ #

你的代码里有两个明确触发表单BeforeUpdate的原因：

• 给Me.BooleanSomeControl.Value = False赋值，会将表单设为Dirty（已修改）状态；
• 调用DoCmd.RunCommand acCmdSaveRecord时，Access会自动触发表单的BeforeUpdate事件来验证保存操作。

关于控件失焦：如果过程中没有主动调用SetFocus或操作其他控件，组合框不会自动失焦，表单BeforeUpdate的触发是因为记录修改后的保存动作，而非控件失焦。

3. 撤销后保存报错的解决方案 #

当前问题核心是：Form_BeforeUpdate里执行Undo并取消更新后，SomeProcedure里的保存命令因无更改内容报错。推荐以下两种优化方案：

方案一：在保存前检查表单Dirty状态 #

修改SomeProcedure，仅当表单处于已修改状态时执行保存，避免无更改时触发报错：

Sub SomeProcedure()
    If Me.Dirty Then
        DoCmd.RunCommand acCmdSaveRecord
    End If
    ' 后续业务代码
End Sub

方案二：调整过程调用时机，避免提前触发保存 #

不要在ComboBox_AfterUpdate里直接调用保存，而是让Access的默认事件流程处理保存，或者将保存逻辑移到更合适的时机（比如用户确认修改时）。同时修正Form_BeforeUpdate里的判断条件（当前If x=x Then永远为真，会导致所有更新都被撤销，不符合正常业务逻辑）：

Private Sub Form_BeforeUpdate(Cancel As Integer)
    ' 替换为实际业务判断条件，比如用户确认要撤销时
    If MsgBox("是否撤销当前修改？", vbYesNo) = vbYes Then
        Me.Undo
        Cancel = True
    End If
End Sub

额外建议：控件赋值的位置选择 #

如果赋值操作（Me.BooleanSomeControl.Value = False）是业务必需的，建议保留在ComboBox_AfterUpdate内，避免将UI操作混入通用过程SomeProcedure，保持逻辑的清晰性。

内容的提问来源于stack exchange，提问作者Rashad Jackson