|
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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.