1. TAB KEY
- Posted by achury Oct 12, 2020
- 1341 views
I have a question about key.ex and get_key() on windows
I noted that using Eu3.1, the TAB key returns value 9
Using Euphoria Interpreter v4.1.0 development 64-bit Windows, Using System Memory Revision Date: 2015-02-02 14:18:53, Id: 6300:57179171dbed
The same TAB key returns 1015936
Is this a bug or a feature? Depends on the compiler used to build the interpreter?
Just for that detail, the compatibility become broken.
Marco Achury
2. Re: TAB KEY
- Posted by ghaberek (admin) Oct 13, 2020
- 1328 views
Is this a bug or a feature? Depends on the compiler used to build the interpreter?
If you take a look at the getKBcode() which is what does get_key() internally on Windows, you'll see at line 659 that it checks for the tab key (EuChar == 9) and then passes it through a big int[] array named VK_to_EuKBCode which then converts it to 0xF8080 (1015936), the value you're seeing.
So... why?
Well, it looks like Derek added all that on 12 Nov 2011 in commit 1e10f0d with the comment:
Windows keyboard now uses native API and also fixes keycode clashes with unicode chars
And... I'm still not sure why. I mean, I get using the Windows API to read keyboard characters and avoiding Unicode problems, but the Unicode value for Tab is still 9.
Just for that detail, the compatibility become broken.
This might just be a bug. I wonder if Derek's around to chime in on this.
-Greg
3. Re: TAB KEY
- Posted by achury Oct 13, 2020
- 1312 views
- Last edited Oct 16, 2020
I think is a severe bug that must to be fixed and may cause a lot of confusion.
I noted this because edx.ex editor on windows don't accept TAB
From: https://en.wikipedia.org/wiki/Tab_key
And near the end of the same article wikipedia says about TAB on unicode
U+000B <control-000B> (LINE TABULATION, vertical tabulation (VT))
U+240B ␋ SYMBOL FOR VERTICAL TABULATION
U+21C6 ⇆ LEFTWARDS ARROW OVER RIGHTWARDS ARROW
U+21E4 ⇤ LEFTWARDS ARROW TO BAR (leftward tab)
U+21E5 ⇥ RIGHTWARDS ARROW TO BAR (rightward tab)
So Unicode has glyphs to represent the tabulation and the symbol that appear on the Tab key, but in the keyboard input itself is allways 9
And obviously, If you run this program:
? "\t"
You will get as result a {9}
And any program that get keyboard input and save it to a file, is supposed that will save 9...
Marco Achury
4. Re: TAB KEY
- Posted by ghaberek (admin) Oct 14, 2020
- 1261 views
I found the discussion on rapideuphoria-develop mailing list: Keyboard handing changes. Although I haven't had the opportunity to read through the whole thing yet.
-Greg
5. Re: TAB KEY
- Posted by SDPringle Oct 16, 2020
- 1230 views
Since the value of TAB as a character is indistinguishable from CNTRL+I, I believe the intention was to give get_key() the ability to distinguish CNTRL+I with TAB keystrokes. Whereas this might be useful in games it is supposed to be a high-level system where you don't have details like numeric keys in the number locked keypad versus number keys that are all in one row. So why should we be able to distinguish CNTRL+I from the TAB key? The community has spoken. Let's change things back.
6. Re: TAB KEY
- Posted by achury Oct 16, 2020
- 1276 views
Since the value of TAB as a character is indistinguishable from CNTRL+I, I believe the intention was to give get_key() the ability to distinguish CNTRL+I with TAB keystrokes. Whereas this might be useful in games it is supposed to be a high-level system where you don't have details like numeric keys in the number locked keypad versus number keys that are all in one row. So why should we be able to distinguish CNTRL+I from the TAB key? The community has spoken. Let's change things back.
Such things were common on DOS. The programs used to read directly ports to check when a key is pressed or released on real time. I don't know on Windows on deep, but by sure the OS have an API for such information. A game or any program that requires low level machine information must to use such functions. But as I understand, get_key() is a text orient function. I allways assumed that is like BASIC's INKEY$. Simply gives you the next text character on the keyboard buffer, even if such key was pressed and released several minutes ago.
Several times I have used english and french keyboards on computer with spanish locale. Such thing must be transparent to user (and programs). OS manage the keyboard's hardware, filter the information depending on the user's locale and provide the user with the rigth text characters. If Eu interpreter calls high level OS functions to get the characters, why not pass them directly to my program? The OS maintainers are responsable to keep updated the locale profiles for any present or future language and keyboard, left them to make their job.
People programming games requires different functions, not text oriented. May be is needed on standar library or a separated package with such low level keyboard control functions, things like turn off NumCaps and get on real time pressed and released keys.
Regards
Marco Achury
7. Re: TAB KEY
- Posted by jimcbrown (admin) Oct 19, 2020
- 1235 views
Is this a bug or a feature? Depends on the compiler used to build the interpreter?
We only support GCC based compilers now.
As I said roughly five years ago, it's partly related to switching away from OpenWatcom, https://openeuphoria.org/forum/m/128371.wc
I wonder if Derek's around to chime in on this.
He was last around in early Feb of this year. There's no news on his website ( at http://derekparnell.id.au/Resume.html ) of anything happening since, so no news is good news! I'll stay optimistic and hope he'll chime in soon.
I was around and took part in these dicussions (almost a decade ago now), so I might also be able to provide some clarity around this.
If you take a look at .. which then converts it to 0xF8080 (1015936), the value you're seeing.
So... why?
After switching away from OpenWatcom, a bug with handling keys on non-US keyboards was exposed, and this was Derek's fix to handle that.
The other thing might have been that OpenWatcom and MinGW might have returned different keycodes for the same keyboard for at least a few keys on Windoze... but I'm not sure. It's a bit blurry now.
Windows keyboard now uses native API and also fixes keycode clashes with unicode chars
And... I'm still not sure why. I mean, I get using the Windows API to read keyboard characters and avoiding Unicode problems, but the Unicode value for Tab is still 9.
This might just be a bug.
-Greg
I don't recall discussing the behaviour of the Tab key specifically, but considering the design and purpose of the entire thing, I'm pretty sure that this is not a bug.
Rather, Derek realized that this change couldn't really be done The Right Way (tm) without a few small breaking changes, so he went forward with those while putting in mitigating measures for those programs that needed backwards compatibility.
Just for that detail, the compatibility become broken.
Derek had intented that it be possible to revert get_key() et al to the old behaviour on systems that supported it. (For TAB specifically, I'd imagine that all systems support this - but you can't set a keycode for the AltGr key if you are using a keyboard that only has one Alt key on the left side, for example.)
On the still unreleased 4.1.0, you can do this by calling console:key_codes() to set the keycodes yourself - this will let you tell get_key() to start returning 9 for tab again. (Or just machine_proc(100, ..) if you prefer.)
8. Re: TAB KEY
- Posted by jimcbrown (admin) Oct 19, 2020
- 1178 views
So why should we be able to distinguish CNTRL+I from the TAB key? The community has spoken. Let's change things back.
If it were possible, I can see it being useful. Some games might want to use TAB to switch between different views (Map Mode, FPS POV, etc) while reserving control+I for some kind of action shortcut (Invite Friend to Battle for example?).
Not saying that this necessarily be the default behaviour, but if we could have a toggle - like console:key_codes() ...
Since the value of TAB as a character is indistinguishable from CNTRL+I, I believe the intention was to give get_key() the ability to distinguish CNTRL+I with TAB keystrokes.
Have you actually tested this though? I no longer have Windoze and can't try it out myself, but based on the implementation I'd expect getting a Control+I with get_key() on that platform to return 1015936.
9. Re: TAB KEY
- Posted by ghaberek (admin) Oct 19, 2020
- 1176 views
Have you actually tested this though? I no longer have Windoze and can't try it out myself, but based on the implementation I'd expect getting a Control+I with get_key() on that platform to return 1015936.
I just tried this using key.ex on Windows 10 with Euphoria 4.1 64-bit and Tab returns 1015936 (0xF8080) while Ctrl+I returns 9.
Now that seems like a bug to me. Shouldn't the default behavior be reversed?
-Greg
10. Re: TAB KEY
- Posted by jimcbrown (admin) Nov 16, 2020
- 1091 views
Have you actually tested this though? I no longer have Windoze and can't try it out myself, but based on the implementation I'd expect getting a Control+I with get_key() on that platform to return 1015936.
I just tried this using key.ex on Windows 10 with Euphoria 4.1 64-bit and Tab returns 1015936 (0xF8080) while Ctrl+I returns 9.
Now that seems like a bug to me. Shouldn't the default behavior be reversed?
Actually, memories are a bit dim, but this might have been my influence. I vaguely remember stating to someone (probably Derek or Jeremy over IRC) that we should default to using Ctrl+I (and Ctrl+J et al) as the defaults since keys like Tab/Return/etc might be mapped elsewhere. I might have said it should be done to be cross-platform, citing some termcap/terminfo oddity (where say the Tab key was configured for some other value but Ctrl+I still worked) or looked at xev on the X Windows System, where the Tab key is specified as keycode 23 or keysym 0xff09. (I almost wonder if the choice of 0xF8080 is intended as some kind of pun over 0xff09 - 08 is above 09, and iirc Derek preferred big endian, hence the swap from 08 to 80.)
Also, I've reread the code and realized that it was intended to behave this way. See below,
(EuChar == 9 && vkey != 73) || // TAB key but not CTRL-I
So it doesn't go through the conversion if Ctrl+I was pressed, only for other tabs.