Static, you are still missing the point that Greg and I were making. On the other hand, with regarding to getting drunk... want company? But I digress.
In VBA or in any other formal computer language I know, and I can count at least half a dozen major ones, FALSE is false and TRUE is true. Boolean is NOT A NUMBER.
The problem that was being explained is that unfortunately, VBA and Access (and a lot of other languages) DO NOT HAVE a native Boolean variable because they are limited to whole-byte addresses. They do not do bit-mode addressing. It is a language implementation constraint.
Internally there is a representational convention in which a BYTE INTEGER acting as a Boolean variable gets either 0, meaning FALSE, or -1, meaning TRUE. But this is an ARTIFACT of the implementation that occurs because there IS no native data type that is 1 bit long and stores either true or false.
It is the same thing as saying that an "infinite" result is often stored as the maximum value for a given representation. So a signed LONG representation of infinity is +2 billion and change. A SINGLE representation of infinity is 1.something x 10^38. These are representation artifacts. A DOUBLE, if typecast as a DATE, stores any date after the epoch starting reference of 0, representing 31-Dec-1899 (or 1-Jan-1900, depending on whether you are talking Access or Excel). And by the same token, -1 is the value for TRUE in the byte integer used to represent a Boolean data type.
The OP's problem is simply that in the absence of formatting instructions, the VBA methods of examining that storage unit look at it as a BYTE rather than a Boolean. And my original discussion was to suggest using CBool to force the output routines to see it as a Boolean. Because in essence, using an unformatted output method to look at an unusually formatted variable results in a confusing answer.