Debug Mode In VB 6?

Question

How can I do something similar to the following C code in VB 6?

#ifdef _DEBUG_
    // do things
#else
    // do other things
#end if

Dolor

Answer 1

It's pretty much the same as the other languages that you're used to. The syntax looks like this:

#If DEBUG = 1 Then
    ' Do something
#Else
    ' Do something else
#End If

It's easy to remember if you just remember that the syntax is exactly the same as the other flow-control statements in VB 6, except that the compile-time conditionals start with a pound sign (#).

The trick is actually defining the DEBUG (or whatever) constant because I'm pretty sure that there isn't one defined by default. There are two standard ways of doing it:

1. Use the #Const keyword to define the constant at the top of each source file. The definition that you establish in this way is valid throughout the entire source module. It would look something like:

    #Const DEBUG = 1
   

2. Set the constant in the project's properties. This would define a constant that is valid throughout the entire project (and is probably what you want for a "Debug" mode indicator).

   To do this, enter something like the following in the "Conditional Compilation Constants" textbox on the "Make" tab of the "Project Properties" dialog box:

    DEBUG = 1
   

   You can define multiple constants in this dialog by separating each of them with a colon (:):

    DEBUG = 1 : VERSION2 = 1
   

Remember that any constant which is not defined is assumed to be 0.

Changchun

This looks fantastic, just one question, when you compile the release version of the exe I'm assuming you need to set DEBUG = 0 or does VB auto detect this and somehow manages to ensure the debug stuff is not compiled (I gather const would have to be internally hardcoded into compiler for it to be able to do this, unlikely but just wanted to make sure). So before release just set DEBUG = 0 and ur ready to compile? – Hymettus

@Erx: No, there's no auto-detection done by the compiler. The DEBUG symbol is not defined automatically, you have to do it yourself. So switching to "release" mode is a manual action. Yes, in this example, you'd change the compile-time DEBUG constant to 0. – Changchun

what would happen if you put the DEBUG = 1 into your code general declarations module area...? Would it still work or fail? – Hymettus

@Erx: I don't know what you mean by "code general declarations module area". Do you mean at the top of the source file for a module? It would take effect only in that module. If you want it to apply to the entire project, you'd need to add it to the project properties or all code files in your project. – Changchun

bascially, i was wondering if i did a "Public Const DEBUG As Boolean = True" in either of my modules (right on the top, not inside a class), since these variables are 100% Global, would that work? Because I was trying to understand the significance of using the Conditional Compilation Arguments section, thanks. – Hymettus

@Erx: That won't do anything. You need to prefix the line with a # symbol. This has nothing to do with the regular compiler. This is a separate stage that happens before regular compilation. Defining the symbol in a code file only declares it for that code file. There is no such thing as "global scope" for preprocessor symbols. That's why you need to use the dialog. – Changchun

Answer 2

Cody has told you about conditional compilation. I'd like to add that if you want different behaviour when debugging on the IDE (e.g. turn off your own error handling so that the IDE traps errors) you don't need conditional compilation. You can detect the IDE at runtime like this.

On Error Resume Next 
Debug.Print 1/0 
If Err=0 then 
  'Compiled Binary 
Else 
  'in the IDE 
End if

This works because Debug.Print is omitted in the compiled EXE.

• EDIT Remember to turn off On Error Resume Next !
• EDIT You can wrap the check in a function like this (thanks CraigJ)

Spectrohelioscope

That's a nice tip, but you probably want to turn off On Error Resume Next at some point, eh? :-) – Changchun

Why? On Error Resume Next is best error handling strategy - user doesn't see any error this way :) Well, at least until (s)he doesn't look at actual data... More seriously, we're just using global variable (inEXE) and initializing it while program starts; same for debug and trace flags. Yes, this approach doesn't use preprocessor directives, but run-time overhead (from checking various flags) is negligible compared to database access or even simple UI drawing. – Doubler

You would be better to declare a global flag, and do this check somewhere towards the beginning of Sub Main. That way you can check for debug with minimal overhead. – Fermat

@MarkBertenshaw My way to minimize the overhead is to wrap the code into a global function, and use a local static to make sure the check is only carried out once – Spectrohelioscope

Answer 3

To achieve the same effect as MarkJ, but with error handling, you can use the following code.

Public Function GetRunningInIDE() As Boolean

   Dim x As Long
   Debug.Assert Not TestIDE(x)
   GetRunningInIDE = x = 1

End Function

Private Function TestIDE(x As Long) As Boolean

    x = 1

End Function

When you are running from within the IDE, there will be an extra overhead of calling a function (which is ridiculously small). When compiled, this evaluates to a simple number comparison.

Twila

+1. This actually looks like what we actually use at work, but I didn't post that code, because it belongs to my employer. – Spectrohelioscope

Answer 4

This is my short and stable code. I think it is better than conditional constants, because you don't need to change it every complication time.

Public Function InIDE() As Boolean
  On Error Resume Next
  Debug.Print 0 / 0
  InIDE = Err.Number <> 0
End Function

Medication

+1 Best answer because it's short and sweet and does not require changing the project properties whenever you need to recompile. – Scutum