So far, this discussion has focused on how the process of evaluating conditional
compiler expressions works. You still need to know more about the kinds of expressions
that the preprocessor can handle. Just like any other conditional statement, the
preprocessor requires the expressions it evaluates to have a truth value—that
is, they must evaluate to True or False, where True is defined as any non-zero
value and False is zero. These expressions may consist of the following three
components, two of which are probably already familiar:
You probably understand operators already. The same arithmetic and logical
operators used in any other conditional statement are available for use in preprocessor
conditional statements, with one exception. You can use any arithmetic or logical
operator except Is—because Is is a special operator used to compare VB object
variables, and the preprocessor doesn’t understand VB variables.
Literals are probably familiar by now, too. A literal can be a numeric value,
such as 1 or 256, or a text string, such as "Hello,
world". When comparing values, the Option Compare statement has no
effect upon expressions in #If and
#ElseIf statements. Conditional compiler statements are always evaluated
with Option Compare Text.
Because these tests use only operators and literals, both tests are valid:
#If 1 < 2 Then
‘ do something
#ElseIf "MyString" = "MyString" Then
‘ do something else
Not only are both of the tests valid, but it so happens that both are also
True. However, only the do something code will be compiled into the executable
because the conditional statement on which it depends, 1 <
2, is evaluated first. The do something else conditional,
"MyString" = "MyString", is True, but because it
is part of an #ElseIf test, it is skipped when any
previous #If or #ElseIf at
its level in the block evaluates to True. However, this test is not valid:
Dim db1 as Database, db2 as Database
Set db1 = DBEngine(0)(0)
Set db2 = db1
iCounter = 100
#If db1 Is db2 Then
‘ try this
#ElseIf iCounter > 0 Then
‘ try this instead
There are two problems here. The first should be obvious from the rule for
operators stated earlier: The #If statement uses the
Is operator, which is explicitly disallowed.
What’s wrong with the second conditional? Because it is True that
iCounter is greater than zero, it may seem that nothing is wrong here.
The problem is that the preprocessor can’t use VB variables, so it has no
idea what to do with iCounter. (In fact, that’s
also a problem with the #If statement’s use of
the db1 and db2 variables.)
Although these variables make perfectly good sense in the context of a VB program,
remember that the preprocessor doesn’t speak the same language as the compiler.
The preprocessor may be responsible for deciding which code gets sent to the compiler,
but it doesn’t have to know anything about VB code to accomplish that task.
If you could only use literals in your tests, the preprocessor wouldn’t
make for a very interesting tool. You could only construct tautologies (statements
that are always true) or contradictions (statements that are always false). You
could move such statements from place to place in your code, explicitly selecting
the lines you want to include by wrapping them with tautologies, and screening
the lines you want to exclude with contradictions, but that’s a lot of manual
labor. It would almost be as easy to wade through the each project’s code,
manually commenting out any undesired lines on a build-by-build basis.
Fortunately, an easier way exists. Besides operators and literals, you will
recall that a third component allowed in conditional compiler tests was mentioned
earlier: compiler constants. Compiler constants are the key to doing tricks with
the VB preprocessor.