Creating or Modifying International Applications

Article
10/23/2006

You can prevent localization problems with code by observing the guidelines described in the following sections.

Testing for International Versions

If it's important for your application to be able to determine what language Visual FoxPro is running in, you can call VERSION( ). Knowing the language environment can help you determine what text to display, how to format data, and so on. For example, the following code determines what language environment Visual FoxPro is running in and then runs a language-specific form:

IF VERSION(3) = 34 THEN
   * Running in Spanish--display Spanish form
   DO FORM CST_SPN.SCX
ELSE
   * Display English form
   DO FORM CST_ENU.SCX
ENDIF

Note Support for double-byte characters strings has been available in Visual FoxPro only since version 3.0b. If your application is relying on the availability of DBCS functions, you should also call the VERSION(1) function to test the Visual FoxPro version number.

Using Strings

Avoid including strings directly in code because they make localization difficult. For instance, don't include dates and currencies as strings in code. If possible, write your code so that it retrieves strings from files or tables separate from the program.

Note The performance of your program might suffer if you remove all strings from it. For example, performance might suffer if the program searches for strings while inside a loop.

One way to work with strings in an application that will be translated is to use string constants throughout the application. You can then define the text for these constants in a separate text file that is referenced from your programs using the #INCLUDE preprocessor directive. For example, instead of embedding the error message "file not found," you can use the constant ERR_FILE_NOT_FOUND. The text for this constant could be in a file called ERR_TEXT.H. A program that uses this technique might look like this:

#INCLUDE ERR_TEXT.H

* processing here

IF ERR THEN
   MESSAGEBOX( ERR_FILE_NOT_FOUND )
ENDIF

When your application is localized, the translator can create a locale-specific version of the error text file and then recompile the application.

Working With Strings in DBCS Environments

Visual FoxPro includes functions for manipulating character expressions containing any combination of single-byte or double-byte characters. By using DBCS string functions you can develop applications without having to write extra code that tests for double-byte characters when counting, locating, inserting, or removing characters in a string.

Most DBCS functions are equivalent to their single-byte counterparts except that they're named with a C suffix to distinguish them. You can use these functions with both single-byte and double-byte data; the DBCS functions return exactly the same value as their single-byte counterparts when single-byte data is passed to them. A few other functions help you work with strings specifically in double-byte environments.

DBCS string functions	Description
AT_C( )	Returns the position of one string within another (case-sensitive), starting at the left.
ATCC( )	Returns the position of one string within another (case-insensitive).
CHRTRANC( )	Replaces characters in a string.
IMESTATUS( )	Toggles double-byte editing in the Browse window.
ISLEADBYTE( )	Tests whether a character is a DBCS character.
LEFTC( )	Returns leftmost characters from a string.
LENC( )	Returns the number of characters in a string.
LIKEC( )	Determines whether two strings match.
RATC( )	Returns the position of one string within another (case-sensitive), starting at the right.
RIGHTC( )	Returns rightmost characters from a string.
STRCONV( )	Converts characters between single-byte and double-byte representations.
STUFFC( )	Replaces characters in a string with another string.
SUBSTRC( )	Returns a substring.

When working with double-byte string functions, remember that the maximum-length limit for variables, names, and so on is effectively cut in half. For more information about Visual FoxPro system capacities, see System Capacities.

Note The Visual FoxPro DBCS functions are not supported in earlier versions of Visual FoxPro, and calling them might cause unpredictable results. If you use any DBCS functions in your application, use VERSION(1) to verify that the Visual FoxPro version is later than version 3.0.

Working with Date, Time, and Currency Formats

To help you format dates, times, and currency to match what your users are accustomed to, you can use a variety of formatting techniques. You can:

Allow Visual FoxPro to use the settings established in the Control Panel.
Specify a language or a specific format in the Visual FoxPro Options dialog box that you want to use.
Format dates, times, and currency information in code.

To set a format for date, times, and currency

From the Tools menu, choose Options, and then click the Regional tab.
To use the settings made with the Windows Control Panel, choose Use system settings.

-or-

Choose a language or format for dates and times and then choose options for formatting currency and numbers. If you choose the format Short or Long for the date format, you cannot specify any further options for the date format, and the settings are read from the Windows Control Panel.
Choose OK to use the options for this session, or Set As Default to make the changes the default settings for this copy of Visual FoxPro.

You can also make these settings using the SET SYSFORMATS and SET DATE commands. As a rule, you would issue this command during the initialization of your application (for example, in the configuration file). The default for SET SYSFORMATS is OFF, so you must explicitly set it to ON when starting your application.

You can establish data validation in individual text boxes by setting the Format property of the text box. However, because text box formatting takes precedence over system-wide formatting, this can make it more difficult to localize your application to an environment that uses a different format for dates, currency, and so on.

Using Preprocessor Directives

You can create application variants for different locales by using preprocessor directives. These control compilation of code in the application and include the #INCLUDE, #DEFINE, #UNDEF, and #IF...#ENDIF constructs.

Using preprocessor directives can produce variants quickly; however, such directives have the following drawbacks:

To use preprocessor directives, you bracket code, and extensive bracketing can increase the code's complexity.
Compile-time constants are available only in the program that creates them.

Share via