VBA7 compiler constant usage

Question

Bear with me ... have to step back a bit to explain where I'm coming from and why.  Then the actual question.

The name of the Win64 compiler constant strikes me as confusing.  If it's true, you know you're running on a 64-bit version of Office, which necessarily implies that you're running on Win64, but if it's false (or rather undefined), it tells you you're running a 32-bit version of Office, not whether you're in Win/64 or 32.

So, thinks I, I'll do this instead:

#If Win64 Then

Const Office64 as Boolean = True

#Else

Const Office64 as Boolean = False

#End If

and from that point on, I can do

If Office64 then

' whatever

Else

' Whatever else

End If

Easier to type, easier to understand.  Great.

So then I figured, why not:

#If VBA7 Then

Const VBA7  as Boolean = True

#Else

Const VBA7 as Boolean = False

#End If

In real life, I'll use a different name for the constant, if only to make it VERY clear that I'm not using compiler directives, but I wondered what side effects this kind of construct might cause, if any.

Help says this in reference to Win64, Win32 etc::  "These constants are provided by Visual Basic, so you cannot define your own constants with these same names at any level."

That doesn't seem to hold true of VBA7, or at least doing so triggers no compiler errors.  And swapping the defs around like so:

#If VBA7 Then

Const VBA7  as Boolean = False

#Else

Const VBA7 as Boolean = True

#End If

produces the expected results.  If Not VBA7 Then .... executes under Office 2010 and 2013 preview.

Again, this isn't a problem so much as a curiosity.  Thoughts?

Answer 1

No problem, Andreas.  

Thanks for the answer anyway, and especially thanks for all of your other hugely useful answers.  I've learned a LOT from you and appreciate it tremendously.

Answer 2

I beg your pardon, it is sometimes difficult for me to understand posts.

Answer 3

Isn't that what Steve is saying though. You can but you shouldn't be able to.

Answer 4

>> That looks like an oversight to me - it's undesirable and highly confusing to be able to set these constants yourself...

It seems that way to me too.

I'll resist the temptation. ;-)

Answer 5

I'm using 32-bit Office 2010 on 64-bit Windows 7.

Contrary to the statement "These constants are provided by Visual Basic, so you cannot define your own constants with these same names at any level", I can create both compiler constants and ordinary constants with names such as Win64, VBA7 or Mac, and set any value for them. Code compiles and runs without problems.

That looks like an oversight to me - it's undesirable and highly confusing to be able to set these constants yourself...