• 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 their 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