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