Re: TAB KEY

new topic     » goto parent     » topic index » view thread      » older message » newer message
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 thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu