1. problem with wait_key() and arrows
- Posted by james_paige Aug 09, 2011
- 3880 views
I have a euphoria program that I wrote way back in the Euphoria 2.1 days. More recently I have been using it with euphoria 3.x, and now I am trying to use it with 4.x
It has a bunch of text-based menus, and you use the arrow keys to navigate them.
I do all the keyboard input with wait_key() which used to work just fine for arrow keys. The results I get for arrow keys from wait_key() are different than they used to be, depending on which platform I am using.
On Linux, I get multiple keypresses, for example, when I press the up-arrow I get 27, 91, 65. (not as a sequence, as separate keypresses) That is extremely awkward, but I can work around it.
On Windows XP and Windows 7, I get absolutely nothing for arrow keys. That is beyond awkward. I have no idea how to work around that :(
I tested a couple versions, and the Windows-half of this problem seems to have started with version 4.0.3. If I install 4.0.2 instead, then on Windows XP and Windows 7, I get the results I expect from wait_key()
up arrow = 328
down arrow = 336
left arrow = 331
right arrow = 333
As for the Linux arrow keys problem, I don't know when that started. I remember I had it working with an older version of euphoria, but I can't remember which one. 2.5 maybe? I don't know. I mainly run this program on Windows computers, so I had not investigated that angle further
2. Re: problem with wait_key() and arrows
- Posted by euphoric (admin) Aug 09, 2011
- 3749 views
OK, so I'm not the only one! :)
I get no response in wait_key() to arrow key presses with the latest version of Euphoria.
3. Re: problem with wait_key() and arrows
- Posted by mattlewis (admin) Aug 09, 2011
- 3737 views
On Linux, I get multiple keypresses, for example, when I press the up-arrow I get 27, 91, 65. (not as a sequence, as separate keypresses) That is extremely awkward, but I can work around it.
I suspect that this happened back when euphoria stopped using ncurses. I believe this happened with 3.0.
On Windows XP and Windows 7, I get absolutely nothing for arrow keys. That is beyond awkward. I have no idea how to work around that :(
I tested a couple versions, and the Windows-half of this problem seems to have started with version 4.0.3. If I install 4.0.2 instead, then on Windows XP and Windows 7, I get the results I expect from wait_key()
Looking at the code repository, I don't see anything that changed with the implementation of wait_key() between 4.0.2 and 4.0.3. Is there a difference between eui.exe and euiw.exe?
Matt
4. Re: problem with wait_key() and arrows
- Posted by james_paige Aug 09, 2011
- 3714 views
Looking at the code repository, I don't see anything that changed with the implementation of wait_key() between 4.0.2 and 4.0.3. Is there a difference between eui.exe and euiw.exe?
I tested all three of eui euiw and euc and they all seemed to have the same problem.
5. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Aug 10, 2011
- 3627 views
Looking at the code repository, I don't see anything that changed with the implementation of wait_key() between 4.0.2 and 4.0.3. Is there a difference between eui.exe and euiw.exe?
I tested all three of eui euiw and euc and they all seemed to have the same problem.
I'm using windows 7 and eui 4.0.4 and I'm getting key codes for the arrows when using either wait_key() or get_key(). In other words, all seems to be working correctly.
Left = 331
Right = 333
Up = 328
Down = 336
6. Re: problem with wait_key() and arrows
- Posted by euphoric (admin) Aug 10, 2011
- 3651 views
I just tested on my PC here at work and it works fine (arrow keys return values). It might be the keyboard I have at home. I'll check tonight.
7. Re: problem with wait_key() and arrows
- Posted by james_paige Aug 10, 2011
- 3641 views
Where do I get 4.0.4? Is that the same as a nightly build? The latest I see on the downloads page is 4.0.3
I know this can't be related to my keyboard, because I have tested it on 5 different computers, and tested it by installing 4.0.2 (which works) followed by 4.0.3 (which has the problem) on the same computer
8. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Aug 10, 2011
- 3620 views
I know this can't be related to my keyboard, because I have tested it on 5 different computers, and tested it by installing 4.0.2 (which works) followed by 4.0.3 (which has the problem) on the same computer
I just reinstalled 4.0.3 and tested it again, and you're right. None of the special keyboard keys return a value now.
I then reverted to 4.0.4 and everything works again.
9. Re: problem with wait_key() and arrows
- Posted by euphoric (admin) Aug 10, 2011
- 3595 views
I just reinstalled 4.0.3 and tested it again, and you're right. None of the special keyboard keys return a value now.
I then reverted to 4.0.4 and everything works again.
Then that will explain my problem. Up at work I have 4.0.4, and here at home I have 4.0.3... but not for long. :)
10. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Aug 12, 2011
- 3524 views
I'm just speculating here, but it appears that the 4.0.3 build was built as if the EMINGW symbol was defined for keystroke handling, as that doesn't check for extended keyboard characters. Whereas the Watcom (non-EMINGW) explicitly caters for extended keys plus combinations for SHIFT/CTRL/ALT.
11. Re: problem with wait_key() and arrows
- Posted by achury Aug 17, 2011
- 3308 views
If the originalk program was running on DOS, you must to know that WINDOWS have different codes for the "grey" keys around the num pad (on old keyboards used to be grey).
A confussion caused on Eu3.1 is that key.ex don't report what interpreter is used. The bat file "KEY.BAT" uses ex.exe. If you run on the same machine "ex key.ex" will not get the same keys running "exw key.ex".
This is an old problem, no idea when first appear
12. Re: problem with wait_key() and arrows
- Posted by mattlewis (admin) Sep 17, 2011
- 3171 views
I'm not sure what the best way is to deal with arrow keys, cross platform. Basically, it appears that in Linux, we're getting ANSI Escape Sequences. Here's some code that should allow cross platform behavior, arrow key-wise for get_key(). wait_key() could probably use a similar work around.
public constant VK_LEFT = 331, VK_RIGHT = 333, VK_UP = 328, VK_DOWN = 336, $ ifdef not WINDOWS then sequence buffer = {} override function get_key() if length(buffer) then integer c = buffer[1] buffer = remove( buffer, 1 ) return c end if integer c = eu:get_key() if c = 27 then integer d = eu:get_key() if d = '[' then integer e = eu:get_key() switch e do case 'A' then return VK_UP case 'B' then return VK_DOWN case 'C' then return VK_RIGHT case 'D' then return VK_LEFT case else buffer = {d, e} end switch else buffer = {d} end if end if return c end function end ifdef while 1 do integer c = get_key() if c = '\n' then exit elsif c != -1 then ? c end if end while
Matt
13. Re: problem with wait_key() and arrows
- Posted by jimcbrown (admin) Sep 17, 2011
- 3165 views
I'm not sure what the best way is to deal with arrow keys, cross platform. Basically, it appears that in Linux, we're getting ANSI Escape Sequences.
Perhaps we should consider get_key() and wait_key() low-level enough that they return platform specific values.
But then we should also enhance your workaround into a better new_key() and new_wait_key() (perhaps to go into std/console.e) and in that stdlib file have the Euphoria code define and return a cross-platform set of symbolic keycodes.
That way, people who need to see the low level values (or those who don't care what they get and only want speed - e.g. a wait_key() to pause the program) can do so, but those who want the ease of knowing what key is pressed regardless of platform will be able to get that from the stdlib as well.
IIRC, even old versions of Euphoria (e.g. 2.3) never had a unified set of keycode values, so adding this into the stdlib would be a first.
14. Re: problem with wait_key() and arrows
- Posted by mattlewis (admin) Sep 17, 2011
- 3134 views
Perhaps we should consider get_key() and wait_key() low-level enough that they return platform specific values.
But then we should also enhance your workaround into a better new_key() and new_wait_key() (perhaps to go into std/console.e) and in that stdlib file have the Euphoria code define and return a cross-platform set of symbolic keycodes.
That way, people who need to see the low level values (or those who don't care what they get and only want speed - e.g. a wait_key() to pause the program) can do so, but those who want the ease of knowing what key is pressed regardless of platform will be able to get that from the stdlib as well.
IIRC, even old versions of Euphoria (e.g. 2.3) never had a unified set of keycode values, so adding this into the stdlib would be a first.
In those days, euphoria was using ncurses, which does its own translation. You're correct, however, that the values were different from windows key codes.
I doubt that speed is really a big issue here. Either way, both of these are built-in (well, wait key is a MACHINE_FUNC, but same thing). I guess that for wait_key(), we'd have to differentiate between actually typing ESC vs getting the escape sequences, but I don't think that's a big problem.
But, yes, the "low level" aspect is part of why I'm not really sure how to proceed. I think the code I posted is basically something that people can use until a better, more permanent solution is devised. And that code only captures the arrow codes.
Matt
15. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Sep 17, 2011
- 3112 views
Perhaps we should consider get_key() and wait_key() low-level enough that they return platform specific values.
But, yes, the "low level" aspect is part of why I'm not really sure how to proceed. I think the code I posted is basically something that people can use until a better, more permanent solution is devised. And that code only captures the arrow codes.
I I've completed the rewrite of get_key() for Windows. It now uses the Windows API regardless of which compiler is used. In doing so, the keycode values have been set in stone by encoding them into the be_w.c file. I have no idea what should be done for Unix, but probably the same sort of thing. That is, get_key() should return the 'cooked' keycode rather than have a routine in console.e convert ANSI escape sequences.
However, I might be suggesting that the keycodes be changed from previous Euphoria releases as they sort of clash with a subset of unicode characters.
16. Re: problem with wait_key() and arrows
- Posted by mattlewis (admin) Sep 17, 2011
- 3137 views
However, I might be suggesting that the keycodes be changed from previous Euphoria releases as they sort of clash with a subset of unicode characters.
Unicode entry is its own special thing, though, isn't it? There are lots of special input mode thingies for doing this, aren't there?
Matt
17. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Sep 17, 2011
- 3117 views
Unicode entry is its own special thing, though, isn't it? There are lots of special input mode thingies for doing this, aren't there?
Yes, but the Windows API can return Unicode characters to the application if that's what's been keyed in by the user. This means that it is possible to get some values above 256 returned. So I'm thinking of making the keycodes for the special keys (arrows, function, etc ...) negative values.
If people use constants defined in the library it won't be so bad but I guess most existing code would need an update.
public constant VK_LEFT = -331, VK_RIGHT = -333, VK_UP = -328, VK_DOWN = -336, $
18. Re: problem with wait_key() and arrows
- Posted by jeremy (admin) Sep 17, 2011
- 3139 views
You said key codes are set in stone in be_w.c, I didn't look at the code but I wonder if they could be made configurable at runtime? i.e.
ifdef WINDOWS then set_keycodes(...) els....
Not sure any of it makes sense. Just thinking aloud. That may make it easier as well to configure for exotic terminals in the Unix world as well?
Jeremy
19. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Sep 17, 2011
- 3127 views
You said key codes are set in stone in be_w.c, I didn't look at the code but I wonder if they could be made configurable at runtime? i.e.
ifdef WINDOWS then set_keycodes(...) els....
Not sure any of it makes sense. Just thinking aloud. That may make it easier as well to configure for exotic terminals in the Unix world as well?
Just like have a terminfo file ... 
...
But yes, I can change this to be loadable at runtime, with a default set hard coded. There probably should be a command line switch (and/or environment symbol) to specify which virtual key set you want to run with too.
20. Re: problem with wait_key() and arrows
- Posted by andi49 Sep 17, 2011
- 3116 views
You said key codes are set in stone in be_w.c, I didn't look at the code but I wonder if they could be made configurable at runtime? i.e.
ifdef WINDOWS then set_keycodes(...) els....
Not sure any of it makes sense. Just thinking aloud. That may make it easier as well to configure for exotic terminals in the Unix world as well?
Just like have a terminfo file ... ...
But yes, I can change this to be loadable at runtime, with a default set hard coded. There probably should be a command line switch (and/or environment symbol) to specify which virtual key set you want to run with too.
hallo
i did some testing on Win 8 (Developer Version) Euphoria 4.0.3 seems to work. I tried some of my own work and they seems to work okay, (everything GUI-Based)
But there are problems in text mode (same with cmd or powershell). ed.ex starts up, but the arrow keys are not recognized (not even den ESC key) so it is not usable. I did some testing with wait_key() - no response for the arrowkeys.
Also Win 8 is only a preview now and a lot of things are subject to change. Keyboardhandling should be made more Platform indepented (if it is possible).
Bye Andreas
21. Re: problem with wait_key() and arrows
- Posted by jimcbrown (admin) Sep 17, 2011
- 3094 views
You said key codes are set in stone in be_w.c, I didn't look at the code but I wonder if they could be made configurable at runtime? i.e.
ifdef WINDOWS then set_keycodes(...) els....
Not sure any of it makes sense. Just thinking aloud. That may make it easier as well to configure for exotic terminals in the Unix world as well?
Jeremy
We still have the problem of needing to have good defaults. This is not a bad idea, but a user should be able to use new_key() et al cross-platform without having to worry about this stuff.
22. Re: problem with wait_key() and arrows
- Posted by jimcbrown (admin) Sep 17, 2011
- 3116 views
Unicode entry is its own special thing, though, isn't it? There are lots of special input mode thingies for doing this, aren't there?
Yes, but the Windows API can return Unicode characters to the application if that's what's been keyed in by the user. This means that it is possible to get some values above 256 returned. So I'm thinking of making the keycodes for the special keys (arrows, function, etc ...) negative values.
I have a UTF-8 terminal set up, so I can get raw UTF-8 from get_key() and wait_key(). I can easily forsee UTF-16 and even UTF-32 terminals.
23. Re: problem with wait_key() and arrows
- Posted by petelomax Sep 18, 2011
- 3108 views
Having part of the i/o system in hll could be a problem:
? get_key() ? gets(0)
If the user keys Esc, "hello" then the hll could buffer a 'h' and the low-level gets return "ello".
Since you've put "ifdef not WINDOWS then" around that code it would mean the behavior differs between platforms.
Regards, Pete
24. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Sep 18, 2011
- 3100 views
Having part of the i/o system in hll could be a problem:
? get_key() ? gets(0)
If the user keys Esc, "hello" then the hll could buffer a 'h' and the low-level gets return "ello".
Since you've put "ifdef not WINDOWS then" around that code it would mean the behavior differs between platforms.
Regards, Pete
Having ESC sequences processed in Unix-type systems will cause problems regardless of whether this is done in a library or done in the eui executable. In the example you've given, in Unix-type systems we would see ESC-h followed by "ello" and in Windows we would see ESC followed by "hello".
See Wikipedia to get an idea how complex processing escape sequences can get.
25. Re: problem with wait_key() and arrows
- Posted by DerekParnell (admin) Sep 18, 2011
- 3151 views
i did some testing on Win 8 (Developer Version)
But there are problems in text mode (same with cmd or powershell).
This is not a Windows issue but a problem with building Euphoria using MingW. Building using Watcom will make the arrow keys work but not when building with MingW.
I'm currently working on fixing this.
26. Re: problem with wait_key() and arrows
- Posted by jimcbrown (admin) Sep 18, 2011
- 3109 views
Having part of the i/o system in hll could be a problem:
? get_key() ? gets(0)
If the user keys Esc, "hello" then the hll could buffer a 'h' and the low-level gets return "ello".
Since you've put "ifdef not WINDOWS then" around that code it would mean the behavior differs between platforms.
Regards, Pete
Having ESC sequences processed in Unix-type systems will cause problems regardless of whether this is done in a library or done in the eui executable. In the example you've given, in Unix-type systems we would see ESC-h followed by "ello" and in Windows we would see ESC followed by "hello".
See Wikipedia to get an idea how complex processing escape sequences can get.
All the more reason to get this handled in either the stdlib or in the backend. We shouldn't have to deal with solving this problem every time someone wants to write a console app.
