Re: Indicator Coding Technique

Scott,

You could use CSRLOC to set the cursor position rather than DSPATR(PC).
> That'd eliminate the need for an indicator.


I fully agree.  I tend to avoid indicators whenever possible, though they
are still needed for some things like controlling subfile operations.  But
even then you can rename/map them to meaningful names so the RPG code is at
least fairly readable.  I use DSPATR(&var) for setting attributes, and
CSRLOC() for positioning the cursor.  To avoid hassles with getting the
row/col correct for CSRLOC, I abstract that out to a subprocedure which uses
QDFRTVFD to obtain the position when passed a dspf, record format, and field
name.

This whole DSPATR(&VAR) thing was very poorly done, IMHO. People coding
> DDS want a level of abstraction between their code and the 5250 data
> stream.  They don't want to code raw 5250 codes. IBM could've easily
> written it so that you set  var = 'HI BL', and had it be high intensity
> and blinking.. they didn't need you to pass the raw attribute code.


Using /Copy and meaningful constant names go a long way here.  My bigger
gripe is the lack of being able to specify a field name inside a variable
for CSRLOC(), similar to how RTNCSRLOC() can perform the opposite and return
the actual field name (if any) where the cursor was located when an AID byte
was pressed.  I work around that using my own subprocedure, but it always
struck me as odd they added support for returning the cursor location by
field name but not setting it!

Doug