RE: Subfile question -- RPG400-L

Hi Don,

<clip>
I'm not certain how I would pull that off, especially considering I like to
include cursor sensitive help in my applications.  I also think one would
quickly run out of indicators in such a scenario, so I'd have to think about
this for a while.
</clip>

Our report submission screen is completely soft-coded - it handles any alpha field from 1-alpha to 20-alpha, it handles numerics, dates (*EUR, *ISO, *DMY) and times. All edit codes and edit words are catered for. Granted, we do use banks of indicators (6 for the alpha fields alone). The screen runs in 8 different languages, has field-sensitive help and field sensitive prompting. You really can make your field selection subfile run just like a regular panel - better in fact.

Obviously, if you do not have a requirement to perform such a task then it may be more work than it's worth. But I've always found that the first program is the hardest to write - the rest are just enhancements. :-)

We have another program that has an alternative use - all of our Enquiry System programs are wafer-thin. That is, they only contain a single screen. All function keys and subfile options are held in a file and a new program is called upon valid key-press or subfile entry. This allows us to add new options or functions to a screen at will. It also promotes code re-use - you write one carton details screen and then update the options file to allow it to be called from 14 different screens! Not a single code change. All of our Enquiry System programs take a single parameter, which is a DS mapped to a file. Now, some of the DS fields are mandatory parameters for some of the programs, other DS fields are mandatory for other programs. As part of the system, a central program is called to validate the data that is passed between the programs. If the calling program does not pass the required data to allow the called program to function correctly a panel is presented to the user. This allows them to enter any missing data. This screen, of course, displays completely different parameters, depending upon the program being called (and who called it). It doesn't display all DS fields - there's no point. It only displays the fields that are mandatory/optional for this call. This is a classic case for a field selection subfile. It was the first one we wrote, and it works a treat.

(As an aside - the Enquiry System actually only goes one call deep. There is a central program that calls all screen programs. When an option is taken from one screen, the program modifies the DS (adds data from the subfile record), returns to the central program and the central program then calls the new screen program. Thus you can call programs as recursively as you wish. It's beautiful, lightweight, and totally flexible! All possible because we can dynamically build our error-trapping screens.)

HTH

Cheers

Larry Ducie