在许多编译语言中,出于性能原因,对编译的生产代码中不包含对Debug.Assert
或其等效语句的调用。但是,对Debug.Assert的调用仍然似乎在/runtime
版本的MS Access应用程序中执行。
为了测试这一点,我将以下内容添加到我的启动表单中:
Private Sub Form_Load()
Debug.Assert UserOK()
End Sub
Function UserOK() As Boolean
UserOK = MsgBox("Is everything OK?", vbYesNo, "Test Debug.Assert") = vbYes
End Function
当我在开发环境中运行它并单击MsgBox上的[No]时,执行会在Debug.Assert行中断(正如我所料)。
当我使用/runtime
开关(使用完整版本的MS Access 2002)运行相同的代码时,我仍然看到MsgBox,但单击[否]不会停止程序执行。似乎VBA执行该行但忽略了结果。这并不奇怪,但不幸的是。
我希望Access完全跳过Debug.Assert行。这意味着必须注意不要使用会损害性能的Debug.Assert行,例如:
Debug.Assert DCount("*", "SomeHugeTable", "NonIndexedField='prepare to wait!'") = 0
此行为是否记录在某处? Access中的官方文档似乎是从VB6逐字逐句提取的:
断言调用仅在开发环境中起作用。将模块编译为可执行文件时,省略对Debug对象的方法调用。
显然,MS Access应用程序无法编译为可执行文件。 是否有比以下解决方法更好的选择?
Private Sub Form_Load()
If Not SysCmd(acSysCmdRuntime) Then Debug.Assert UserOK() 'check if Runtime
End Sub
Function UserOK() As Boolean
UserOK = MsgBox("Is everything OK?", vbYesNo, "Test Debug.Assert") = vbYes
End Function
答案 0 :(得分:4)
我不知道你的特定用例是否更好,但如果你想在与应用程序无关的VBA代码中做这件事,那么还有一个更好的选择。 VBA有Conditional Compilation。条件复杂常量可以在模块级别声明,但在这种情况下,最好在项目级别声明它。
在菜单栏上,单击工具>> 项目属性,然后在“条件编译参数:”字段中键入DEBUGMODE = 1
。 (注意:DEBUG
无效,因为它是关键字。)
现在,您可以将所有Debug.Assert()
语句包装在这样的代码中。
#If DEBUGMODE Then
Debug.Assert False
#End If
当您准备部署项目时,只需返回“项目属性”对话框并将参数更改为DEBUGMODE = 0
。
其他信息: