VI. USER-INTERACTION INCOMPATIBILITIES CAUSED BY ENHANCEMENTS TO DHCP FILEMAN

A. INPUT TEMPLATES

'REQ' Fields in DHCP Input Templates

A DHCP Input Template is allowed to include ";REQ" Specifiers on individual Fields.

The purpose of such a Specifier is that, when the user runs the (scrolling) Input Template, he is "required" to enter data for such Fields that have empty values, just as though those Fields had been designed as "MANDATORY" in the Data Dictionary. CHCS FileMan Input Templates do not recognize this Specifier, and therefore do not support this functionality, which could be very significant in the design of a particular application.

Portability Effect: SERIOUS Any Input Template ported from a DHCP environment to a CHCS environment needs to be examined for occurences of the ";REQ" Specifier, since it must be assumed that a developer who has explicitly added this Specifier must have a reason for doing so. Accomplishing the equivalent functionality under CHCS FileMan is not as simple as making the Field "Required in the Database"! A general workaround for this incompatibility is not apparent.

'DUP' Fields in DHCP Input Templates

A DHCP Input Template is allowed to include ";DUP" Specifiers on individual Fields. The purpose of such a Specifier is that, when the user runs the (scrolling) Input Template, the 'previous answer' to such a 'DUP'-specified Field will be 'remembered', and can be retrieved by the user just by typing a space character.

Of course, Pointer-valued Fields in both FileMan systems have always had the "space-bar" input feature, by virtue of the way the general "^DIC" lookup program works. CHCS FileMan, however, does not have the general ";DUP" feature.

Portability Effect: Minor. A DHCP Application could easily contain an Input Template that included a ";DUP" specification on one or more of its Fields. Such a specification would be ignored by CHCS FileMan, and the user of that system would not (if he knew about the feature) be allowed to retrieve a 'previous answer' just by hitting the space bar. Of course, the CHCS user might become more than a little frustrated if the DHCP developer had somehow included with the Template a user-visible message to the effect that the space-bar could be used!

B. MISCELLANEOUS USER-INTERACTION DISCREPANCIES CAUSED BY DHCP ENHANCEMENTS

Lookup doesn't generally stop at exact match

This is one of the most recurrently-troubling user-interaction differences between CHCS and DHCP FileMan. "Recurrent", because of course the FileMan lookup module is used everywhere within the system. "Troubling", because the difference in behavior is so obvious to the user.

If a File, for example, contains two Entries, named "SUSAN" and "SUSANNA", and the user makes a "partial" answer:

Select Entry: SUSA

then, in both systems, he will see the two matching Entry names displayed, and be asked to choose which one he wants. If, however, he knows the full, exact spelling of the Entry he wants, and tries to

Select Entry: SUSAN

VA FileMan will not generally accept the input "SUSAN" as an exact spelling of one of the Entry names, but will echo back

1 SUSAN

2 SUSANNA

Choose 1 or 2:

CHCS FileMan, by contrast, will straightforwardly assume "SUSAN" as the selection.

Portability Effect: Uncertain. One wants to call this a "cosmetic" difference between the two systems (on the user level), but personal experience indicates that this is a discrepancy in behavior that continues to jar the user who interacts with both systems. In Section VIII, below, we will point out a potentially "Serious" aspect of this discrepancy, from a programming perspective: some calls to the "^DIC" lookup module may rely on exact matches being made.

Aborting output by typing '^'

When any kind of FileMan report (including a Data Dictionary listing) is displayed on a video terminal with keyboard, VA FileMan allows the user who reads the report to type a "^" character at the end of any display page, thereby aborting the report. CHCS FileMan (Version 25) only allows this kind of report-termination to be done through an implementation-specific feature (i.e., typing CONTROL-C at any moment during the display).

Portability Effect: Minor. User-training only.

'CAPTIONED' output can show Computed Fields

In using the 'Inquire' option, the DHCP user of 'STANDARD CAPTIONED OUTPUT' is asked whether he wants to see COMPUTED FIELDS in the Display. At the cost of always being asked an extra question in this 'easy-to-use' option, the user is thus given more flexibility. If, however, the user has no knowledge of the current File's Data Dictionary setup, the question is merely awkward, because the naive user doesn't know whether Computed fields exist in the File.

Portability Effect: Minor. User-training only.

'Uneditable' Fields don't display and pause

In DHCP scroll-mode editing of a Field that has been designated 'UNEDITABLE', if the Field already has a value for a particular Entry, then the user sees something different than the CHCS user: In DHCP FileMan, the uneditable data is simply shown to the user along with a "(No Editing)" message, and the user does not need to hit 'RETURN' (as in CHCS) in order to pass the Field.

Portability Effect: Minor. User-training only.