MS Access运行时中的Debug.Assert行为

在许多编译语言中，出于性能方面的原因，对Debug.Assert或其等价物的调用被排除在编译的生产代码之外。但是，对Debug.Assert的调用似乎仍然在/runtime版本的MS Access应用程序中执行。MS Access运行时中的Debug.Assert行为

为了测试这一点，我添加了以下到我的启动形式：

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，在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

来源

2014-11-20 mwolfe02

我似乎无法找到链接，但MS最近开源了办公文档。你可能想要提交一个PR。 – RubberDuck 2015-11-25 16:22:51

我不知道这是否是您的特定用例更好，但就是好，如果你正在寻找这样做在应用无关的VBA代码的替代品。 VBA有Conditional Compilation。条件复杂常量可以在模块级别声明，但在这种情况下，最好在项目级别声明它。

在菜单栏上，单击工具 >>项目属性并键入DEBUGMODE = 1进入“条件编译参数：”字段中。（注：DEBUG是行不通的，因为它是一个关键字）

Project Properties Dialog Window

现在你可以用你所有的Debug.Assert()报表中像这样的代码。

#If DEBUGMODE Then 
    Debug.Assert False 
#End If

当你准备部署你的项目，只是重新回到Project Properties对话框，改变参数DEBUGMODE = 0。

附加信息：

来源

2014-11-20 21:30:30 RubberDuck

这是一个有趣的想法，但我不确定它会购买我现有的解决方法。它避免了对'SysCmd（acSysCmdRuntime）'调用的开销，但是这可能忽略不计。另外，我尽量避免使用条件编译，仅仅是因为在部署更新之前记得切换标志的可怕时间。 – mwolfe02 2014-11-20 21:53:30

关于你作为一个不依赖于应用程序的解决方法的观点是一个很好的观点（我在一读时忽略了一个）。在Excel，Word，Outlook等中没有真正的“运行时”等效项。条件编译可能是这些应用程序唯一可靠的解决方法。 – mwolfe02 2014-11-20 21:56:06

是的。我真的不认为它真的会在Access中购买任何东西，但我不认为'SysCmd'在其他Office应用程序中可用，所以这是我所知道的唯一的“便携”方式。 – RubberDuck 2014-11-20 21:58:23

MS Access运行时中的Debug.Assert行为

回答

相关问题