About get_key() alternative
- Posted by achury Oct 17, 2020
- 921 views
The last thread about TAB KEY, makes me think about.
get_key() has a problem long long time ago. On DOS and Linux allways was a good keyboard support. On Win32 there are problems to support some keystrokes. This was never solved and we simply accept it this way.
Source code from ed.ex at Eu 3.1 simply says that some keys (like Ctrl_Left and Ctrl_Rigth) are not supported on exwc interpreter. Is a very old bug that requires a solution.
Also is not nice that special characters codes are not the same on any OS.
Some people tried to fix it and caused the problem with TAB Key discussed on another thread.
My proposal is:
1- Left get_key() as is (as allways has been) to keep compatibility with old code. A text oriented function that return mainly printable characters but not full support for special keys.
2- Create a new alternative keyboard function that provide better keyboard information.
The main problem is that I want to receive the text information (including unicode or regional language characters) and the special keys like F1 in with the same function and be sure not confuse them. Check what other languages do. I inspired on QBASIC that return one byte for printable characters and two byte "0+Other" for special keys http://www.petesqbsite.com/phpBB3/viewtopic.php?t=1105. If your qbasic receives a "0" from keyboard you know that the next byte is an special key, not a printable.
We can explote the power of sequences. A keystroke of several keys like Ctrl+Alt+Insert may become a sequence {CTRL, ALT, INS}. So, if your program receives from the keyboard an atom, is a printable character, but if receives a sequence is an special key that your program can process or discart. We can create a simple table of special key values unified the same for any OS, and left the printable characters as presented by the OS and their locale.
Regards
Marco Achury
