Вы делаете свою жизнь слишком сложной, применяя концепции из другой среды разработки к Access VBA.Хотя VBA поддерживает WithEvents / RaiseEvent, здесь нет причин усложнять.
Обычный способ работы с диалогами в Access состоит в том, что вместо их закрытия вы их скрываете.Это позволяет запускать код после открытия формы, оставляя значения в форме доступными для использования в этом коде.
Пример кода в событии OnOpen отчета, который открывает форму для сбора значений для фильтрацииreport:
Private Sub Report_Open(Cancel As Integer)
DoCmd.OpenForm "dlgDateRange", , , , , acDialog, "ThisYear"
If IsLoaded("dlgDateRange") Then
With Forms!dlgDateRange
If .Tag = "Cancel" Then
Cancel = True
Else
Me.Filter = "[InvoiceDate] Between #" & !txtStart & "# AND #" & !txtEnd & "#"
Me.FilterOn = True
Me!lblDateRange.Caption = StrConv(Trim(("from " + varZLStoNull(Format(!txtStart, "mm/dd/yyyy"))) _
& (" to " + varZLStoNull(Format(!txtEnd, "mm/dd/yyyy")))), vbProperCase)
End If
End With
DoCmd.Close acForm, "dlgDateRange"
End If
End Sub
Диалоговая форма имеет две командные кнопки, CONTINUE >> и CANCEL.Кнопка ОТМЕНА устанавливает для тега формы значение «Отмена», а для свойства формы .Visible устанавливается значение «Ложь».Кнопка ПРОДОЛЖИТЬ >> ничего не делает, кроме как устанавливает свойство формы .Visible в False.Нажатие любой из этих кнопок позволяет продолжить выполнение кода после того, как форма открыта с помощью переключателя acDialog.
Моя философия - сделать диалоги настолько глупыми, насколько это возможно.Вызывающий код должен знать, что он ищет в формах (т. Е. Вам нужно знать имена элементов управления, из которых вы читаете данные), но это можно обойти, добавив в форму свойства клиента.Но тогда вы должны знать имена свойств, поэтому вы просто переместили шар.
Я также реализовал этот тип, обернув форму dailog в модуле класса, и затем вызывающий контекст просто инициализируетэкземпляр класса, а затем извлекает значения из него в соответствующее время.Но это на самом деле сложнее, чем подход выше.