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."