Text Only | Text with Attachments

QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: moises1953 on June 05, 2020, 05:25:26 am

Title: BUGS: display of special characters and keyboard mapping
Post by: moises1953 on June 05, 2020, 05:25:26 am
Display of special characters and keyboard mapping are a pending subject in QB64. It applies to both the IDE and the INKEY $, KEYHIT, INPUT ... functions.
Regardless of the IDE language that is selected, the screen output uses the CP437. So if you configure Windows CP1250, you can see what you write, but when you run the program it will show the character corresponding to the extended ASCII code represented by CP437. Therefore, the page chosen for the IDE is not taken into account to generate the text outputs of the compiled program, therefore it is useless to choose another one than CP437. And so it should be to preserve compatibility.
Regarding the presentation, let's take an extended character from page CP437, for example º has the code 167, however when typing º on a Spanish keyboard you receive, both in the IDE and in the executables, with the code 186 that represents as ║, and therefore should be mapped to  167 to show º.
As for the keyboard, some [AltGr] keys, like {} [] work well in the IDE, but not in the INPUT, and in neither case can you type accented letters, which requires a KEYHIT process.
I am attaching an example for a Spanish keyboard.
Code: QB64 $NOPREFIX: [Select]
  2. DEFLNG H-P
  3. 'CONST Phor = 1366, Pver = 768 ' WXGA
  4. CONST Phor = 1600, Pver = 900 ' HD+
  5.  
  6. TITLE "Inkeyhit" 'Version 1.0
  7. hscr = NEWIMAGE(Phor, Pver, 256)
  8. SCREEN hscr
  9. 'Permite comprobar el mapeado del teclado.
  11.  
  12. PuedeFull = (Pver = DESKTOPHEIGHT)
  14. 'Para poner a pantalla completa basta pulsar <Alt><Intro> un par de veces.
  15.  
  16. fontpath$ = "Lucon.ttf": fontsize% = 24 'Windows lucida console 24x14
  17. style$ = "MONOSPACE"
  18. hfont = LOADFONT(fontpath$, fontsize%, style$)
  19. IF hfont THEN FONT hfont
  20.  
  21. LOCATE , , 1 'mostrar cursor solo funciona en modo texto
  22. PRINT "Inkeyhit & display (128-175): €‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ ¡¢£¤¥¦§¨©ª«¬­®¯"
  23. PRINT "                   (176-223): °±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞß"
  24. PRINT "CP437 extended     (224-254): àáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþ"
  25. PRINT "Puede comprobar si el mapeado del teclado es correcto"
  26. PRINT CHR$(254);
  27. LOCATE , 1
  29.   in$ = Inkeyhit$ 'emulates quickbasic INKEY$
  30.   IF LEN(in$) THEN
  31.     PRINT in$;
  32.     pcol = POS(0)
  33.     PRINT CHR$(254);
  34.     LOCATE , pcol
  35.   END IF
  36. LOOP UNTIL in$ = CHR$(27)
  38.  
  39. FUNCTION Inkeyhit$ STATIC 'Emulates INKEY$ for spanish keyboard
  40.   DIM i, iaccent AS INTEGER, car AS UNSIGNED BYTE, doblecar AS STRING * 2
  41.   i = KEYHIT
  42.   IF i THEN
  43.     car = 0
  44.     keyalt = KEYDOWN(100307) OR KEYDOWN(100308)
  45.     keyctrl = KEYDOWN(100305) OR KEYDOWN(100306)
  46.     keyshift = KEYDOWN(100303) OR KEYDOWN(100304)
  47.     IF iaccent THEN
  48.       SELECT CASE iaccent
  49.         CASE 1
  50.           SELECT CASE i
  51.             CASE 97: car = 160 '
  52.             CASE 101: car = 130 '‚
  53.             CASE 105: car = 161 '¡
  54.             CASE 111: car = 162 '¢
  55.             CASE 117: car = 163 '£
  56.             CASE 69: car = 144 '
  57.           END SELECT
  58.         CASE 2
  59.           SELECT CASE i
  60.             CASE 97: car = 133 '…
  61.             CASE 101: car = 138 'Š
  62.             CASE 105: car = 141 '
  63.             CASE 111: car = 149 '•
  64.             CASE 117: car = 151 '—
  65.           END SELECT
  66.         CASE 3
  67.           SELECT CASE i
  68.             CASE 97: car = 132 '„
  69.             CASE 101: car = 137 '‰
  70.             CASE 105: car = 139 '‹
  71.             CASE 111: car = 148 '”
  72.             CASE 117: car = 129 '
  73.             CASE 65: car = 142 'Ž
  74.             CASE 79: car = 153 '™
  75.             CASE 85: car = 154 'š
  76.           END SELECT
  77.         CASE 4
  78.           SELECT CASE i
  79.             CASE 97: car = 131 'ƒ
  80.             CASE 101: car = 136 'ˆ
  81.             CASE 105: car = 140 'Œ
  82.             CASE 111: car = 147 '“
  83.             CASE 117: car = 150 '–
  84.           END SELECT
  85.       END SELECT
  86.     END IF
  87.  
  88.     IF car = 0 THEN
  89.       SELECT CASE i
  90.         CASE 48 TO 57 'numeric heys 0-9
  91.           IF keyalt = 0 THEN car = i
  92.         CASE 97 TO 122 'CTRL a-z: 1-26
  93.           car = i
  94.           IF keyctrl THEN car = car - 96
  95.         CASE 128: car = 238 '€î   'spanish keyboard keys maping
  96.         CASE 161: car = 173 '¡­
  97.         CASE 170: car = 166 'ª¦
  98.         CASE 183: car = 249 '·ù
  99.         CASE 186: car = 167 'º§
  100.         CASE 191: car = 168 '¿¨
  101.         CASE 199: car = 128 'ç€
  102.         CASE 209: car = 165 'Ñ¥
  103.         CASE 231: car = 135 'ç‡
  104.         CASE 241: car = 164 'ñ¤
  105.         CASE 1 TO 255
  106.           car = i
  107.         CASE 256 TO 65535 'double byte chr$(0)+
  108.           doblecar = MKI$(i&)
  109.           car = ASC(doblecar, 2)
  110.           IF keyalt THEN
  111.             SELECT CASE car
  112.               CASE 59 TO 68 'F1-F10: ;-D
  113.                 MID$(doblecar, 2) = CHR$(car + 45)
  114.               CASE 133, 134 'F11,F12; …,†
  115.                 MID$(doblecar, 2) = CHR$(car + 6)
  116.               CASE ELSE
  117.                 MID$(doblecar, 2) = CHR$(0)
  118.             END SELECT
  119.           ELSEIF keyctrl THEN
  120.             SELECT CASE car
  121.               CASE 59 TO 68 'F1-F10: ^-g
  122.                 MID$(doblecar, 2) = CHR$(car + 35)
  123.               CASE 71 'Home
  124.                 MID$(doblecar, 2) = CHR$(119)
  125.               CASE 73 'RePag
  126.                 MID$(doblecar, 2) = CHR$(132)
  127.               CASE 75 'Left
  128.                 MID$(doblecar, 2) = CHR$(115)
  129.               CASE 77 'Right
  130.                 MID$(doblecar, 2) = CHR$(116)
  131.               CASE 79 'End
  132.                 MID$(doblecar, 2) = CHR$(117)
  133.               CASE 81 'AvPag
  134.                 MID$(doblecar, 2) = CHR$(118)
  135.               CASE 133, 134 'F11,F12
  136.                 MID$(doblecar, 2) = CHR$(car + 4)
  137.               CASE ELSE
  138.                 MID$(doblecar, 2) = CHR$(0)
  139.             END SELECT
  140.           ELSEIF keyshift THEN
  141.             SELECT CASE car
  142.               CASE 59 TO 68 'F1-F10
  143.                 MID$(doblecar, 2) = CHR$(car + 25)
  144.               CASE 71 TO 81
  145.               CASE 133, 134 'F11,F12
  146.                 MID$(doblecar, 2) = CHR$(car + 2)
  147.               CASE ELSE
  148.                 MID$(doblecar, 2) = CHR$(0)
  149.             END SELECT
  150.           END IF
  151.           IF CVI(doblecar) THEN
  152.             Inkeyhit$ = doblecar
  153.             iaccent = 0
  154.           END IF
  155.           car = 0
  156.         CASE -100308 'Alt up
  157.           IF LEN(buf$) THEN
  158.             car = VAL(buf$)
  159.             buf$ = ""
  160.           END IF
  161.         CASE -222 'accent and dieresis
  162.           IF keyshift THEN
  163.             iaccent = 3
  164.           ELSE
  165.             iaccent = 1
  166.           END IF
  167.         CASE -186 'backaccent and circumflex
  168.           IF keyshift THEN
  169.             iaccent = 4
  170.           ELSE
  171.             iaccent = 2
  172.           END IF
  173.         CASE -57 TO -48 'numeric keys, also numeric keypad with numlock
  174.           IF keyalt THEN
  175.             IF LEN(buf$) > 2 THEN buf$ = RIGHT$(buf$, 2)
  176.             buf$ = buf$ + CHR$(ABS(i&))
  177.           END IF
  178.       END SELECT
  179.     END IF
  180.     IF car THEN
  181.       Inkeyhit$ = CHR$(car)
  182.       iaccent = 0
  183.     END IF
  184.   END IF
  186.  
Title: Re: BUGS: display of special characters and keyboard mapping
Post by: RhoSigma on June 05, 2020, 05:37:28 am
Try using Steve's "Programmable Keyboard Input" to setup the input for yor needs:
https://www.qb64.org/forum/index.php?topic=2042.0

Or my falcon.h based unicode printing routines:
https://www.qb64.org/forum/index.php?topic=2248.0
Title: Re: BUGS: display of special characters and keyboard mapping
Post by: moises1953 on June 05, 2020, 03:13:55 pm
Thank's a lot RhoSigma, but none of this solves the problem of keyboard capture:
1. ¿Can you write an accented vowel on the IDE?, ¿or capture trought inkey$ function?
2. Think your keyboard has a ß letter. When you press goes to screen of the IDE?, or captures in KEYHIT function?
3. When you press [AltGr]+€, works OK.

In the case of the IDE , this is a bug, but in the case of keyboard capture and display, the InkeyHit funtion, wich emulates de inkey$, solves the problem in 146 lines of code, but needs a lot of maping,  por each keyboard. My example if for Spanish keyboard.
Title: Re: BUGS: display of special characters and keyboard mapping
Post by: RhoSigma on June 05, 2020, 06:32:50 pm
Quote from: moises1953 on June 05, 2020, 05:25:26 am
Display of special characters and keyboard mapping are a pending subject in QB64. It applies to both the IDE and the INKEY $, KEYHIT, INPUT ... functions.

It's a known problem and will probably remain as is at least for the foreseeable future. A complete overhaul of the input system would be required, which is not an easy task, as it is not just a single function, but several interdependent functions.

When I was adding the input support for &B prefixed numbers for QB64 v1.4 I got a slight idea of how confusing the input system is. You might think adding support for &B is a small change here to recognize the prefix itself and adding a small algorithm there to process the following zeros and ones to get the  final number. But the reality is, that I had to do changes in more than a dozen different places in internal\c\libqb.cpp to catch really all INPUT variants.

In fact, don't expect that this problem will go away soon.

Quote from: moises1953 on June 05, 2020, 05:25:26 am
Regardless of the IDE language that is selected, the screen output uses the CP437. So if you configure Windows CP1250, you can see what you write, but when you run the program it will show the character corresponding to the extended ASCII code represented by CP437. Therefore, the page chosen for the IDE is not taken into account to generate the text outputs of the compiled program, therefore it is useless to choose another one than CP437.

It's not useless to use another codepage in the IDE, you just must make your program using the same one to get the correct output. See http://www.qb64.org/wiki/MAPUNICODE and the given example. You can also use the SUB SetAnsiCodepage() from my falcon toolkit mentioned in my first reply. Note that your program must use a unicode font, just as the IDE needs to with another codepage than 437.

Quote from: moises1953 on June 05, 2020, 05:25:26 am
Regarding the presentation, let's take an extended character from page CP437, for example º has the code 167, however when typing º on a Spanish keyboard you receive, both in the IDE and in the executables, with the code 186 that represents as ║, and therefore should be mapped to  167 to show º.
As for the keyboard, some [AltGr] keys, like {} [] work well in the IDE, but not in the INPUT, and in neither case can you type accented letters, which requires a KEYHIT process.

As said above, the input system is a pain. Using _MAPUNICODE does only change the text output, so that the strings used in your program will show up correct (if your program CP is mapped to the same CP you've used in the IDE). However, INPUT, INPUT$, INKEY$ etc. will not change by using another codepage, but if it's the same as your system codepage at least the regular letters should work (when using a unicode font in your program). I guess the special AltGr chars will still be wrong or not working at all.

Conclusion, if your InkeyHit function works for you, then be happy and use it. I made a similar function for german keyboards here: https://www.qb64.org/forum/index.php?topic=1385.0
Title: Re: BUGS: display of special characters and keyboard mapping
Post by: moises1953 on June 06, 2020, 02:05:03 am
Thank's a lot RhoSigma.
Most people who migrate an application from DOS only need consistency, which in the case of the keyboard means that if you touch a key it appears in the IDE, is written the same in the output, and is captured the same in the inputs. Agree?
Could that happen by using the translation function of the windows API?

https://docs.microsoft.com/en-us/windows/win32/inputdev/using-keyboard-input
....
Any thread that receives character input from the user must include the TranslateMessage function in its message loop. This function examines the virtual-key code of a keystroke message and, if the code corresponds to a character, places a character message into the message queue. The character message is removed and dispatched on the next iteration of the message loop; the wParam parameter of the message contains the character code.

In general, a thread's message loop should use the TranslateMessage function to translate every message, not just virtual-key messages. Although TranslateMessage has no effect on other types of messages, it guarantees that keyboard input is translated correctly. The following example shows how to include the TranslateMessage function in a typical thread message loop.
...
Text Only | Text with Attachments