× 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.



Thanks Larry. There is some new information I am processing from this post. I need to go back to the drawing board a bit based on what you said.

Right now I am baffled by this:

I conditioned the SFLDSP and the SFLDSPCTL on two different indicators (31 and 32)

In my code I do this:
*in31= *on;
*in32=*on;
EXFMT FMT01

I get the following error message:
SFLDSPCTL or SFLDSP option required for PUTGET.

It acts as though the indicators aren't on. So I remove both indicators and the when I run the code, I see the control and the subfile display correctly (but then have issues with clearing the subfile. It is almost as though the indicators on the DDS are being ignored.

Still sorting this out (and scratching my head).

Pete Helgren
Value Added Software, Inc
www.asaap.com
www.opensource4i.com


On 12/21/2010 5:10 PM, Larry Ducie wrote:
Hi Pete,

<snip>
Incorrect record number in subfile SFLRCDNBR or SFLSIZ field.
</snip>

It may be that you are confusing the relative record number (RRN) with the SFLRCDNBR.

The RRN uniquely identifies each row in your subfile and should be different for each row - no duplicates.
The SFLRCDNBR tells the display file which page on your subfile you should display when issuing a write or exfmt.

You identify a field as a RRN by use of the SFILE keyword in the F-spec in your RPG.
You identify a field as a SFLRCDNBR by use of the SFLRCDNBR keyword in your DDS on your subfile control format.

Whatever value you put in the SFLRCDNBR field tells the display file to display the page that contains thr row with a matching RRN.

In your DDS you should:
define a hidden 4,0 field in the control format and assign it the SFLRCDNBR keyword

In your RPG you should:
define a relative record number to your subfile using the SFILE keyword. Do NOT use the same field you used for your SFLRCDNBR field. They are distinct and separate.

During your clear of your subfile you should:

set sfldsp off
set sfldspctl off
set sflclr on
write to the control format
set sfldspctl on (if you want to display your control format)
set sflclr off

(I NEVER use the same indicator for sflclr and sfldspctl - they are separate and I treat them as such)

Now you should prepare for your build (still in clear procedure):

set RRN to zero (so your build will start at 1 and increment)
set SFLRCDNBR to 1 (so you display the page that contains the row with RRN = 1 - the first page)
set slfend off

do NOT set sfldsp on here - you should only set sfldsp prior to your exfmt of your control format (possibly within your screen loop). The check should be as follows:

// if I actually have rows to display...
if RRN> 0;
sfldsp = *on;

// Otherwise, splash a "No Records" message...
else;
sfldsp = *off;
write norecords;
endif;

exfmt control;

Misunderstandings of the definition of SFLRCDNBR cause so many subfile issues:

1) If you use the same field for RRN and SFLRCDNBR you display the last page after the build as SFLRCDNBR = last value given to RRN.
2) Setting SFLRCDNBR to zero crashes on an exfmt because you tell the display file to display the page that holds row with RRN = 0.
3) Classic: forgetting to set SFLRCDNBR = RRNTOP when displaying a page results in a user paging down several times and pressing Enter only to shoot back to page. why? Because SFLRCDNBR still has the value 1 in it when set during the clear.
4) When building an expandable subfile pagedown doesn't take you to the next page because you forget to increment your SFLRCDNBR. The program built the new page - you saw it in debug - but you didn't tell the display file to display it!

The best thing about the last issue is a second pagedown DOES take you to the next page because the display file handles it now that you are not at sflend.

I hope this makes sense, and good luck.

Cheers

Larry Ducie




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.