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.
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.
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
