RE: Window format clearing the remainder of the screen

Actually, I do an EXFMT on the SCRN1C format already.  The only time I've
ever done a separate WRITE and READ is when I have more than one format with
input capable fields and that is very rare.   I also write the SCRN1K format
before the EXFMT of SCRN1C.  As for the OVERLAY on SCRN1K, I figured it to
be necessary to avoid clearing the prior format from the screen.

And yes, we have major interface problems.  We're moving to a more normal
use of function keys (F3 for exit, F12 for previous, etcetera), but this
system will be gone by next year anyway so we're not putting much effort
into retrofitting code.

Now what is this AID byte?  I guess I should look that up.  I have always
been under the impression *INKx was understood by the vast majority of RPG
programmers and thus a good practice to make programs maintainable by
outsiders.

Donald R. Fisher, III
Project Manager
The Roomstore Furniture Company
(804) 784-7600 ext. 2124
DFisher@roomstoreeast.com

<clip>
I would create a separate window format and reference that on both SCRN1C
and SCRN1K that way it doesn't matter what order the formats are written to
the screen (as long as the window format itself is written first) and you
can use EXFMT on SCRN1C instead of a WRITE and a READ.  You'll find this
more flexible in the long run.

I probably wouldn't use OVERLAY on the SCRN1K format but would write that
to the window first and then EXFMT the SCRN1C format which will need
OVERLAY.

In addition to the above, you have major interface inconsistencies.
        1. Underlying screen uses F3 to 'do stuff' but window uses it for
Exit.
        2. Windows shouldn't have an Exit key, only a Cancel key.
        3. Inconsistent terminology -- CMD 3 vs. F3

Also, I do hope you are using the AID byte in the file feedback data
structure to test for the F-keys rather than the bloody awful *INKx
method.
<clip>