On 15/06/2010, at 12:37 AM, John McKay wrote:
Thinking about this case, if SFLSIZ > SFPAG were used, and if all the
columns except one are output, the one being input or both output
and input,
then the cursor would move up and down that column and not go to the
others
when the tab keys or enter are used...
True but the original append was for a panel with multiple records
displayed in columns like SFLLIN.
I had a look at the data stream generated for SFLLIN and SFLCSRPRG and
it appears there is no technical reason why these two features cannot
be used together. The restriction is therefore artificial and likely
due to the complexity of calculating the next field value for the FCW
for each field.
Anyway, it seems that the desired behaviour could be achieved by
building a user-defined data stream of by using the DSM APIs. Given
that this is somewhat overkill then the same effect could be obtained
by faking things.
There are two requirements in the original append:
1) Multiple (2) columns of records. Each record contains 1 I/O field
and 1 or more output fields.
2) Cursor progression should be down each column of I/O fields rather
than across each row of I/O fields.
Given that SFLLIN gives the desired layout and SFLCSRPRG gives the
desired cursor movement but these keywords are mutually exclusive we
have to choose which is the more important. The layout can be faked by
the program but cursor control cannot. Therefore the desired layout is
faked by the old-fashioned method of defining multiple fields:
A OPT01 2D 0B 16 2
A NAME01 10A O 16 6
A DESC01 10A O 16 18
A TYPE01 10A O 16 30
A OPT02 2D 0B 16 42
A NAME02 10A O 16 46
A DESC02 10A O 16 58
A TYPE02 10A O 16 70
A OPT03 2D 0B 17 2
A NAME03 10A O 17 6
A DESC03 10A O 17 18
A TYPE03 10A O 17 30
... etc.
Thus we get a screen that looks like a multi-column subfile
(satisfying requirement 1):
row1 1 __ xxxxxxxxx xxxxxxxxx xxxxxxxxx 6 __ xxxxxxxxxx xxxxxxxxxx
xxxxxxxxxx
row2 2 __ xxxxxxxxx xxxxxxxxx xxxxxxxxx 7 __ xxxxxxxxxx xxxxxxxxxx
xxxxxxxxxx
row3 3 __ xxxxxxxxx xxxxxxxxx xxxxxxxxx 8 __ xxxxxxxxxx xxxxxxxxxx
xxxxxxxxxx
row4 4 __ xxxxxxxxx xxxxxxxxx xxxxxxxxx 9 __ xxxxxxxxxx xxxxxxxxxx
xxxxxxxxxx
row5 5 __ xxxxxxxxx xxxxxxxxx xxxxxxxxx A __ xxxxxxxxxx xxxxxxxxxx
xxxxxxxxxx
Default cursor movement is 1->6->2->7->3 and so on. That can be
changed with either FLDCSRPRG or SFLCSRPRG. Because this is no longer
a sub-file SFLCSRPRG is not allowed but FLDCSRPRG can be used instead.
So now we get:
A OPT01 2D 0B 16 2FLDCSRPRG(OPT03)
A NAME01 10A O 16 6
A DESC01 10A O 16 18
A TYPE01 10A O 16 30
A OPT02 2D 0B 16 42FLDCSRPRG(OPT04)
A NAME02 10A O 16 46
A DESC02 10A O 16 58
A TYPE02 10A O 16 70
A OPT03 2D 0B 17 2FLDCSRPRG(OPT05)
A NAME03 10A O 17 6
A DESC03 10A O 17 18
A TYPE03 10A O 17 30
... etc.
This gives cursor movement of 1->2->3->4->5 etc. and satisfies
requirement 2.
Of course, you could restructure the field sequence so the field
numbers go down the left side of the screen and then the right
instead of across and down as here. That would make it easier to
specify the next target field.
The program can continue to use a sub-file internally to manage the
data and simply move the appropriate records to the display fields. A
data structure would probably help with that.
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
