1. TAB KEY

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

new topic     » topic index » view message » categorize

2. Re: TAB KEY

achury said...

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.

achury said...

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

new topic     » goto parent     » topic index » view message » categorize

3. Re: TAB KEY

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

In software engineering, when developing computer programs or storing and manipulating data in files, the Tab character is often used for indentation purposes to help guide the flow of reading and add semantic structure to the code or data. Some programmers and programming languages prefer the usage of multiple whitespace characters instead for that purpose. Because of this, many text editors have an option that makes the tab key insert the number of whitespace characters that a tab character is set to be equivalent to (by default mostly four).

Tab characters

The most known and common tab is a horizontal tabulation (HT) or character tabulation, which in ASCII has the decimal character code of 9, and may be referred to as Ctrl+I or ^I. In C and many other programming languages the escape code \t can be used to put this character into a string constant. The horizontal tab is usually inserted when the Tab key on a standard keyboard is pressed.

A vertical tabulation (VT) also exists and has ASCII decimal character code 11 (Ctrl+K or ^K), escape character \v.

In EBCDIC the code for HT is 5. VT is 11 (coincidentally the same as in ASCII).

And near the end of the same article wikipedia says about TAB on unicode

The Unicode code points for the (horizontal) tab character, and the more rarely used vertical tab character are copied from ASCII [14]

U+0009 <control-0009> (CHARACTER TABULATION, horizontal tabulation (HT), tab)
U+000B <control-000B> (LINE TABULATION, vertical tabulation (VT))

The tab characters can be graphically represented by special symbols:

U+2409 ␉ SYMBOL FOR HORIZONTAL TABULATION
U+240B ␋ SYMBOL FOR VERTICAL TABULATION

Unicode also has characters for the symbols to represent or be printed on the tab key [15]

U+21B9 ↹ LEFTWARDS ARROW TO BAR OVER RIGHTWARDS ARROW TO BAR (tab with shift tab)
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

new topic     » goto parent     » topic index » view message » categorize

4. Re: TAB KEY

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

new topic     » goto parent     » topic index » view message » categorize

5. Re: TAB KEY

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.

new topic     » goto parent     » topic index » view message » categorize

6. Re: TAB KEY

SDPringle said...

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

new topic     » goto parent     » topic index » view message » categorize

7. Re: TAB KEY

achury said...

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

ghaberek said...

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.

ghaberek said...

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.

ghaberek said...

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.

achury said...

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

new topic     » goto parent     » topic index » view message » categorize

8. Re: TAB KEY

SDPringle said...

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

SDPringle said...

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.

new topic     » goto parent     » topic index » view message » categorize

9. Re: TAB KEY

jimcbrown said...

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

new topic     » goto parent     » topic index » view message » categorize

10. Re: TAB KEY

ghaberek said...
jimcbrown said...

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.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu