Internal procedure INQFLAG starts with following code:
---------------------------------
PROCEDURE INQFLAG:
ASSIGN msg-nr = "edit0094".
RUN keyregel.p. /* SHOWS POSSIBLE Function-Keys */
READKEY.
MESSAGE
"IN INQFLAG custcl01.p: LASTKEY = " KEYLABEL(LASTKEY).
PAUSE 8.
APPLY LASTKEY.
MESSAGE
"IN INQFLAG custcl01.p: LASTKEY = " KEYLABEL(LASTKEY).
PAUSE 9.
--------------------------------
Keystrokes that are validated are PAGE-DOWN, PAGE-UP and F5. I need the example of the F5 because there is specific functionality behind that F-Key.
Before the APPLY LASTKEY statement, the Message shows LASTKEY = F5.
After the APPLY LASTKEY statement, the Message shows LASTKEY = <blanc>. And then the IF LASTKEY EQ KEYCODE("F5") statement returns FALSE.
Does this blanking out of LASTKEY sound familiar to anybody?
We are running 10.2B04 under Suse Linux 11 patch 2
I'm gonna skip this issue. There is a workaround for the required functionality and the program is going to be phase out.
LASTKEY is being cleared by the PAUSE statement, not by the APPLY statement. I'll look into why it's doing this. PAUSE and READKEY share some of the same code so this interaction isn't surprising.
As I suspected this is happening because PAUSE and READKEY share the same code. The answer lies in the documentation for READKEY PAUSE n:
The READKEY statement waits up to n seconds for a keystroke. If you do not press a key during that amount of time, READKEY ends, and sets the value in LASTKEY to -1.
PAUSE n and READKEY PAUSE n do the same thing so they treat LASTKEY the same way.
Thank you Matt for this explanation. Strange thing that occurs however, is that if I remove both Message-Pause lines before and after the APPLY LASTKEY statement, the IF LASTKEY EQ KEYCODE("F5") that follows on the code snippet shown does not return TRUE. So even without the MESSAGE and PAUSE lines, it does not behave as I would expect.
Can you post a short compilable example that demonstrates the issue? IF LASTKEY EQ KEYCODE("F5") works as expected for me but maybe there's something else going on in your code that I'm missing.
That's not that easy, other program's with the same construction don't have this issue and process the keystroke F5 as expected. I'll dig a little deeper into this, but that might take a few days.
I'm gonna skip this issue. There is a workaround for the required functionality and the program is going to be phase out.