4

In many compiled languages, calls to Debug.Assert, or their equivalent, are left out of the compiled production code for performance reasons. However, calls to Debug.Assert still appear to execute in the /runtime versions of MS Access applications.

To test this, I added the following to my startup form:

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

When I run this in a development environment and click [No] on the MsgBox, execution breaks at the Debug.Assert line (as I would expect).

When I run the same code with the /runtime switch (using a full version of MS Access 2002) I still see the MsgBox, but clicking on [No] does not halt program execution. It seems VBA executes the line but ignores the result. This is not surprising, but it is unfortunate.

I was hoping that Access would skip the Debug.Assert line completely. This means that one must take care not to use Debug.Assert lines that would hurt performance, for example:

Debug.Assert DCount("*", "SomeHugeTable", "NonIndexedField='prepare to wait!'") = 0

Is this behavior documented somewhere? The official documentation in Access appears to be pulled verbatim from VB6:

Assert invocations work only within the development environment. When the module is compiled into an executable, the method calls on the Debug object are omitted.

Obviously, MS Access apps cannot be compiled into an executable. Is there a better alternative than the following workaround?

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
mwolfe02
  • 23,787
  • 9
  • 91
  • 161
  • I can't seem to find the link right now, but MS open sourced the office documentation recently. You may want submit a PR on this. – RubberDuck Nov 25 '15 at 16:22

1 Answers1

4

I don't know if it's any better for your particular use case, but there is an alternative that is better, if you're looking to do this in application agnostic VBA code. VBA has Conditional Compilation. Conditional Complication constants can be declared at the module level, but in this case, it will be better to declare it at the project level.

On the menu bar, click Tools>>Project Properties and type a DEBUGMODE = 1 into the "Conditional Compilation Arguments:" field. (Note: DEBUG won't work as it's a keyword.)

Project Properties Dialog Window

Now you can wrap all of your Debug.Assert() statements in code like this.

#If DEBUGMODE Then
    Debug.Assert False
#End If

When you're ready to deploy your project, just go back into the Project Properties dialog and change the argument to DEBUGMODE = 0.

Additional Information:

RubberDuck
  • 11,933
  • 4
  • 50
  • 95
  • That's an interesting idea, but I'm not sure it buys much over my existing workaround. It does avoid the overhead of the call to `SysCmd(acSysCmdRuntime)`, but that's likely negligible anyway. Also, I try to avoid using Conditional Compilation just because I have a terrible time remembering to switch the flags before deploying updates. – mwolfe02 Nov 20 '14 at 21:53
  • 1
    Your point about yours being an application-agnostic workaround is a good one (and one that I overlooked on first reading). There's no real "runtime" equivalent in Excel, Word, Outlook, etc. Conditional compilation is probably the only reliable workaround for those applications. – mwolfe02 Nov 20 '14 at 21:56
  • Yeah. I really don't think it really buys you anything in Access, but I don't think `SysCmd` is available in the other Office Applications, so this is the only "portable" way to do it that I know of. – RubberDuck Nov 20 '14 at 21:58
  • 1
    You can also make your code do a lookup against a table value somewhere you set, so you can turn this on/off without redeploying a new runtime environment (depending on your use case). I have mine setup to do a "checkIfDeveloper" function based on my login so any "debug" stuff only happens for me or other developers. – enderland Nov 20 '14 at 23:55
  • @enderland: When you say you "can turn this on/off" is the "this" you are referring to the Debug.Assert or the conditional compilation? If it's the latter I would be very interested in that, because I did not think there was any way outside of the IDE itself to make changes to global Conditional Compilation arguments. – mwolfe02 Nov 21 '14 at 15:48
  • @mwolfe02 it is actually possible to programatically make changes to global conditional compilation arguements. http://stackoverflow.com/a/19801057/3198973 – RubberDuck Nov 21 '14 at 15:54
  • That's interesting, but it appears one would still need access to the IDE to make those changes. That's not an option for a runtime Access environment. Thanks for the link, though. The technique of using `SendMessage` to interact directly with Windows elements from VBA was itself enlightening. It's something that may come in handy in situations where I've previously felt forced to fall back on SendKeys {shudder}. – mwolfe02 Nov 21 '14 at 16:11