wish list item - define files or define screens

[Bruce Easton]

This is a wish list item for ddefine and/or dscreen.  Maybe this 
has been covered already by some 3rd party - if so, I'd like to 
know.  If not, then, if someone would please let me know where 
the most appropriate and effective to place a wish list item is, 
then I'd be happy to place an entry for this.

Presently, when saving a map in Define Files, the developer has 
the option of creating a default screen 0.  If this option is 
selected, then a screen 0 is created/overwritten with as many 
fields that will fit from the map starting on the fourth line of 
the screen, starting with field 1, one field per line. (I'm 
guessing a field will 'fit' on the line if it can be preceded by 
'field' concatenated with its field number, followed by a colon 
and space and have its field end marker still stay on the same 
line.)

I would like to see this functionality expanded as follows:

1.  In the save map dialog (after ESC ESC), replace the expression 
'Create a screen 0' with 'Create a default screen'.

2.  In the same dialog, after that same flag field to indicate 
'Create a screen 0', I'd like to see two more fields:
  a.  screen name (that maybe would be defaulted to '0' if screen 
      0 does not yet exist, but where any screen number or name 
      can be entered).
  b.  starting field# (default entry of '1', but that can be 
      overridden).

3.  In ANY case, the program should prompt if an existing screen 
    #/name is about to be overridden.

The current ddefine program would then run just as it does now, 
only respecting the new fields screen #/name to write to and 
starting field number (and warning about overwrites).

This way, one could generate a set of default screens that cover 
all fields in a large database in little time.  You would just 
run the program several times and let it do the maximum # that 
will fit for each run - you would just start on a different screen 
#/name and with the last field that didn't fit as the starting 
field for the next run. (I'm sure this would not be the only 
benefit of implementing such an enhancement, but this is 
functionality I need that made me think of this.)

I would even suggest going a step further and incorporating this 
feature in Define Screens (or better leaving Define Files alone 
and incorporating this entirely in Define Screens, since screen 
design does not prevent someone from simultaneously using the 
file).

For someone developing an fp-based application - such as a web-
based application where elaborate character-based screens are 
not needed, but where maintenance screens covering all fields 
in the database maybe desired, I think this would be a nice 
enhancement to ddefine/dscreen.

Bruce

Bruce Easton
STN, Inc.