| Application Development | |
This chapter describes features of hardware and operating system software that can cause Panther to behave in a non-uniform fashion. If you want to create and write programs that run across a variety of systems, you need to be aware of these factors.
Panther Header Definitions |  |
The header files smmach.h and smcommon.h contain information that library functions need in order to deal with certain machine, operating system, and compiler dependencies. These include:
The header files are thoroughly commented. Follow the directions in the file and use the information that applies to your machine and operating system.
Terminal Dependencies | |
Some general differences among terminals are described in this section. Recommendations and considerations are included to help ensure that your application can be ported to terminals that differ from your development environment.
Panther can run on display terminals of any size. On character-based terminals without a separately addressable status line, Panther uses the bottom line of the display—typically, line 24—for a status line, and status messages overlay that line's contents. To ensure enough room for status line and screen displays, design for an average screen size of 23 lines by 80 columns, including the border.
Different terminals support different sets of attributes. Panther makes sensible compromises based on the attributes available. However, do not design programs that rely extensively on attribute manipulation to highlight data, which might not be evident on terminals with an insufficient number of attributes. For example, colors do not display on monochrome terminals. On the other hand, consider designating the appropriate color combinations in the event that your application is ported to terminals that support color. Also, use of graphics character sets is especially terminal-dependent.
Attribute handling can also affect the spacing of fields and text. In particular, if you design screens to run on terminals with onscreen attributes, leave space between fields, highlighted text, and reverse video borders for the attributes. Some terminals with area attributes also limit the number of attribute changes permitted per line or per screen.
Use color aliases to ensure cross-GUI color compatibility.
The key translation table mechanism supports the assignment of any key or key sequence to a particular logical character. However, if you make excessive use of function keys for program control, the number and labelling of function keys on particular keyboards can cause constraint. For instance, the standard VT100 has only four function keys. In this case, consider using menus rather than function keys to implement choice among alternatives.
Use key labels in your key translation file instead of hard-coded key names. This helps ensure portability to a variety of terminals. With the %K escape, the key labels can be automatically inserted in field status text and other status line messages. To include the key name in a field, use sm_keylabel to return a printable name of the logical key.
Language Dependencies | |
To a large extent, Panther depends on the operating system to handle discrepancies between different languages and their character sets. The following sections discuss some of the system-related factors that you might need to account for when preparing an application for different languages.
You can also support different languages by modifying Panther' message file. (See "Using Message Files.") For strategies to translate screens into different languages, refer to "Translating Screens in Application Programs."
Panther evaluates user input only when a widget's keystroke_filter property is set to any value other than PV_UNFILTERED: A keystroke filter restricts user input—for example, to digits only, yes/no, or to conform with an edit mask or regular expression. To validate data as it is entered, Panther uses standard C macros, such as isdigit and isalpha. Panther relies on the operating system to supply these macros in a form suitable for international use. Absent operating system support, care should be taken when using these capabilities.
Panther uses its own code to process numeric entry because C does not provide an macro to evaluate real numbers. If the widget has its decimal_symbol property set, Panther uses it to evaluate numeric input.; otherwise, Panther uses the decimal symbol that is set in the message file or derived from the operating system.
Widgets that are restricted to yes/no entry use the characters that are specified by the message file's SM_YES and SM_YES entries. (See "Setting Yes/No Values.") Although some vendors supply information about these characters, the ANSI standard leaves the issue unresolved. Therefore, Panther relies on the message file to evaluate this data.
If the keystroke filter specifies a regular expression (keystroke_filter = PV_REGULAR_EXP), Panther uses the ASCII collating sequence to validate ranges of characters. Therefore, this expression matches only English lower-case letters:
[a-z]*
The European character ä, for example, is not matched by this expression.
Widgets that have their convert_case property set to PV_UPPER or PV_LOWER depend on the toupper and tolower functions. The present code assumes that the return from toupper is appropriate for conversion to upper case. A lower case letter that has no upper case equivalent—for example, the German "double s"—remains in lower case.
Range checks for numeric data are handled by the C library routine at of (assuming that the "strip" routine works properly).
Collating sequences can vary among different languages. This is especially true for dictionary or telephone book processing. For example, upper- and lower-case letters are compared equally. Also, a telephone book evaluates St. and Saint as equal and ignores hyphens. Some languages can pose problems even for less demanding applications. For example, ligatures compare equally to pairs of letters. The placement of vowels with diacritical marks varies widely even among countries using the same language.
The ANSI standard specifies the routine strcoll to expand a word into a format that strcmp can use for comparisons. These routines assume that the data supplied is a word in the local language. They can yield unexpected results on non-language data.
Panther is not designed to process languages in a way that involves such fine distinctions. It does sort names of fields and other objects, but only to speed look-up. As long as the sort routine and the search routine use the same algorithm, things will work.
In Panther, range checks can be applied to non-language data. For example a menu selection might have a range of a to d. In certain languages an umlaut falls into that range if a language-specific comparison is made. In cases like these, you might need to create different screens for each language.
The C routines strcmp and memcmp are used to range check on non-language data. These routines compare the internal values of the characters, without regard to their actual meaning.