The V4R2 DDS manual doesn't say anything about different behavior if the
subfile is in a window, nor does it say the DSPATR(PC) doesn't work in a
subfile, although I can see it would choose the subfile control record
input-capable field over the subfile record input field since you're
displaying both at the same time and presumably the control record is above
the subfile record. But you eliminated that anyway by making the control
record field output-only.
What happens if you use SFLRCDNBR(*TOP)?
The manual says:
If *TOP is specified, the subfile record whose relative record number is
identified by the contents of this field will display as the first record of
the page of the subfile records being displayed.
If that worked, you'd still have the problem with the control record field
being input. Would it be possible to put the control record under the
subfile (ie at a higher row)? Might look weird, but would it work?
I also have SFLRCDNBR(CURSOR) defined and the correct RRN (confirmed by
debug) is being placed in the SFLRCDNBR field. I have tried changing
the input-capable field in the control record to be output and it
positions to the first record in the subfile. I have also tried using
Nxx indicators on other fields without success.
One thing of note is that this is a subfile within a Window.
Thanks...John
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Sounds like you are close...
There really is no need for a DSPATR(PC) as you cannot address a specific
record in this manner.
I just took a quick look at a SFL program that I have which is in a window.
When I detect an error eg. incorrect option entered I do the following:
1) Set on the SFLNXTCHG indicator to retain the flag telling the program
that the record has changed
1) Set on the DSPATR(RI) indicator
2) Z-ADD the RRN for the record into the field defined in my DDS on the
SFLRCDNBR(CURSOR) keyword
3) Move some message txt into a display field on line 24 of the display
4) Update the SFL which will set the cursor and turn on the RI attribute.
Now, my program has no input capable field on the control but, by default,
the cursor will always position to the first entry field on the first record
in the SFL. To override this is a little tricky so I would be surprised if
this is what is happening by default. I have many examples of SFL's with
input fields on the control and these work in EXACTLY the same way.
I would guess that as the DSPATR(PC) is being ignored and you are not adding
the RRN into the SFLRCDNBR field this is causing your problem. Also try
making sure that the SFLNXTCHG is on.
If you would like to see a copy of the program I have to do this function,
please don't hesitate to e-mail me at rta...@nospam.acsltd.com (just remove
the 'nospam')
Hope this helps
Sincerely
Robin Tatam
John wrote in message <7rkb84$luj$1...@nnrp1.deja.com>...
Using the SFLRCDNBR(CURSOR) and DSPATR(PC) on the option field works fine
for me (with fields in the control record, and in windows).
I think you still have a logic error somewhere in your program. If you wish
you can always send me the source of both DSPF and RPG... if time permits
I'll take a quick look.
Kind regards,
Paul
--------------------
John wrote in message <7rkb84$luj$1...@nnrp1.deja.com>...
I want to position my cursor within a subfile at the relevant RRN where
an error has occurred. Simple enough you would think. My problem is
that I also have an input-capable field in the control record and no
matter how hard I try I can't position the cursor in the subfile. I
have an indicator defined in the subfile with DSPATR(PC) and I update
the subfile immediately after turning the indicator on. The cursor
still positions at the first input capable field. Any ideas would be
appreciated.
I also have SFLRCDNBR(CURSOR) defined and the correct RRN (confirmed by
debug) is being placed in the SFLRCDNBR field. I have tried changing
the input-capable field in the control record to be output and it
positions to the first record in the subfile. I have also tried using
Nxx indicators on other fields without success.
One thing of note is that this is a subfile within a Window.
Thanks...John
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
The contents of this message express only the sender's opinion.
This message does not necessarily reflect the policy or views of
my employer, Merck & Co., Inc. All responsibility for the statements
made in this Usenet posting resides solely and completely with the
sender.
John <jpor...@my-deja.com> wrote in message
news:7rkb84$luj$1...@nnrp1.deja.com...