Ticket #468 (Fixed)Mon May 06 16:53:18 UTC 2019
INKEY in a TaskWindow requires an extra key press if Escape key pressed
| Reported by: | Richard Coleman (3190) | Severity: | Enhancement |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Fixed |
Details by Richard Coleman (3190):
Whilst investigating OS_Byte 129 in a TaskWindow (See Ticket #467) found that INKEY (which calls OS_Byte 129) also fails to deal with the Escape key correctly when in a TaskWindow.
Open TaskWindow
Enter BASIC
Do:
PRINT INKEY
If you press Escape then nothing seems to happen but press a key, any key, and then you get “Escape”.
ON ERROR doesn’t catch the Escape.
This is unaffected by the fix to the TaskWindow in Ticket #467.
This time I think it’s BASIC that needs sorting but I’ve had a look at the code but can’t see where it’s going when Escape gets pressed – I’m assuming into the Escape handler but I’ve no idea where it’s returning too once the Escape handler has set the Escape flag.
Outside of the Desktop PRINT INKEY returns “-1” followed by “Escape” if you press the Escape key. Which is the same as timing out, but without the “Escape” message.
Since BASIC just returns the character code of the key pressed or -1 would it not be better for INKEY to call OS_Byte 229,1,0 before calling OS_Byte 129 so that the Escape key is treated as a normal key anyway?
Doing SYS “OS_Byte”,229,1,0 before PRINT INKEY does return &1B.
This would make the problem, of waiting for another key press if Escape is pressed, to go away, as well as returning the Escape character (by default &1B though this can be changed by OS_Byte 220) which is probably what the user would have expected anyway.
Changelog:
Modified by Richard Coleman (3190) Thu, October 06 2022 - 19:42:05 GMT
Having had another look at this, what’s happening is that BASIC calls OS_Byte 129 for INKEY, and TaskWindow sits on the Byte Vector and handles INKEY and Escape itself.
On exit from the Byte Vector, BASIC then calls OS_ReadLine, and TaskWindow sits on the RdCh Vector, and whilst it is waiting for input it calls Wimp_Poll and then it checks for Escape and handles it.
And so the flag was being set to say that the Escape key had been pressed but it wasn’t being actioned until after the call to Wimp_Poll hence why an extra key press was needed to get it to handle the Escape key.
I’ve submitted a merge request to add a check for the Escape key as soon as the RdCh Vector is entered which fixes this problem.
Modified by Sprow (202) Thu, October 20 2022 - 07:36:23 GMT
- Status changed from Open to Fixed
Fixed by Richard in TaskWindow-0_85
