Cursor Positioning

[Chipper Miller]

We have an input capable subfile. The user presses enter and if there
is/are error(s), the cursor would get positioned to the first field where an
error occurred. If no errors, the cursor would end up on the first field on
the first sfl record. (Pretty standard stuff so far.)

Now comes the wrench: I had to add a input field to the sflctl. Is it
possible to have the cursor position itself as follows:
1) If errors on sfl rcds, cursor positions to the first field where an error
ocurred.
2) If no errors on sfl rcds, but error on field in sflctl, position there.
3) Otherwise, cursor goes to first field on first sfl record.

I tried a couple of approaches, but no luck. Also checked a couple sfl
books we hade to see if there was some keyword. Didn't find anything,
either.

[John Johnson]

Hi,

I do this routinely, so I should be able to help. There may be better ways
to do this, but I know this works and has worked for years.

1). In the subfile control record, define a "position cursor" indicator on
the field you want to position to in the event of an error. The keyword in
"DSPATR(PC)" with an indicator on it. Let's call it "*IN50" for explanation
below.

2). Also in the subfile control record, define a hidden field that is four
bytes with zero decimals (it has to be signed, not packed) with the
SFLRCDNBR(CURSOR) keyword. If you define this with SDA, define it as 4,0
and prompt for keywords. Select subfile keywords and it will guide you.
Let's call the field "DSPRRN" for the explanation below.

When the "position to" indicator in the field on the control record is on,
it will override the value in the SFLRCDNBR(CURSOR) keyword.

Otherwise, whatever value is in the SFLRCDNBR(CURSOR) field is the subfile
record the cursor will be on (the first input capable field). It the
subfile has multiple pages, it will display the correct page.

So, when you write the program:

If the error is on the subfile control field, simply turn on *In50 to
position the cursor there. Make sure you turn it off after the EXFMT or it
will get stuck on.

I define a couple of switches (one byte fields) to control the rest. I
usually call them "@Redisplay" and "@First" . Before the subfile validation
loop, initialize the two switches to '0'.

Then, in your loop, if you find an error on a record, do this:

Eval @Redisplay = '1'
If @First = '0'
DSPRRN = Subfile relative record number
Eval @First = '1'
EndIf

Before writing the panels do this:

If @Redisplay <> '0'
Eval DSPRRN = 1
EndIf

The last is default to the first record in the subfile in case no errors
found.

I always also provide some error checks on DSPRRN to make sure it is never
outside the limits of the subfile.

This should do it. Hope it helps.

"Chipper Miller" <Chi...@MailOps.com> wrote in message
news:3a9c2...@news.kivex.com...

[Stephen Villanueva]

I agree completely with the DSPATR(PC), but I would use it for all errors.
If multiple fields are in error, you will be positioned to the first field
in error. Make sure you perform an update on the subfile after setting on
the indicator for DSPATR(PC). Only on those updated SFL records would the
DSPATR(PC) would be in effect. I wouldn't use the same indicator for the SFL
record and the SFLCTL record.

You can use the CSRLOC keyword to position to a specific point on the
screen.

|...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+.
...8
00010A R RECORD1 CSRLOC(LINNBR POSNBR)
00020A TITLE 40 B 1 2
00030A PAGE 5Y OB 1 60
00040A TEXT 1760 B 2 1
00050A LINNBR 3 OH
00060A POSNBR 3 OH

Drop an indicator (or lack of indicator) on the CSRLOC keyword and use it
to position only if there is not an error.

Alternatively, if there are no errors, you could chain out to the SFL with a
RRN of 1 and set indicator for the DSPATR(PC) on the first field and the
update the SFL record. This would eliminate any future problems of hard
coding field positions if the subfile fields were moved from their present
location.

Stephen Villanueva

"John Johnson" <jjoh...@kc.rr.com> wrote in message
news:rNXm6.97771$446.4...@typhoon.kc.rr.com...

[Chipper Miller]

Thanks for the replies. Forgot to mention that each sfl rcd is 5 input
fields each with its own dspatr(pc) ind. Nonetheless, this gives me ideas
to try some different approaches to see which one will go best with the
current design of the display dds & pgm.

[Jon]

Just as an aside, I find that creating a "header" version of the
subfile record is quite advantagious.... specifically it allows for
the usual 1=Create option with very little overheads. The only thing I
do is have a field (hidden) that contains any formatting (PC/RI/PR
etc) indicators that I always move back into the indicators prior to
updating a slf record. This reduces the number of indicators required
to seperatly control the attributes of "header" fields.

I try to conform to the look and feel of IBM screens as much as
possible, especially the WRK with format. I find that in the majority
of cases (90+%) that this provides a very workable system for data
access.

WRKCUST
WRKORDER
WRKDETAIL
WRKINVOICE

etc.

It also allows the internals of every program to be 90% standard, only
the fields and file names change.... all the record selection, option
storage, is common.

Where a WRK with is called passing subsetting parameters the user is
prevented from changing the top level key(s), also a low level can be
called witout passing anything, ie. WRKORDER *ALL

I always use page at a time SFL's as the control.positioning,
displaying needs to be under program control, once a SFL is created
and the program looses control then the positioning system goes to
pot.

With carefull thought it is possible to create a common WRK that can
also be used as a "search and select/view" again reducing the
maintenance nightmare...

as there is only one program to deal with for each component part.

Again, with the "edit" screen this can be in update/view mode (I even
went to the trouble of chainging the : and > markers via an array). I
can also call the WRK and pass a (hidden parm from a command) *CRT
*DLT etc. which imeediatly go to the edit screen and the user is
allowed to perform the relevent confirmation/editing.

Where I feel ILE will help is in physically hiding alot of the day to
day of the program, at the moment its like one huge cut and paste. My
creating general modules the only chages/code [visible] in the program
would be application specific.

Jon
--
Jonathan Wilson

Phone 07775 638904.

I can only offer advise! No responsibility can be accepted.
All sugestions are provided on a personal basis,
such as would be recieved by talking to a friend.