RE: problem with RTNCSRLOC and DSPATR(RZ ER) in RPG program

Dan,

I tested on an InfoWindow II, a Network Station and Client Access V5R1.
It works indeed as you describe; the cursor moves to the end of the
field in the emulation and stays in position on the terminal and the NS
(which always emulated terminals more faithfully than CA).

Now if you really, really, really want to test for field exit, you could
test for the right number of zeroes in the leftmost  part of the field.
Assume the user enters 6 characters and presses field exit. The cursor
stays in position 7 (so you know 6 characters were entered); the 6
characters shift to the right and on the left 3 zeroes are inserted.
That should be a nice bit of code; especially if you leave it
uncommented :-)

Joep Beckeringh


> -----Oorspronkelijk bericht-----
> Van: rpg400-l-admin@midrange.com
> [mailto:rpg400-l-admin@midrange.com] Namens Dan Bale
> Verzonden: maandag 29 juli 2002 18:30
> Aan: RPG400-L@midrange.com
> Onderwerp: problem with RTNCSRLOC and DSPATR(RZ ER) in RPG program
>
>
> I have a perplexing problem with a display file and an RPG-IV
> program.  I am
> retrieving the cursor location via:
>
>    RTNCSRLOC( &RCL_RECORD &RCL_FIELD +
>          &RCL_POSITN )
>
> Based on special user requirements, the program must detect
> when Field Exit
> is pressed while the cursor is in a particular field (so that
> a protected
> field becomes unprotected under certain conditions and the
> cursor is placed
> on it instead of the next field).  The particular field is
> defined in the
> display file with "DSPATR(RZ ER)".  Because Field Exit cannot be
> distinguished in an RPG program from a normal Enter key, I
> used logic that
> basically said ...
>
>    If AIDbyte = EnterKey and
>       &RCL_Field = 'AAORD#' and
>       &RCL_Positn = %Size( AAORD# )
>
> ... to do my magic.  Essentially, if the cursor was found to be on the
> rightmost position of the field, I was assuming that Field
> Exit was pressed.
> This is a 9-character field for which they will never enter
> more than 7
> characters beginning at position 1 of the field (hence,
> requiring Field Exit
> under normal circumstances).
>
> This logic was working well through two weeks of development
> and testing.
> Moved it to the customer's system and, bang, the protected
> field becomes
> unprotected as designed, but the cursor jumps ahead of that
> field to the
> next field.  Through testing, it was determined that my
> Client Access V3R2
> (service packed to the max) client would "push" the cursor to the last
> position of the field when Field Exit was pressed in a "DSPATR(RZ ER)"
> field, while the dumb terminal at the customer's location
> (and our location
> too), as well as another emulation client, the cursor is "left" at the
> position it was at when Field Exit was pressed, thus the program
> "determines" that the Field Exit key was not pressed.
>
> As I'm reading through my therapeutic post, I'm beginning to
> realize that I
> may well be up a creek with this.  After all, the dumb
> terminal sets the
> standard for the behavior of this type of thing.  (Even
> though the dumb
> terminal I tried it on was a Wyse, what's important is that
> behaves the same
> way at the customer site and nobody's replacing hardware for
> my nifty piece
> of logic to work.)  However, if anyone's gotten this obscure
> technique to
> work like I'm trying to, I'd be more than happy to hear about it.
>
> - Dan Bale
> (I am *NOT* "Dale"
> http://archive.midrange.com/midrange-l/200105/msg00281.html )