Re: Display file cursor positioning -- can somebody clarify, and/or jog my memory?

"I believe CSRLOC is probably my answer for the "fake subfile" screen,
but the manual says this doesn't work for subfiles."

You don't defined the CSRLOC on the subfile, but the CSRLOC used on the
control format can reposition the cursor to anywhere on the screen. In
this way you can use CSRLOC to manually position your cursor to a line
in the subfile. This works well with page at a time subfiles where you
have multiple places where you want the cursor to go.

However, with full load subfiles you also need to make sure that the
correct page is being shown using the SFLRCDNBR keyword.

A 75 CSRLOC(ROWPOS COLPOS)
A SFLRRN 4S 0H SFLRCDNBR(CURSOR)
A ROWPOS 3S 0H
A COLPOS 3S 0H

You can use both the CSRLOC and the SFLRCDNBR keywords at the same time.
However the CSRLOC will be used over any other DSPATR(PC) keywords that
may be active.



" And the manual entry
for SFLRCDNBR has the puzzling statement, "If the subfile record format
contains field selection, this keyword is not allowed." What exactly
does THAT mean?"
Here is a, somewhat lengthy, explanation of Field selection.

"Field selection" is used when you want a subfile to have different
fields shown for each subfile line. These types of subfiles are
page-at-a-time. To use the feature every field that is defined for
output must have an indicator on the definition. Also, every field is
defined for the first row of the subfile. For any two fields that
overlap on the output, only one can be "active" when the subfile rrn is
written out. If you accidentally turn on indicators for two fields that
overlap in the output then your data stream may be corrupted and your
session may display strange results. During development this happed a
few times and resulted in some subfile lines appearing on line 1 of the
display file, which was very strange.

I coded one application like this because I needed to have multiple
input fields in different positions that would potentially overlap each
other.

In order to maintain it, my display file contains a separate record
format for each "Group" of fields. Grouped fields use the same indicator
for activation. I added additional logic in my program to make sure that
if one group was active, the indicators for any overlapping groups were
always turned off prior to writing or updating the subfile.
Using Screen Designer in RDP 8 I was able to use the extra record
formats to reposition the lines and see how all the fields line up. Once
the adjustments are made I copied the lines back into the main subfile
and adjusted their row back to the first line of the subfile. I left
these "development" record formats inside the display file and coded the
RPGLE program to use the include keyword so they are not brought into
the program.
FCPA21AFM CF E WORKSTN INFDS(DSPFINFDS)

F SFILE(SCNSFL:RRN)

F SFILE(SCNSFL1:RRN1)

F INCLUDE(MSGSFL:MSGCTL

F :SCNSFL :SCNCTL :SCNFTR

F :SCNSFL1 :SCNCTL1 :SCNFTR1)


These types of screens are very customizable, however the added
complexity make them harder to maintain.

Here is a snippet showing 3 groups with overlapping fields.
A R SCNSFL

A***********************************************************************
**
A* Group 4 : Price/Cost Associate Code

A***********************************************************************
**
A 04 007 2'Price:'
A COLOR(WHT)
A 04 S0VIPASCDE 15Y 0O007 9EDTWRD(' - - ')
A DSPATR(&DSPATR04A)
A 04 007 27'Cost:'
A COLOR(WHT)
A 04 S0VICASCDE 15Y 0O007 33EDTWRD(' - - ')
A DSPATR(&DSPATR04B)
A DSPATR04A 1A P
A DSPATR04B 1A P

A***********************************************************************
**
A* Group 4b(03) : Price/Cost Associate Master

A***********************************************************************
**
A 03 S0MSTPAR 40A O007 6

A***********************************************************************
**
A* Group 5 : Related Item

A***********************************************************************
**
A 05 007 2'Rit:'
A COLOR(WHT)
A 05 S0RITUPC 15Y 0O007 7EDTWRD(' - - ')
A DSPATR(&DSPATR05A)
A 05 S0RITVND 9A O007 25
A DSPATR(&DSPATR05A)
A DSPATR05A 1A P

The program is currently running on V5R4 and V7R1 since we are upgrading
this week.

Chris Hiebert
Programmer/Analyst
Disclaimer: Any views or opinions presented are solely those of the
author and do not necessarily represent those of the company.