Re: subfile issue

I'd add this: Valid comment.
Because of that, I define a data structure of the subfile fields and a SavedField like(datastructure). As I fill the subfile, I also add the SavedField as a hidden field. This gives me 3 benefits:

1) easy to check if any values in the subfile record were changed.
2) easy to see if the original file's fields are still the same as when first read, in case of updates at another work station.
3) really easy to have F5=refresh.


Way back when 300 baud was blazingly fast READC made sense. Today it should be considered a deprecated opcode, imho. READC is easy to understand, except when something is not working right. Or a programmer is trying to figure out the spaghetti when a programmer is trying to use SFLNXTCHG, READC, data from various files, complicated validity checking, and logic that is convoluted and unclear..




Carel Teijgeler wrote:

Well, if he is using READC to check an option field only, he can also check
if the option has a value higher then zero or blank when looping throu the
SFL with READC.With other input capable fields he should check the
before/after values of the SFL.

Using a FOR-loop means you have to check every input capable field if it
has changed.

If you know what the READC does (and most of you having programmed in RPG
III should), it is still the best suited opcode, not taking performance
into consideration.

With regards,
Carel Teijgeler
*********** REPLY SEPARATOR ***********

On 18-4-2009 at 16:27 Joep Beckeringh wrote:

Simon Coulter schreef:

Note: I see various other comments indicating SFLNXTCHG or READC are

suspect and not to be trusted. I have NEVER had a problem when using

these keywords except when I first started and did not understand how

they worked. It took about 15 minutes to properly understand the

relationship and since then READC has always behaved as I expected. The most likely cause of your problem is something in your code

(probably the READC loop itself) and not the behaviour of SFLNXTCHG or

READC.

Regards,
Simon Coulter.

Simon,

I see only two comments advising not to use READC. Jack said 'I have been

bit many times by missed readc's for various reasons' but did not

specify whether READC or he was to blame; Booth just said 'Get rid of a

lot of headaches. Forget the read'. So you're slightly exaggerating :-)

The problem with READC is that the name is wrong: it should have been

READT - read touched. Because if the user enters something but then

decides to blank the field or just rekeys the original value, the record

will be read by READC, even if nothing actually changed. Mostly I am not

interested whether a user touched a record after I last displayed it, but

whether the contents of the record have changed since I filled it.

If I use READC, I still have to compare the actual to the original values

and if for some reason I do not want to process the touched

records immediately, I have to mess with SFLNXTCHG to 'remember' that the

record was touched. That makes READC problematic, even it works

flawlessly as documented.

I agree strongly with Booth; a FOR-loop is much easier to understand.

Joep Beckeringh
--
This is the RPG programming on the IBM i / System i (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.


No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.0/2066 - Release Date: 04/18/09
09:55:00

------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.0.238 / Virus Database: 270.12.0/2065 - Release Date: 04/17/09 17:52:00