Guidelines, Hints and Tips
- It is highly recommended that the IBM publication "Common User Access: Guide to User Interface Design" be reviewed before attempting to implement GUI WIMP constructs.
- Before you start utilizing the new contsructs you should first familiarize yourself with them. Write a few pilot functions and experiment with the constructs, to ensure that they operate in the fashion that you require.
- GUI WIMP constructs cannot be defined on fields used in browse lists.
- Due to the graphical representation on PC displays, push buttons must be separated from other information by a blank line.
- Because of the implementation of radio buttons on NPT's their use on NPT's is discouraged.
- It is recommended that if more than 50 entries are needed for a drop-down list than an alternative method should be considered (i.e., POP_UP, Prompt etc). Large numbers of entries in a drop-down make the list cumbersome and hard to use, opposing the main reason for their use.
- The choices in a radio button group should be formatted in one of two ways: vertically in a left-aligned column, or horizontally on the same line. An imaginary rectangle encompassing the radio button group must not contain any other fields, or portability to other platforms will be affected.
- There are two methods of implementing a drop-down list. One is where the valid field codes are loaded into a drop-down list, then the user selects a code. This method can be confusing when the codes are not well known.
For example #PAYTERM is a field that contains the payment terms for a customer. Its valid values are A, B, C, D and E, but without any description the user could be confused as to there meaning and select the wrong code.
DEFINE FIELD(#PAYTERM) TYPE(*CHAR) LENGTH(1)
INPUT_ATR(DDPT)
USE BUILTIN(DROP_DD_VALUES) WITH_ARGS(DDPT)
USE BUILTIN(ADD_DD_VALUES) WITH_ARGS(DDPT '''/'''
'A/B/C/D/E') TO_GET(#RETCD)
BEGIN_LOOP
REQUEST FIELDS((#PAYTERM))
END_LOOP
A better solution would be to load the valid field codes and descriptions into the drop-down list using a different field. The code field then overlays the new field in the position that the code appears. So when the entry in the drop-down list is selected the code field is automatically updated with the code from the drop-down entry because of the overlay.
DEFINE FIELD(#PAYDROP) TYPE(*CHAR) LENGTH(24)
INPUT_ATR(DDPT)
DEFINE FIELD(#PAYTERM) TYPE(*CHAR) LENGTH(1)
TO_OVERLAY(#PAYDROP 1 )
USE BUILTIN(DROP_DD_VALUES) WITH_ARGS(DDPT)
USE BUILTIN(ADD_DD_VALUES) WITH_ARGS(DDPT *DFT
'A - PAYMENT WITH ORDER') TO_GET(#RETCD)
USE BUILTIN(ADD_DD_VALUES) WITH_ARGS(DDPT *DFT
'B - CASH ON DELIVERY') TO_GET(#RETCD)
USE BUILTIN(ADD_DD_VALUES) WITH_ARGS(DDST *DFT
'C - 7 DAYS') TO_GET(#RETCD)
USE BUILTIN(ADD_DD_VALUES) WITH_ARGS(DDST *DFT
'D - 30 DAYS') TO_GET(#RETCD)
USE BUILTIN(ADD_DD_VALUES) WITH_ARGS(DDST *DFT
'E - UNLIMITED') TO_GET(#RETCD)
BEGIN_LOOP
REQUEST FIELDS((#PAYDROP))
END_LOOP