Access Cookbook - Ken Getz [95]
lngLanguage = acbAccessLanguage( )
You can then pass that variable to procedures in your application that make decisions based on the current language version of Access.
In the example application, the language ID is stored in an option group, which will work only if you are supporting a known, limited set of languages. The example also includes code that detects the version of Access in use and whether it is a runtime version.
Discussion
Retrieving language information requires setting a reference to the Microsoft Office Object Library. You can then refer to the Application object's LanguageSettings property to retrieve the language being used. Each language has its own LanguageID property, which is an integer value. These language IDs are represented by enumerated constants. When you set a reference to the Microsoft Office Object Library, you can see a complete list of constants by examining the msoLanguageID enumeration, as shown in Figure 4-11.
Figure 4-11. Each language value has a corresponding constant
The call to acbAccessLanguage requires a simple variable:
lngRetval = acb_apiGetLanguage( )
Or you can use a control, as we have in the example:
Me.grpLanguage = acbAccessLanguage( )
The function returns a single value, which tells you which language version the function found. Table 4-1 lists only a few of the Windows languages and the ID values associated with them, along with the corresponding constants. You can see a complete list by using the Object Browser, as shown in Figure 4-11.
Table 4-1. Windows languages and ID values
Language
Constant
ID
American English
msoLanguageIDEnglishUS
1033
French
msoLanguageIDFrench
1036
German
msoLanguageIDGerman
1031
Italian
msoLanguageIDItalian
1040
Russian
msoLanguageIDRussian
1049
Spanish
msoLanguageIDSpanish
1034
Portuguese
msoLanguageIDPortuguese
2070
Swedish
msoLanguageIDSwedish
1053
Zulu
msoLanguageIDZulu
1077
The simple function in basFileLanguage, acbAccessLanguage, returns only the national language ID number (from Table 4-1) for the installed version of Access:
Function acbAccessLanguage( ) As Long
acbAccessLanguage = _
Application.LanguageSettings.LanguageID(msoLanguageIDUI)
End Function
Once you know the ID for the national language, you can make choices in your application. For example, as shown in the next two solutions, you can modify labels on forms and reports and modify the error messages that you display.
The example form also uses two functions from basAccessInfo in 04-05.MDB, acbGetVersion and acbIsRuntime. Both are quite simple, comprising only calls to the built-in SysCmd function. The first, acbGetVersion, returns the version number of the currently running copy of Access. The second, acbIsRuntime, returns True if your application is running in the runtime version of Access or False if it's in the retail version. You may find these functions useful if your application needs to react differently to different environments.
Public Function acbGetVersion( ) As String
' Retrieve the Access version for places
' that can't use symbolic constants.
acbGetVersion = SysCmd(acSysCmdAccessVer)
End Function
Public Function acbIsRuntime( ) As Boolean
' Use SysCmd( ) to gather the information.
acbIsRuntime = SysCmd(acSysCmdRuntime)
End Function
4.6. Internationalize Text in Your Applications
Problem
You'd like to be able to pop up translated error messages in your applications, based on the currently running language version of Access. You'd also like other text on your forms and reports to adjust automatically based on the current language version. You know there are a number of ways to do this, but you can't decide which is best. How should you store and retrieve messages in multiple languages?
Solution
The translated version