Macros failing in different language versions of Word

[stephenc]

My company wants to standardize on templates across several countries - we
have offices in many countries, but for simplicity I will just talk about UK
and Sweden. My problem is that some features in the English version of Word
do not work in the Swedish version of Word.

For example, StylRef. I use StyleRef in the header margin to refer to
"Heading 1" style. The problem is that it is not called "Heading 1" in the
Swedish version of Word. It is called "Rubrik 1", which translates back to
"Heading 1" of course.

In the UK we use many macros that refer to "standard" things like "Heading
1", but these macros fail in Sweden. It looks like we have use
country-specific macros.

I have not been able to confirm this yet, but it looks like objects such as
"TemplateProject" in UK are not called that in Sweden.

Do we need to write country-specific macros, or is there a better way (i.e.
one that involves less work)?

 

[Jay Freedman]

Many of these problems can be worked around by using built-in
enumerations. For example, the built-in styles are represented by the
members of the WdBuiltinStyle enumeration, so "Heading 1" is
ActiveDocument.Styles(wdStyleHeading1). The name to use in a StyleRef
field is then ActiveDocument.Styles(wdStyleHeading1).NameLocal.

In other cases you may have to write functions that return different
values depending on the Application.Language property. Example:

Private Function Hello() As String
Select Case Application.Language
Case msoLanguageIDEnglishUK
Hello = "Hello"
Case msoLanguageIDFrench
Hello = "Bonjour"
Case Else
Hello = "Eh?"
End Select
End Function

--
Regards,
Jay Freedman
Microsoft Word MVP
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

 

[stephenc]

Thanks Jay,
That answers my question exactly

 

[stephenc]

Oh dear - I'm not as clever as I thought I was...

Okay Jay, how do you insert

ActiveDocument.Styles(wdStyleHeading1).NameLocal

into a StyleRef field in a document?

 

[Jay Freedman]

Sorry, I should have made that clearer. You can't insert the code into a
field. You have to use the code in a macro to create or modify the field
with the specific style name needed for the current user of the document. If
the document is passed from one user to another with a different language,
the macro has to run again. That usually indicates that the code should be
in the AutoNew and AutoOpen macros
(http://www.word.mvps.org/FAQs/MacrosVBA/DocumentEvents.htm).

Incidentally, since the question is likely to be asked, "Why can't fields
contain and execute VBA code?" The answer is that it would be an enormous
security risk. Look at all the machinery in Office for trying to prevent
macros from running unless they're digitally signed, stored in a trusted
location, not downloaded from the Internet, etc. Now imagine also having to
examine every document or template for code embedded in fields...

 

[Peter Jamieson]

"Why can't fields

contain and execute VBA code?" The answer is that it would be an enormous
security risk. Look at all the machinery in Office for trying to prevent
macros from running unless they're digitally signed, stored in a trusted
location, not downloaded from the Internet, etc. Now imagine also having to
examine every document or template for code embedded in fields...

If "code in documents" were the real reason for that, it's difficult to
imagine how Excel worksheets could work at all. Even if you decided that
the worksheet function language was not powerful enough to be
"dangerous", I suspect that the facility to reference user-defined VBA
functions from Excel worksheet formulae would have been eliminated a
long time ago

Peter Jamieson

http://tips.pjmsn.me.uk

 

[stephenc]

Thanks Jay!
--
Stephenc

Sorry, I should have made that clearer. You can't insert the code into a
field. You have to use the code in a macro to create or modify the field
with the specific style name needed for the current user of the document. If
the document is passed from one user to another with a different language,
the macro has to run again. That usually indicates that the code should be
in the AutoNew and AutoOpen macros
(http://www.word.mvps.org/FAQs/MacrosVBA/DocumentEvents.htm).

Incidentally, since the question is likely to be asked, "Why can't fields
contain and execute VBA code?" The answer is that it would be an enormous
security risk. Look at all the machinery in Office for trying to prevent
macros from running unless they're digitally signed, stored in a trusted
location, not downloaded from the Internet, etc. Now imagine also having to
examine every document or template for code embedded in fields...



.