7.99.1 POP_UP Parameters

ACROSS_SEP

ADD_KEY

AT_LOC

BROWSELIST

CHANGE_KEY

CURSOR_LOC

DELETE_KEY

DESIGN

DOWN_SEP

EXIT_KEY

FIELDS

IDENT_ATR

IDENTIFY

IGCCNV_KEY

MENU_KEY

PANEL_ID

PANEL_TITL

PROMPT_KEY

STD_HEAD

TEXT

USER_KEYS

WITH_SIZE

Specifies either the field(s) that are to be displayed in the pop up window or the name of a group that specifies the field(s). Alternatively, an expandable group expression can be entered in this parameter.

Specifies the design/positioning method which should be used for fields that do not have specific positioning attributes associated with them.

...

Note: The default value of this parameter is different to the equivalent default used on DISPLAY or REQUEST commands.

Specifies the default identification method to be used for fields that do not have specific identification attributes associated with them.

...

Note: The default value of this parameter is different to the equivalent default used on DISPLAY or REQUEST commands.

Specifies display attributes that are to be associated with identification text (labels, column headings, descriptions, etc) that are displayed in the window.

...

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/Warnings 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/Warnings section for details of what value *DESIGN is actually specifying.

Specifies the position of the window on the screen panel. It may be entered as a special value that automatically specifies the row and column number according to the table below, or as actual row and column numbers. Values specified are fixed and cannot be varied at execution time. The special values and the actual row and column numbers used are as follows:

Specifies the size (ie: width and length) of the window. It may be entered as a special value *AUTO that automatically computes a width and length, or as actual width and length values.

...

When the AT_LOC parameter is one of the following special values, the WITH_SIZE parameter is automatically computed according to the following table, regardless of what value you specify for the parameter.

If you specify a specific row and column value for the AT_LOC parameter, and leave the WITH_SIZE parameter as *AUTO, the width and length values will be automatically calculated to fill the entire screen panel to the right of and to the bottom of the nominated locating row and column number.

...

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.specified.

Specifies the title that is to be assigned to the window panel.

...

This parameter is valid for SAA/CUA and non-SAA/CUA applications.

Specifies the name of a browse list which is also to be included into the window.

...

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.

          EXIT_KEY(*YES *EXIT *HIGH)  in a "main program"
          EXIT_KEY(*YES *RETURN *LOW)  in "subroutines"

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.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.

...

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 usage consider the following:

   POP_UP FIELDS(#PRODUCT) USER_KEYS((14 'Commit')(15 'Purge'))

...

      IF_KEY  WAS(*USERKEY1)

    << Commit logic >>

   ENDIF

...

       << Commit logic >>
      ENDIF
      IF_KEY  WAS(*USERKEY2)

    << Purge logic >>

...

       << Purge logic >>
      ENDIF

Note that 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.

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.

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 where the cursor was located when the command completed execution will be returned in them.

This 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)
   POP_UP  FIELDS(#FIELD1 .. #FIELD10) CURSOR_LOC(#ROW #COL)

When the POP_UP 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 POP_UP command completed execution.

Specifies whether or not the standard LANSA design for the screen heading lines (lines 1 and 2) should be used.

...

*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.

Controls the appearance of the text "Fnn=XXXXXX" in the function key area, of the function key assigned to support IGC conversion.

...

The final option allows the nomination of a condition previously defined by a DEF_COND command. If the condition is true the text should appear. If the condition is false, the text should not appear.