Page History
7.36.1 DISPLAY Parameters
|
|---|
Specifies either the field(s) that are to be displayed at the workstation or the name of a group that specifies the field(s) to be displayed. Alternatively, an expandable group expression can be entered in this parameter.
Portability Considerations | Visual LANSA has multi-page and field-spanning line restrictions: Multi-page data (i.e. if the screen format is larger than one page) can be displayed in a Web browser window but NOT in a LANSA function. Field spanning (i.e. when the field is larger than one line on the screen) is not supported - only a single line will be displayed. No error or warning is issued. |
|
|---|
Specifies the design/positioning method which should be used for fields that do not have specific positioning attributes associated with them.
*IDENTIFY, which is the default value, indicates that the design method should be the default method associated with the IDENTIFY parameter. Refer to the table in the Comments section for more details.
*DOWN indicates that the fields should be designed "down" the screen in a column.
*ACROSS indicates that fields should be designed "across" the screen in a row.
|
|---|
Specifies the default identification method to be used for fields that do not have a specific identification attribute associated with them.
*DESIGN, which is the default value, indicates that the fields should be identified by the default method associated with the DESIGN parameter. See the table in the comments section for more details.
*LABEL indicates that fields should be identified by their associated labels on the screen.
*DESC indicates that fields should be identified by their associated descriptions on the screen.
*COLHDG indicates that fields should be identified by their associated column headings on the screen.
*NOID indicates that no identification of the field is required. Only the field itself should be included into the screen design.
|
|---|
Specifies display attributes that are to be associated with identification text (labels, descriptions, column headings, etc) that are displayed on the screen.
*DEFAULT, which is the default value, indicates that the system defaults for identification display attributes should be adopted. They are set up in the system definition block as overall system default values. Refer to The System Definition Data Areas in the LANSA for i User Guide and how to change it.
*NONE indicates that identification text should have no special display attributes associated with it.
Otherwise, specify one or more of the values: *HI (high intensity), *RI (reverse image) and *UL (underline).
This parameter is ignored in SAA/CUA processes in SAA/CUA compliant partitions. In such partitions, the attributes are determined from the partition-wide standards for labels and column headings.
|
|---|
Specifies the spacing between rows on the display that should be used when automatically designing a screen. The value specified must be *DESIGN or a number in the range 1 to 10. Refer to the table in the Comments section for details of what value *DESIGN is actually specifying.
|
|---|
Specifies the spacing between columns on the display that should be used when automatically designing a screen. The value specified must be *DESIGN or a number in the range 1 to 10. Refer to the table in the Comments section for details of what value *DESIGN is actually specifying.
|
|---|
Specifies the name of a browse list which is also to be included into the screen format, and optionally, the number of entries of the browse list that should appear in the screen panel.
*NONE indicates that no browse list is required. The screen designed will not have any browse component.
If a browse list is specified, then you may also specify the number of entries from the browse list that are to appear on the screen panel. This may leave space below the browse list for other details (which can be overlaid by a subsequent screen). The default of 999 entries indicates that the browse list should extend to the logical bottom of the screen panel.
If a browse list is specified it must be defined elsewhere in the RDML program with a DEF_LIST (define list) command.
|
|---|
Specifies the following things about the EXIT function key:
...
If a condition name is specified it must be defined within the RDML program by a DEF_COND (define condition) command.
| Note | |||
|---|---|---|---|
| title | Note | : In SAA/CUA applications it is recommended that only the following 2 variations of the EXIT_KEY parameter are used: Code Block | EXIT_KEY(*YES *EXIT *HIGH) in a "main program"*
|
|
|---|
Specifies whether the MENU function key is to be enabled when this screen format is displayed at the workstation. In addition, it also specifies what is to happen if the MENU key is used.
...
If a condition name is specified it must be defined within the RDML program by a DEF_COND (define condition) command.
|
|---|
Specifies whether the ADD function key is to be enabled when this screen format is displayed at the workstation. In addition it also specifies what is to happen if the ADD key is used.
...
If a condition name is specified it must be defined within the RDML program by a DEF_COND (define condition) command.
|
|---|
Specifies whether the CHANGE function key is to be enabled when this screen format is displayed at the workstation. In addition it also specifies what is to happen if the CHANGE key is used.
...
If a condition name is specified it must be defined within the RDML program by a DEF_COND (define condition) command.
|
|---|
Specifies whether the DELETE function key is to be enabled when this screen format is displayed at the workstation. In addition it also specifies what is to happen if the DELETE key is used.
...
If a condition name is specified it must be defined within the RDML program by a DEF_COND (define condition) command.
|
|---|
Specifies whether the PROMPT function key is to be enabled when this screen format is displayed at the workstation. In addition it also specifies what is to happen if the PROMPT key is used.
*DFT, which is the default value, indicates that the PROMPT function key should be enabled or disabled automatically according to its default value defined in the system definition data area DC@A01. Refer System Definition Data Area DC@A01 in the LANSA for i User Guide for more information about this default value.
...
*AUTO indicates that the prompt key processing should be handled automatically by LANSA. Before attempting to use this option, refer to Prompt Key Processing.
*NEXT indicates that control should be passed to the next command.
...
If a condition name is specified it must be defined within the RDML program by a DEF_COND (define condition) command.
|
|---|
Specifies up to 5 additional user function keys that can be enabled when the screen format is displayed at the workstation.
...
As an example of use consider the following:
...
DISPLAY FIELDS(#PRODUCT) USER_KEYS((14 'Commit')(15 'Purge'))
...
IF_KEY WAS(*USERKEY1)
...
* << Commit logic >>
...
ENDIF
IF_KEY WAS(*USERKEY2)
...
* << Purge logic >>
...
ENDIF
| Note | |
|---|---|
| Note | : The IF_KEY command refers to the keys by symbolic names that indicate the order they are declared in the USER_KEYS parameter, not the actual function key numbers assigned to them. This makes changing function key assignments easier. |
|
|---|
Specifies the identifier that is to be assigned to the panel or pop-up window created by this command.
...
This parameter is ignored if the current partition definition indicates that panel identifiers are never required, no matter what value is specified.
|
|---|
Specifies the title that is to be assigned to the window panel.
...
This parameter is valid for SAA/CUA applications only..
|
|---|
Specifies whether the "next function" field should be shown on line 22 of the screen. The next function field is a facility that allows transfer between the functions in a process without the need to return to the process menu each time. Refer to the section that describes the The Function Control Table in the LANSA for i User Guide for more details about "next function" processing.
...
*NO indicates that the next function field should not appear regardless of what menu selection style is being used by the process to which this function belongs.
| Note | ||
|---|---|---|
| title | Note | : The SHOW_NEXT parameter is ignored in SAA/CUA applications. |
Portability Considerations | Ignored in Visual LANSA applications with no known effect on the application. |
|
|---|
Allows the specification of up to 50 "text strings" that are to appear on the screen panel or report. Each text string specified is restricted to a maximum length of 20 characters.
When a text string is specified it should be followed by a row/line number and a column/position number that indicates where it should appear on the screen panel or report.
For example:
...
TEXT(('ACME' 6 2)('ENGINEERING' 7 2))
specifies 2 text strings to appear at line 6, position 2 and line 7, position 2 respectively.
Portability Considerations | In Visual LANSA this parameter should only be edited using the screen or report painter which will replace any text with a text map. DO NOT enter text using the command prompt or free format editor as it will not pass the full function checker if checked in to LANSA for i. |
All Platforms
The text map is used by the screen or report design facilities to store the details of all the text strings associated with the screen panel or report lines.
...
The presence of a text map is indicated by a TEXT parameter that looks like this example:
...
TEXT((*TMAPnnn 1 1))
where "nnn" is a unique number (within this function) that identifies the stored text map.
...
Never specify *TMAPnnn identifiers of your own or change *TMAPnnn identifiers to other values. Leave the assignment and management of *TMAPnnn identifiers to the screen and report design facilities.
When copying a command that has an *TMAPnnn identifier, remove the *TMAPnnn references (ie: the whole TEXT parameter) from the copied command. If you fail to do this, then the full function checker will detect the duplicated use of *TMAPnnn identifiers, and issue a fatal error message before any loss occurs.
Never remove an *TMAPnnn identifier from a command. If this is done then the associated text map may be deleted, or reused in another command, during a full function check or compilation. Loss of text details is likely to result.
Never "comment out" a command that contains a valid *TMAPnnn identifier. This is just another variation of the preceding warning and it runs the same risks of loss or reuse of text.
Never specify *TMAPnnn values in an Application Template. In the template context *TMAPnnn values have no meaning. Use the "text string" format in commands used in, and initially generated by, Application Templates.
|
|---|
Specifies any user-controlled cursor positioning that is required. The CURSOR_LOC parameter must always contain 2 values which may take any of the following forms:
...
When the row and column option is used and the row and column values are specified as fields (rather than numeric literals), the row and column number that the cursor was at when the command completed execution will be returned in them.
| Note | ||
|---|---|---|
| title | Note | : The CURSOR_LOC does not behave in the same way on Windows as on IBM i. On a Windows platform, the value retrieved is the first position of the field the cursor is currently in. |
The feature is a useful way of retrieving the location of the screen cursor at the time the command completed execution. In cases where you wish to retrieve the cursor location, but do not want to specify it before output to the screen, use coding like this:
...
CHANGE FIELD(#ROW #COL) TO(0)
...
DISPLAY FIELDS(#FIELD1 .. #FIELD10) CURSOR_LOC(#ROW #COL)
When the DISPLAY command is executed #ROW and #COL are both zero, which is an invalid cursor location. In such cases normal LANSA cursor control is resumed and the user positioning request is ignored. However, after completion of the command fields #ROW and #COL will contain the location of the cursor at the time the DISPLAY command completed execution.
|
|---|
Specifies whether or not the standard LANSA design for the screen heading lines (lines 1 and 2) should be used.
*DFT, which is the default value, indicates that the system default value for the STD_HEAD parameter should be used. The system default value is stored in the LANSA system definition block. Refer to The System Definition Data Areas in the LANSA for i User Guide for more details of the system definition block and how to change it.
...
*NO indicates that the standard LANSA screen heading lines should not be used. In this case lines 1 and 2 of the display can be used to position user fields.
|
|---|
Specifies special display options for this screen panel.
...
If either the *NOREAD or *OVERLAY options are used, the complete screen details must fit on one screen panel.
| Note | |
|---|---|
| Note | : These display options have been provided to allow emulation of IBM i 3GL programs, and will not be portable to other platforms. They are not supported by the current GUI. Use of these options is therefore not recommended. |
Portability Considerations | This parameter is not supported in Visual LANSA applications and should not be used. If used, a Full Function Check fatal error will be issued. |
|
|---|
Controls the appearance of the text "Fnn=XXXXXX" in the function key area, of the function key assigned to support IGC conversion.
...