Share via


Visual Basic Concepts

Writing International Code in Visual Basic

Preparing a product for use in other locales implies more than just translating text messages. The product must support national conventions and provide country-specific support for numbers. In order to know how to work with different dates, currencies, and numeric values and separators, you have to understand the distinction Visual Basic makes between system locale and code locale.

System Locale vs. Code Locale

The system locale is the locale of the user who runs your program — it is used as a reference for user input and output and uses Control Panel settings provided by the operating system. The code locale is always English/U.S. in Visual Basic, regardless of which international version you use. Code locale determines the programming language and all the locale-specific settings.

Date

In Visual Basic, never type dates as strings in your code. Entering dates in code in the format #month/day/year# ensures that the date will be interpreted correctly in any system locale. Because Visual Basic allows only English/U.S. as a programming locale, the date will be the same to a user wherever your application is run.

For example, if a user enters 8/2/97 in an input dialog box,

CDate ("8/2/97")

returns the following results, based on the system locale:

Operating system Output
French/France 08/02/97  (= February 8, 1997)
English/U.S. 8/2/97  (= August 2, 1997)

Conversely, if you enter 8/2/97 in code,

CDate (#8/2/97#)

returns the results in the following table, based on the code locale:

Operating system Output
French/France 02/08/97  (= August 2, 1997)
English/U.S. 8/2/97  (= August 2, 1997)

If the user is in France and enters 8/2/97, the application will interpret this date as February 8, 1997, because the date format in France is day/month/year. If a user in the United States enters the same string, the application will understand August 2, 1997, because the date format is month/day/year.

Currency

Avoid typing currencies as strings in your code. For example, the following code does not run in any locale except those where the dollar sign ($) is the currency symbol.

Money = "$1.22"
NewMoney = CCur(Money)

If you run this code example in the French/France locale, where "F" is the currency symbol, Visual Basic will generate a "Type mismatch" error message, because $ is not recognized as a currency symbol in that locale. Instead, simply use numbers, as shown in the following example. Use a period as a decimal separator, because the code locale for Visual Basic is always English/U.S. The following code will run correctly, regardless of the user's locale.

Money = 1.22
NewMoney = CCur(Money)

Numeric Values and Separators

In the United States, the period (.) is used as the decimal separator. In several European countries, however, the comma (,) is used as the decimal separator. Similarly, in the United States, a comma is used as the thousands separator to isolate groups of three digits to the left of the decimal separator. In several European countries, a period or a space is used for this purpose. The following table lists some examples of different number formats:

Countries Number formats
U.S. 1,234,567.89
1,234.56
.123
France 1 234 567,89
1 234,56
0,123
Italy 1.234.567,89
1.234,56
0,123

Note   In Visual Basic, the Str and Val functions always assume a period is the decimal separator. In a majority of locales, this assumption is not valid. Instead, use the CStr, CDbl, CSng, CInt, and CLng functions to provide international conversions from any other data type to the data type you need. These functions use the system locale to determine the decimal separator.

For More Information   See "Locale-Aware Functions" later in this chapter for more information about the Print and Format functions. See "CStr Function," "CDbl Function," "CSng Function," "CInt Function," "CLng Function," "CDate Function," and "CCur Function" in the Language Reference. See also "Variables, Constants, and Data Types."