I’m not Tom, but, Yes, if you turn on the indicator for SFLNXTCHG and update the subfile record, it will be available for the next READC.
Phil

Phil’s right, though there can be complications.

From the Application Display Programming (PDF) manual:

• If a record retrieved by a get-next-changed operation is updated and the SFLNXTCHG keyword is specified for an updated record, the updated record is set again as a changed record. This allows the program to ensure that the user has changed the record. For example, if the program detects an error in a record, it is advantageous to require the user to correct the error. The use of the SFLNXTCHG keyword allows the program to read that record again on a get-next-changed operation so it can continue to reject the record until the error has been corrected. The next get-next-changed operation does not retrieve this updated record. The record cannot be retrieved again with a get-next-changed operation until all the changed records following it in the subfile have been processed.

From the code snippet you supplied, it’s hard to tell. But the general intention is that SFLNXTCHG applies to UPDATEd subfile records.

You might review Chapter 4. Displaying Groups of Records Using Subfiles, topic Requesting I/O Operations for a Subfile, Requesting I/O Operations for a Subfile Record Format, subtopic Reading the Next Changed Record in a Subfile. Then look over your general logic.

Tom

Thanks Philpl1jb and Tom,
There has to be a better way to paste code so it will not get jumbled. I haven’t found that way yet.
The sflnxtchg indicator is set on, the subfile is updated, and then the routine to READC is executed. The READC indicator is *on at the first read.
I will review the manual and verify that it is correct. But right now, what I am shown and what I see are different.

The READC indicator is *on at the first read.

Is the subfile redisplayed in the SrReadC subroutine? Or does it simply continue reading for the next changed subfile record? After the UPDATE, the subfile position should be immediately after the UPDATEd record. Are there other changed subfile records before EOF? If the subfile hasn’t been redisplayed and there are no additional changed records before EOF, that might be a problem.

To paste code, simply paste it, then select everything that was pasted and then click {code}. The selected text will be more or less cleanly presented when viewed later. Also note that if newlines are not part of what was pasted, then newlines won’t be part of what gets displayed. I tend to paste into Notepad first, to be a little more certain of what the lines will look like.

You can also click {code}, paste text and then click {/code} at the end.

Tom

When control comes back from the window sfl, the SRReadC just loops through without showing the base subfile again. I guess that is where the issue was. I re-arranged the code some and now have to skipping the SRReadC routine and going straight to the db file update roiutine. In other words, update the db file immediatly then show the base subfile again. So, WUSIWUGot in the file.
Now my issue is on the file update. First pass is good. Second pass(after choosing a code from the second subfile window) writes another record. Display the base subfile, comment is entered, back to the db file update routine, write duplicate record.
I just have to do some field checking when I figure a clean, consistant way to do it for all occasions.

Thanks for the code post tip.
Nick