Re: READC and *INPUT datastructure

[Booth Martin <booth@xxxxxxxxxxxx>]

Today's computers are very different from way back when READC was made 
available.   Today one can effectively use a for/endfor loop and chain 
to each subfile record.   If there is a change then process the change 
and finish the loop.  Here is an example of how I have done this: 
http://www.martinvt.com/Code_Samples/FAQ/faq.html

A lot of subfile coding issues just plain go away with this approach.

The other issue for this is how do you make the compare, to see if a 
record's fields have changed.  What I do is define a data structure of 
all relevant screen fields, and define a field like the Data 
Structure.   This field becomes a hidden field in the subfile.  When I 
read the subfile record I can do an immediate compare of the screen data 
structure with the hidden field.  If they are no longer the same then 
there has been a change.  Execute a subroutine to deal with the changes, 
remembering to repopulate the hidden field and updating the subfile.

This is especially nice if you wish to offer the users an F5=Refresh.  
All you need to do is the for/endfor loop, populating the screen's 
fields by eval'ing the hidden field into the screen data structure and 
then updating the subfile record.

It is also a useful solution if you need to check the disk file's record 
to see if it has been changed by another user while this user has had 
the subfile open for editing.

On 1/26/2010 2:14 PM, darren@xxxxxxxxx wrote:
> How do you use READC correctly with a DS?
>
> I've been using data structures more with my RPG I/O commands.  I'm a
> little stumped by READC though.  The manual says that the data structure
> used in a READC must be defined with *INPUT, which means only input capable
> fields are defined.  In many of my subfile programs, the action field is
> the only input capable field available.  So if the user puts a 2 on the
> second record subfile record, you get a '2' back in the READC, but nothing
> else.
>
>