Re: Externalize DB/IO (was What Counts as Technically Slick?)

Nathan,

>The dbAdd() procedure sets
>corresponding values in the dbFlags array during the validation logic.  The
>screen I/O module then moves the dbFlags array to the *IN array, to set the
>"real" indicator values.

I figured it was something like that.  But this has more of a direct link
between the business logic and the UI than I'd like in terms of having to know
ordering etc.

John's solution is great from a capability standpoint, and let's the business
rules program be truly indpendent from any UI considerations.  This is ideal.
But does the UI program really end up looking simpler by the time you are done?
Maybe it does by the time you make routines to work with the attribute
structures.

>This is over my head.  Care to elaborate?

Most display attributes can be handled without indicators by naming a 1-byte
program-to-system field as in DSPATR(&attrbyte).  By changing the value of these
attribute bytes in your code, you can control color, underline, reverse image,
protect state, etc and never use an indicator in the process.  I use a /COPY
member with constants for the various bit combinations of attributes so I can
assign a meaningful name to the attribute instead of *INxx something.  I use the
DSPF data field name prefixed with a lowercase "a" as the associated
program-to-system field name. (EG field ITEM uses aITEM for the attribute.)

Alas, the DSPATR(&attr) keyword does not have a bit to control positioning the
cursor.  Nor does CSRLOC() have a variant which accepts a DSPF field name, the
way RTNCSRLOC() can return one.  Thus I use the QFDRTVFD api to get the cursor
location of the field for me at run-time.  This gives me flexibility to add and
arrange fields in the DSPF at will and never use an indicator in the process.

So to control the cursor I start by setting the row/column fields for CSRLOC to
zero.  When they are zero (or otherwise invalid) at output, they are ignored.
Then with each validation error (tested in top down order), I pass the DSPF
field name and the CSRLOC fields to a subprocedure, plus a couple of other
flags.  If the CSRLOC fields are not zero, ie if they have the location of a
previous error, then the routine doesn't overwrite it unless a flag field tells
it to preempt the previous value.  If they are zero, it retrieves the
coordinates for the field and fills in the CSRLOC values.  The error message ID
and replacement data are added to the error message subfile, and other optional
fields allow passing either a DDS indicator or program-to-system field to get
modified.

Doug
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---