RE: Common Display File (Header + File-level Keywords)

We do something very similar for the command key prompt strings and
option strings which are built on the fly from program-defined arrays.
Our display files always have ALL command keys defined and the programs
simply display a "Command key invalid" message if the user presses one
for which the program does not have a defined use.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Thursday, January 30, 2014 8:12 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Common Display File (Header + File-level Keywords)

On 1/30/2014 1:17 AM, CRPence wrote:

The available F-keys can be compiled into the DSPF as file-level
keywords, yet coded with option indicators, thus enabling the program
to determine\control each CFnn that will be available with each
format; i.e. they can be compiled in the DDS *and* the RPG can set
which are active. And those same indicators could control what would
be the corresponding text and help for those keys in any record
format. Although given the probable difficulty in arranging text for
all desired function keys into distinct locations, the program might
instead formulate the text for the function keys [e.g. from messages]
along with setting its choice of available keys for the presented
format(s).

In a previous life (i.e., at SSA) this is exactly what we did. We
actually had two routines, one which formatted the command key prompt
strings and one which formatted the option strings (e.g., 2=Change,
3=Copy) across the top for our Work With type screens. They evolved to
become smart enough to determine whether F23=More options or F24=More
keys were needed and add those to the format strings as necessary.

Joe