Simon, Booth, Stephen, Terry,
Thanks for making me stop and think this through. Following is what
worked for me:
What ended up working for me * TR097MDR
WRITE MSGSUBC
WRITE SUBFTR01
EXFMT SUBCTL01
WRITE MSGSUBC
WRITE SUBFTR02
EXFMT SCREEN02
A R SUBCTL01 SFLCTL(SUBFIL01)
A OVERLAY
A R SUBFTR01
A*************************** CLRL(*NO)
A OVERLAY
A ERASE(SUBFTR02)
A***************************** 23 3'
-
A****************************
-
A************************* '
A R SCREEN02
A OVERLAY
A R SUBFTR02
A******************************* CLRL(*NO)
A OVERLAY
A ERASE(SUBFTR01)
A************* 23 3'
-
A***************
-
A*************** '
A************** 23 3' '
Fran Denoncourt
Sr. Programmer/Analyst
Pinal County Treasurer's Office
Florence, AZ 85232
(520) 866-6404
Frances.Denoncourt@xxxxxxxxxxxxxxxxx
Receipt of this message does not grant you permission to send me
Unsolicited Commercial Email
Simon Coulter <shc@xxxxxxxxxxxxxxxxx> 09/07/2008 1:39 AM >>>
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 HEADERcauses display to be cleared
WRITE BODYwith OVERLAY
WRITE FOOTERwith OVERLAY
but you can do it in any order that makes sense to your code. For
example:
WRITE BODYcauses display to be cleared
WRITE FOOTERwith OVERLAY
WRITE HEADERwith 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
