On 06/09/2008, at 3:27 AM, Frances Denoncourt wrote:
My other issue is that the first footer is still displaying in
places along with the second.
Then the screen area occupied by the first footer is not being
cleared when the second footer is displayed. This is termed "bleed-
through". It's usually caused by PUTOVR plus OVRATR and/or OVRDTA or
CLRL(*NO)
OVERLAY is used to build a single screen from multiple record
formats. The default behaviour is to clear the screen for each record
format written. If you want multiple formats on the display you
generally use OVERLAY. Each record format must NOT share any screen
space with other active record formats. If a format with OVERLAY
specified is written to the display AND it shares even one character
position with another record format already on the display the record
format already displayed is erased. Record formats that share screen
space do not OVERLAY they OVERLAP.
If you need to OVERLAP record formats then the OVERLAY will not help.
You must use CLRL(*NO) to stop the OS from erasing the overlapped
record format, or you must use PUTOVR plus OVRATR and/or OVRDTA to
send new attributes and/or data to the existing display. This
technique leads to bleed-through because the OS does not clear the
screen area before displaying the new information. Your application
must ensure bleed-through cannot occur. The usual technique for that
is to code blank constants in all the unused parts of the overlapping
record format.
There is some code in there placing blanks in the line before the
footer info.
This is probably to hide data from previous record formats that
bleeds through when new information is displayed.
I put some identifying remarks in its place and could see what was
still showing from one footer to the other.
Maybe I should just write blanks to cover up the entire first
footer (or another blank footer) then write the second.
You could do that. Or you could instruct the OS to ERASE an existing
format when writing another footer. WRITE FOOTER2 and ERASE FOOTER1
at the same time. See the DDS keyword ERASE.
There is one of your old posts that might help out, but I'm not
sure about the comment about reordering the write of records to the
display device.
This just means that most people think you have to build a screen
from the top down. For example:
WRITE HEADER causes display to be cleared
WRITE BODY with OVERLAY
WRITE FOOTER with OVERLAY
but you can do it in any order that makes sense to your code. For
example:
WRITE BODY causes display to be cleared
WRITE FOOTER with OVERLAY
WRITE HEADER with OVERLAY
What I was getting at in the append you referenced was simply that
the programmer may need alter the order in which record formats are
written to ensure the screen is cleared properly with the first WRITE
and then the other formats OVERLAY properly.
Which would be the best way to code for this?
Depends on your existing DDS and HLL code. Proper understanding of
DDS will help and avoid all the "try this" and "maybe that" answers
you've been getting.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
