You can control how your project is compiled. Have one “source base” that you use for multiple purposes, environments, or in multiple “modes” of operation. You can use Microsoft defined Compiler Constants and you can define your own.
https://docs.microsoft.com/en-us/office/vba/language/concepts/getting-started/compiler-constants
(This is misleading since it refers to the Microsoft constants as having values of True or False which is not correct. Instead they are 1 or 0 respectively).
The Problem
Compiler Constants are frequently treated as Boolean types, but they are in fact Integer types. So, 0=False and anything else is True. In addition to this Microsoft defines the VBA compiler constants as 1=True and 0=False, rather than -1 and 0 respectively for normal Boolean data types.
So, for example, the statement {#IF Vba7 = True then …} will never be True (since it is 1 or 0 and never -1). Instead, the common expression {#IF Vba7 then …} will work because it is actually comparing {Vba7 <> 0}. However, {#IF Not Vba7 then …} will always evaluate as True since (Not 0) evaluates to -1 and (Not 1) evaluates to -2.
The Solution
You can use one of the following conventions to keep your sanity:
1. To get to the “false” condition of a Microsoft defined Compiler Constant always use the Else clause as in:
#IF Vba7 then
#ELSE
your code for False operation here…
#END IF
2. Or you can explicitly test for true or false as in:
#IF Vba7 = 1 then …
– or –
#IF Vba7 = False then …
When you define your own Compiler Constants you can
1. follow the Microsoft convention of 1=true and 0=false to stay in the same reality for all Compiler Constants,
2. or use the normal -1 for true and 0 for false and then use normal comparison to True and False including the Not operator, as in:
{#IF Not MyVar Then …} or {#IF MyVar Then …}
Background
See “That Whacky Conditional Compiler Constant” posted here: