BBS: Inland Empire Archive
Date: 03-11-92 (01:11) Number: 73
From: JEAN CREPEAU Refer#: NONE
To: RICK STRICKER Recvd: NO
Subj: F-Keys & Line Input Conf: (2) Quik_Bas
In a message to ALL, RICK STRICKER wrote:
RS=> In this case, the app asks for input at ENTRY. LINE INPUT is normally
ended by hitting ENTER. However I'd like to get to HELP by hitting F1
by itself (without hitting ENTER).
RS=> I also tried: IF DAT$ = (CHR$(0) + CHR$(59)) with no luck.
RS=> Also: DAT$ = INKEY$ IF DAT$ = (CHR$(0) + CHR$(59)) THEN GOSUB
HELP even: IF INKEY$ = (CHR$(0) + CHR$(59)) THEN GOSUB HELP No good.
RS=> I don't have my scan code listing with me here, but 0 + 59 may not be
right for F1. I'm using the right one in the actual code though.
RS=> I also found that the scan codes for the numeric keypad arrow keys
aren't the same as the codes for the upside-down "T" arrow keys on the
enhanced keyboard. I don't have any listing for the enhanced arrow
keys...
The point is that the ON ... GOSUB is not like an interrupt...
QuickBASIC checks the event only at the beginning of the line (if you
compile with the /V option) or at the beginning of every command (with the
/W option). But it doesn't check DURING the command is executed. So when
you are doing a LINE INPUT (or just INPUT or INPUT$), your KEY events are
not checked. If you press an event key, it is memorised, but not executed.
When the next event check is done, your subroutine is executed.
There is no way to trap the keys in a LINE INPUT... You have to do
it with INKEY$ (as you did). INKEY$ returns either a one-byte or two-byte
string. If the key pressed has an ASCII equivalent, the string returned is
a one-byte type containing the ASCII character. Otherwise, INKEY$ returns a
two-byte sequence beginning with a NULL (ASCII 00) character. The second
character is the scan code of the key. If you plan to use INKEY$, you must
disable any KEY trap.
For the "T" key-pad, I'm not sure (since I still have an old 83-key
keyboard), but I think the first character is E0 (hex.) instead of a NULL
character... I usually use the following code to check any special key:
kfk$=";<=>?@ABCDGHIKMOPQRSstuvw"+CHR$(132)
do:k$=inkey$:loop until len(k$)
if len(k$)=1 then
...
else
k=instr(kfk$,mid$(k$,2))
select case k
case 1: (code for F1)
case 2: (code for F2)
...
case 10: (code for F10)
case 11: (code for [Home])
case 12: (code for [Up])
case 13: (code for [PgUp])
case 14: (code for [Left])
case 15: (code for [Right])
case 16: (code for [End])
case 17: (code for [Down])
case 18: (code for [PgDn])
case 19: (code for [Ins])
case 20: (code for [Del])
case 21: (code for [Ctrl][Left])
case 22: (code for [Ctrl][Right])
case 23: (code for [Ctrl][End])
case 24: (code for [Ctrl][PgDn])
case 25: (code for [Ctrl][Home])
case 26: (code for [Ctrl][PgUp])
case 0: (code for other keys)
end select
endif
The INSTR and MID$ could be optimised with an assembler routine.
The code is easy to debug and easy to update. The program does not
discriminate between thee two [Home] keys of an extended 101-key keyboard.
BTW, the F1 key is really NUL+59.
Jean
---
* Origin: INTERACESS Montreal (QC) Canada (514) 528-1415 (1:167/280)
