× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Michael,

I'm fairly certain that I can't post the code itself unfortunately. I'm
actually writing that footer record before the EXFMT of the subfile control
format, so I don't think that's causing it. I've debugged the program
looking at the value of SFLRCDNBR and it has the correct value in there for
positioning on the record in question.

I've not had much chance to get another look at it in the last few days.
Other priorities have come into play. I'm going to try to take some of my
own time to look at it further with all the knowledge shared here in mind
and I'll let you know what I find.

Thanks to all for the input! Hopefully this isn't one of those "dum-dum"
errors that I make from time to time!

Bill

On Mon, Mar 23, 2015 at 1:39 PM, <MichaelQuigley@xxxxxxxxxx> wrote:

Bill,

I've been busy again--so lots of discussion here.. This should work
correctly. The whole point of the SFLRCDNBR keyword is to get the cursor
positioned on the specified record. DSPATR(PC) shouldn't enter into it,
etc. I've used SFLRCDBNR for decades to do processing just like
this--including subfiles with no input-capable fields.

The only other thing that's thrown me off sometimes is when I write a
different record after the Subfile Control Record. It sounds like you're
writing the footer record (with the function keys) after the Subfile
Control Record, that could throw it off. I see Buck has asked you to post
the DDS and HLL code. Give us a look at the actual coding driving this and
let's see if we can figure it out.

If the code requested above seems like too much, an alternative would be
to debug the program and check the value of the SFLRCDNBR field from the
control record right before you write the record.

If you can't find anything by debugging and nobody can see anything in the
coding, can you open a PMR? Get IBM to explain what's wrong and then
report back to the list. We'd all like to understand what's causing the
failure here.

Michael


"RPG400-L" <rpg400-l-bounces@xxxxxxxxxxxx> wrote on 03/20/2015 06:22:49
PM:
----- Message from Bill Howie <blhowie66@xxxxxxxxx> on Fri, 20 Mar
2015 14:40:13 -0400 -----

To:

"RPG programming on the IBM i (AS/400 and iSeries)"
<rpg400-l@xxxxxxxxxxxx>

Subject:

Re: Positioning cursor on a subfile record

Michael,

I have tried your suggestion. After the user presses a command key on a
particular record, I set the value of the hidden field associated with
SFLRCDNBR in the DDS to what's in the hidden field associated with
SFLCSRRRN in the DDS (which contains the record number for the record
the
user selected), and then an EXFMT of the subfile control record happens
(there is a WRITE of a different display format immediately before this
that displays command key text). Still positions to the first record
of
the subfile. No DSPATR(PC) in play for this subfile.

Looking at the definition of SFLRCDNBR, it says that using this keyword
displays "the page of the subfile containing the record whose relative
record number is contained in this field". So am I interpreting it
wrong
that it will actually position it to the SPECIFIC subfile record?
Because
there are only 3 records in the entire subfile, so if you take this
definition literally, positioning the cursor to the first record is
technically displaying the page of the subfile that contains the record
the
user selected. Maybe I've got the wrong keyword for positioning on a
specific record?

Bill

On Tue, Mar 17, 2015 at 11:54 AM, <MichaelQuigley@xxxxxxxxxx> wrote:

Bill,

Sorry I've been away from the list for a few days. What you're trying
to
do should work. There are a couple things that've bit me or coworkers
when
we've tried this.

1) You say you're "...moving the field value that goes along with
SFLCSRRRN to the SFLRCDNBR field and updating the subfile." Do you
mean
you're updating the individual subfile record or rewriting the subfile
control record with the new SFLRCDNBR value? You need to rewrite
(i.e.,
update) the control record. You do not need an input capable field.
You do
not need to do a DSPATR(PC).
2) A prior DSPATR(PC) can mis-position the cursor. One common problem
is
to leave the indicator for DSPATR(PC) turned on and update the
individual
subfile record before updating the control record. That or defining PC
on
another field in the subfile record without any indicator.

Those are the big ones. Have you got this working yet?

Michael Quigley
Computer Services
The Way International
www.TheWay.org

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.