RE: Subfile question

["Larry Ducie" <larry_ducie@xxxxxxxxxxx>]

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