INFDS *STATUS Value not correct

[SDeanD]

We use the INFDS *STATUS to return the keycode pressed for PageUp, PageDown, HELP....

I find some documentations, but not conclusively. Is this supported? is there a workaround? I started adding Response indicators to the keys. but, was hoping for a simpler solution.

FAIS329FM CF E WORKSTN
F/COPY QRPGCPYSRC,$PROFOUND
F INFDS(ROLDS)
D ROLDS DS
D STAT *STATUS
* IF ROLL UP REQUESTED, DISPLAY NEXT 8 WEEKS
C STAT IFEQ 01122
C GOTO DSPSC2
C ENDIF

Sample above .

thanks,
Dean

[DaveLClarkI]

For that we use position 369 in the file information data structure:

Code: Select all

      *         Identifies the key pressed
     D Dsp_AID               369    369                                         * Key Pressed
     D Key                   369    369                                         * Key Pressed

Code: Select all

...snip...
     D $F23            C                   CONST(X'BB')
     D $F24            C                   CONST(X'BC')
      *
     D $CLEAR          C                   CONST(X'BD')
     D $ENTER          C                   CONST(X'F1')
     D $HELP           C                   CONST(X'F3')
     D $PAGEUP         C                   CONST(X'F4')
     D $PAGEDN         C                   CONST(X'F5')
...snip...

[Scott Klement]

Right now the Open Access Handler does not set the statuses based on the keys pressed. It only sets status to 0 when all is successful, or it sets it to one of the several "generic" error statuses if something goes wrong.

Would the solution that Dave C. posted help you? This way, the logic is somewhat similar to the way you'd do it with *STATUS. Granted, it's a different spot in the INFDS, and there are different codes, so you'd have to change your program, but it might be doable.

It's important to understand that function keys are made available from Rich Display applications by the 'Shortcut Key' property of widgets. For example, if I wanted to allow F3 to exit my program, I'd add a button, and set it's shortcut key property to F3. Same could be done for the ones that set statuses like Page Up, Page Down, Help, Clear, etc. So you'd have a button (or similar) that enables that particular 5250 key. Since you're doing that, it doesn't seem like adding a response indicator would be all that much more work. Might be easy? Surely it would be easier to read.

But, if you have a lot of old displays where converting them all to use a different approach would be too much work, let us know, and we can figure out a solution. We could potentially (I don't know for sure if we can change this, I'd need to discuss with the rest of the team, but...) have the OA Handler set these statuses... but it could not do so 100% correctly, since it has no way of knowing whether the various keys are already attached to indicators. (The green status values are designed to only be turned on if the user doesn't have a response indicator in his DDS. But the OA handler has no way of knowing that, since it's handled by the JAvaScript code.) So it would have to set the status any time the user hit one of the special function keys, even if it did have a response indicator. This wouldn't be 100% right, but might help you out?

But, if you can get by using Dave's suggestion, or by using response indicators instead of checking *STATUS, that would be even better.

Let me know what you think, please...

[SDeanD]

I think I Can use Dave's Suggestion.

It would not be hard to do a scan and replace. mostly the old programs are looking for page up,down. left over from S/36.
prior to subfile programming. many have arrays instead of subfiles.

Thanks, I will update after I convert a few more.


THANKS DAVE!