2014-11-20 62 views
4

在許多編譯語言中,出於性能方面的原因,對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 
+0

我似乎無法找到鏈接,但MS最近開源了辦公文檔。你可能想要提交一個PR。 – RubberDuck 2015-11-25 16:22:51

回答

4

我不知道這是否是您的特定用例更好,但就是好,如果你正在尋找這樣做在應用無關的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

附加信息:

+0

這是一個有趣的想法,但我不確定它會購買我現有的解決方法。它避免了對'SysCmd(acSysCmdRuntime)'調用的開銷,但是這可能忽略不計。另外,我儘量避免使用條件編譯,僅僅是因爲在部署更新之前記得切換標誌的可怕時間。 – mwolfe02 2014-11-20 21:53:30

+1

關於你作爲一個不依賴於應用程序的解決方法的觀點是一個很好的觀點(我在一讀時忽略了一個)。在Excel,Word,Outlook等中沒有真正的「運行時」等效項。條件編譯可能是這些應用程序唯一可靠的解決方法。 – mwolfe02 2014-11-20 21:56:06

+0

是的。我真的不認爲它真的會在Access中購買任何東西,但我不認爲'SysCmd'在其他Office應用程序中可用,所以這是我所知道的唯一的「便攜」方式。 – RubberDuck 2014-11-20 21:58:23