Word version dependent VBA code (Word 2000 / Word 2002)

Topic

New Reply

I need to write a Macro that uses a Word 2002 specific parameter when calling a function if it is running on Word 2002, but that calls a different Word 2000 function when it runs on Word 2000.

Word 2000 gives a compile error if I include the Word 2002 syntax, even if it doesn’t need to execute it
I don’t want to create and maintain 2 different templates – one for each version.

I vaguely remember a syntax that would cause the VBE run time environment to conditionally skip compiling code, depending on the version, but a google search failed to show anything helpful.

Does anyone have a clue what I am talking about or a pointer to something helpful.

StuartR

Reply | Quote

Replies

hi Stuart,

put the 2002 code in a separate module and leave it uncompiled.
there’s no constant to use in a compiler directive to distinguish between 2k & 2k2(both vba 6.x), only between vba 5.x & 6.x

Reply | Quote

Thanks, a separate module is a sensible approach, and I can just call the W2002 version of the routine based on Application.Version

StuartR

Reply | Quote

Hi Stuart,

I think the following might have come from the post you’re referring to, which isn’t accessible at the moment:

If coding macros that have to work differently under different Office versions, use the VBA compiler constants to select which code runs.
#IF VBA6 then
‘ VBA 6 code here for Office 2000 and beyond
#ELSE
‘ VBA 5 code here for earlier versions
#End If
Alternatively, if the feature has more to do with the application version and less to do with the language version:
if Application.Version = “9.0” Then ‘Office 2000

Select Case Application.Version
Case “8.0” ‘Office 97
Case Else ‘Office 2000, XP, …
The #IF directive will do the correct thing with Properties and Methods that produce compile time errors. The Application.Version check is a run time check, so compile errors may still occur.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Thank you, that was just what I couldn’t remember!
Pity there isn’t a constant to distinguish 2000/2002.

StuartR

Reply | Quote

You could always test the version in an autostart and then call a routine with a static variable that holds the version indicator. After that, you could call the function and have it just return the static variable. Then you could use the result to handle the conditional code. Here’s some air code to illustrate what I mean.

Public Function WordVersion(blnReset As Boolean) As String
Static strVersion As String

If strVersion = “” Or blnReset Then
strVersion = Application.Version
End If

WordVersion = strVersion
End Function

Reply | Quote

But would I be able to use that variable in a conditional compilation

#If Variable Then
Function that would generate a compile error in Word 2000
#Else
Word2000 version of the function
#End If

StuartR

Reply | Quote

I haven’t tried it that way but it should work. You don’t have to use a compiler constant to branch conditional compilation code. The first time you called the function it would populate the static variable and return it. After that, if you called it again, it would simply return the value in the static variable.

I have to warn you, though, that I haven’t used conditional compilation recently, and then only in Access 2000.

Reply | Quote

this won’t work. only actual compiler constants can be used in compiler directives.

Reply | Quote

this won’t work. only actual compiler constants can be used in compiler directives.

Reply | Quote

I haven’t tried it that way but it should work. You don’t have to use a compiler constant to branch conditional compilation code. The first time you called the function it would populate the static variable and return it. After that, if you called it again, it would simply return the value in the static variable.

I have to warn you, though, that I haven’t used conditional compilation recently, and then only in Access 2000.

Reply | Quote

Stuart,

Did you ever find a solution to this problem of conditional compilation that you liked?

Reply | Quote

Guy,

I just created separate modules for each version, and called the appropriate code from the main module. This is modular, easy to understand, and avoids compiling the code for the wrong version during run time.

StuartR

Reply | Quote

But that also means, doesn’t it, that you can’t compile the entire project without getting an error. So the template (as a whole) is distributed “uncompiled.”

That would do for what I’m trying to do, I think. I’m doing a Startup Add-in. Is that compiled once on startup? Or only when individual modules are called?

Seems there should be constants for different versions — considering that the sytax of VBA is changing from one to the other.

Reply | Quote

You are correct, but the alternatives all seemed much worse to me.

StuartR

Reply | Quote

I wouldn’t be surprised if there were compiler constants for the application version, and MS simply didn’t document them.

Reply | Quote

[indent]

---

Is that compiled once on startup? Or only when individual modules are called?

---

[/indent] That depends. In the VBE menu Tools, Options, General tab, there’s a setting Compile on demand. When that is checked the code isn’t compiled until it’s called.

Reply | Quote

> In the VBE menu Tools, Options, General tab, there’s a setting …

“Compile On Demand

Reply | Quote

[indent]

---

I would imagine that this setting is local to the machine, however, and could not be distributed with the application

---

[/indent] Maybe you’re right, I don’t know this for sure. However, I checked on a new machine with just WinXP Pro NL and Off 2003 Pro NL installed and both “Compile on demand” and “Compile in background” (both translated from Dutch, correctly I hope) are checked, so I presume these are the default settings.

Reply | Quote

But would I be able to use that variable in a conditional compilation

#If Variable Then
Function that would generate a compile error in Word 2000
#Else
Word2000 version of the function
#End If

StuartR

Reply | Quote

You could always test the version in an autostart and then call a routine with a static variable that holds the version indicator. After that, you could call the function and have it just return the static variable. Then you could use the result to handle the conditional code. Here’s some air code to illustrate what I mean.

Public Function WordVersion(blnReset As Boolean) As String
Static strVersion As String

If strVersion = “” Or blnReset Then
strVersion = Application.Version
End If

WordVersion = strVersion
End Function

Reply | Quote

Thank you, that was just what I couldn’t remember!
Pity there isn’t a constant to distinguish 2000/2002.

StuartR

Reply | Quote

Hi Stuart,

I think the following might have come from the post you’re referring to, which isn’t accessible at the moment:

If coding macros that have to work differently under different Office versions, use the VBA compiler constants to select which code runs.
#IF VBA6 then
‘ VBA 6 code here for Office 2000 and beyond
#ELSE
‘ VBA 5 code here for earlier versions
#End If
Alternatively, if the feature has more to do with the application version and less to do with the language version:
if Application.Version = “9.0” Then ‘Office 2000

Select Case Application.Version
Case “8.0” ‘Office 97
Case Else ‘Office 2000, XP, …
The #IF directive will do the correct thing with Properties and Methods that produce compile time errors. The Application.Version check is a run time check, so compile errors may still occur.

Cheers

Cheers,
Paul Edstein
[Fmr MS MVP - Word]

Reply | Quote

Thanks, a separate module is a sensible approach, and I can just call the W2002 version of the routine based on Application.Version

StuartR

Reply | Quote

hi Stuart,

put the 2002 code in a separate module and leave it uncompiled.
there’s no constant to use in a compiler directive to distinguish between 2k & 2k2(both vba 6.x), only between vba 5.x & 6.x

Reply | Quote

> I need to write a Macro that uses a Word 2002 specific parameter

Stuart, I’m intrigued by the wording of your query. Can you tell us the nature of the paramater that is specific to a version (any version will do!) of Word?

I’ve been introduced to Dictionaries as a means of dealing with awkward parameters (in my case post 476205 between the four basic office aps WD, Xl, PPT, AC), and that leads me to believe that while Dictionaries may not be available to you in Word 2.0 (grin!), there may be a solution to the general problem of “macro parameters”.

There remains the business of compile-time version identification, I know; mine would be a solution for run-time.

Reply | Quote

Chris,

I can’t remember what particular parameter it was when I wrote this article. But every new feature introduces a number of constants. For example a macro that sets the colour of all table borders needs to deal with .Borders(wdBorderDiagonalDown), but not in versions of word that didn’t have diagonal table cell borders.

StuartR

Reply | Quote

the .Borders(wdBorderDiagonalDown) is actually not a good example of your problem, because then the compile error could easily be avoided by replacing the constant name with its value. the compile problem would only arise if you need to use a specific word 2002 method property or parameter name.

Reply | Quote

I believe the Dictionary is a Scripting object, so any version of Word that has the Scripting libraries and can instantiate a COM object should be able to use it.

Reply | Quote