Coding issues

This section addresses common coding issues to consider as you’re completing initial development. By planning your development carefully, you’ll be able to write scripts for your application that will require minimal adaptation for international markets and allow you to shorten development time for those additional markets.

String-related issues

String-related coding issues typically arise when translating an application into another language in the process of localization. By following the guidelines listed here, you will minimize the amount of additional effort required to localize your application.

Hard-coded strings can’t be transferred to a text file for translation, like string and message resources can be. To translate hard-coded strings, you’ll need to examine the source code for each of your scripts, translate the appropriate messages and recompile them – a time-consuming and error-prone process. It’s best to use message resources for strings that will appear in a window or on a report.

Dexterity will display compiler warnings every time you use a hard-coded string in a script.

When using message resources, don’t concatenate messages together to form new messages. Instead, create a complete message for each unique message that will be used in your application.

Using strings or messages to set values in scripts may result in string overflow errors if the translated strings and messages are longer than the original resources. For example, if you have the following script statement and the value of message 1000 is translated to a word that contains 12 characters, a string overflow error will result.

'Transaction Source' = getmsg(1000);
	{where Transaction Source is a string 10}

You can avoid string overflow errors by storing the integer value of the message, rather than the message resource itself, as shown in the following example.

'Transaction Source' = 1000;
	{Transaction Source is an integer}

In this example, when you display the transaction source in a window or print it on a report, you’d need to use local or calculated fields to retrieve and print the value of the message, rather than the integer value that’s stored in the table.

If you create an international version of your application, keep in mind that all messages resources will be translated to the target language. To prevent potential problems, don’t store the content of message resources in tables. After messages are translated, the data previously stored in tables won’t be compatible with the translated version.

If you must store constant string values in tables, create constants for the values that will be stored. Constants are not translated when creating an international version of an application.

In some cases, it’s necessary to use hard-coded strings in a script. When you compile scripts that contain hard-coded strings, Dexterity will produce compiler warnings. For situations where you must use hard-coded strings, these compiler warnings don’t provide any benefit. You can use a pragma to turn them off within a specific script.

For example, the following script contains a pragma to turn off compiler warnings for hard-coded strings. Notice that after the hard-coded string is used, the warning for hard-coded strings are turned back on.

pragma(disable warning LiteralStringUsed);
set 'Mode' to "Internal";
pragma(enable warning LiteralStringUsed);

If a script contains many hard-coded strings, you may want to use a pragma at the beginning of the script to turn off the literal string warnings, and then turn them back on at the end of the script.

If you need to use physical names or technical names in your scripts, such as for pass-through SQL, don’t hard-code them. Instead, use the physicalname() and technicalname() functions to retrieve names within a script.

Currency and date issues

In many cases, currency and date formats will be handled seamlessly by the Dexterity system, provided your application uses the operating system’s control panel settings.

The Dexterity system allows you to specify the number of decimal places for currency data types. For international use, your customers may want to use the default control panel settings instead.

When you’re placing date fields in a window or report layout, be sure to allow room for international date formats. If you’ve used a short date format, a portion may be truncated when it’s converted to a long date. For example, if you use a date format that includes only the last two numbers of the century, allow extra space when converting it to a format that includes the entire century.

If your application will support multicurrency transactions, you will have to add this capability to your application. Typically, your application will use a functional currency and then use exchange rates for the other currencies you’re supporting. To help you implement multicurrency functionality in your applications, Dexterity provides the following tools:

The Currency function library allows you to define your own custom currency formats. Refer to the currency function library in the Dexterity Script Reference manual or the Dexterity online help for more information about these functions.

The Multiple Format Selector allows you to apply custom currency formats to window fields and report fields. Refer to Formats for more information about the Multiple Format Selector.

Dexterity doesn’t provide built-in support for the following multicurrency features; you will need to add them to your application if you wish to support them.

Documentation Feedback