RE: Indicator Coding Technique

2 things,

1: I agree with you that IBM should have shielded us form the 5250 data stream 
for key press value and the like. We have a copy member that has all the value 
defined as constant so we can check agains them. But IBM sould have provided us 
with keyword like *F1, *enter ...

2: CSRLOC is, in my opinion, way worst than indicator. You must give screen 
coordinate to position the cursor!!! so if you miscalculate or if you change 
the design of the screen layout, the parameters of CSRLOC must change (also we 
would need some smart coding to make the code self documenting). Your idea of 
POSCSRFLD is the right one.

Denis Robitaille
Directeur services technique TI
819 363 6130

SUPPORT
Jour (EST) Daytime : 819-363-6134
En-dehors des heures (EST) After hour : 819-363-6158
Network Status : 819-363-6157

>>> rpg400-l@xxxxxxxxxxxxxxxx 2006-01-12 17:18:54 >>>
On Thu, 12 Jan 2006, Denis Robitaille wrote:
> I did try the DSPATR(&VARNAME) technique but i stoped because the 
> "position cursor" attribute is not supported (must be set by an 
> indicators). Since we use this a lot here (to position the cursor on the 
> first error encounterd on the screen) and that we did not want to use 
> different technique for different attribute, we setteled on using 
> indicators for display attribute (but giving them meaningfull name).

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

When you use DSPATR(&VAR), what you're really doing is setting VAR to have 
the exact 5250 code that you want to send to the display.  However, 
"position cursor" isn't really a display attribute.  There's no 5250 
attribute value for position cursor, so there's no value you could 
possibly put into &VAR that it could send to the terminal.

It's quite curious that IBM made DSPATR(PC) a display attribute in the 
first place.  Why didn't they have a "POSCSRFLD" keyword or something like 
that?  Why DSPATR?  it has little to do with how the field is displayed.

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.

But anyway, complaining about something that was implemented a long time 
ago and isn't changable at this point, is really an exersize in futuility.

> I also want to stress that using the display file data structure to find 
> out the pressed key is the way to go. this way, all keys can be treated 
> the same way (function keys, page up/down, print screen, even enter).

I have the same problem with that technique.  We shouldn't have to work 
with the raw 5250 AID bytes, we should have some level of abstraction. 
It's a really poor design that our two options are hex codes vs. numeric 
indicators.