CLRL(nn|*END)

Category
Screen Building
Additional information
CLRL records are supported as overlapping layers on the screen with opaque backgrounds by default. Although this is non-standard behaviour, it should be satisfactory in a browser environment. The background color of the CLRL layers will be the same as the background color of your selected style. You must use a style with an opaque background color otherwise the text in underlying records will show through and may be displayed in the same location as data from the overlapping layer. If you want to change the default layer background, you can update the wf_layer style class in the apparea.css file under the /WebContent/webfacing/styles/apparea directory.

It is possible with output-only CLRL records to occupy lines above and below the records that the application is expecting input from. This will not work in WebFacing because the entire CLRL record will be made opaque and the overlapped portions of the records below will not be visible and cannot be clicked on. The circumvention for this unsupported scenario is to split the output-only CLRL record into two records containing the fields above and below the input record respectively.

The CLRL keyword is not yet supported for record formats with the WINDOW keyword and will be ignored.

Window Simulation with CLRL: If the CLRL(*NO) or CLRL(nn) keywords are used to implement a window-like record in DDS, WebFacing will attempt to construct a window for that record format to support this common usage. For CLRL(nn), nn must be less than the record length for it to be recognized as a window.

In order for a record to be recognized as a window it must not have any fields outside of the rectangular area intended to be the window. A work-around for developers that have defined function key labels (or other nonessential constants) outside the window area, is to hide these fields using Web Settings. WebFacing will respect these Web Settings and detect the rectangle properly.

The CLRL window recognition algorithm is based on commonly used CLRL window patterns. The following rules, for the top and side borders of the simulated window must be true for the detection to succeed:

  1. For the top border, WebFacing checks for a constant field or an output field occupying the space from (first row, first column) to (first row, last column) and uses it as the window title. If a constant field is used, and the same character is used repeatedly from (first row, first column+1) to (first row, last column-1), the characters used to form the top border will not be used as a title and will simply be removed.
  2. For the side borders, WebFacing checks for a constant field from the record's second row to the second last row. The same string must be used for the left and right border for the simulated window. If this is true, the strings used to form the side borders will be removed.

Note: The bottom border of the simulated window will not be altered because this row is sometimes used to display message information.

The following 5250 behavior is not intuitive and will not be emulated: A CLRL record with no input-capable field does not occupy space on the display. If a CLRL(*ALL) record with no input-capable fields is written, the screen is cleared first and then the record is displayed. However, records that were on the screen before are not removed from the Active Record Table and will be used for OVERLAY checking later. If an OVERLAY record is written, it will first check if records in the Active Record Table are overlapped. If so then those records are removed from the Active Record Table and lines from those records are cleared from the display before the OVERLAY record is written to the display. The above rule also applies to CLRL(nn|*END|*NO). WebFacing deviates from this behaviour by only considering records that are on the display when doing overlap checking. Records that are in the Active Record Table but are not on the display are not considered.


Feedback