[GRASSLIST:5657] Re: arrow keys not working

[Paul Dymecki]

Hitting the enter key moves you to the next selection, at least on windows 
Paul
----- Original Message ----- 
From: "Glynn Clements" <glynn.clements at virgin.net>
To: "Wayne Gibson" <gibson at coas.oregonstate.edu>
Cc: <grasslist at baylor.edu>
Sent: Monday, February 24, 2003 2:23 PM
Subject: [GRASSLIST:5656] Re: arrow keys not working


> 
> Wayne Gibson wrote:
> 
> > After compiling on a SUN, the cursor keys are not working in the
> > window where the user interactively can set LOCATION, MAPSET, and
> > DATABASE. I believe this is generated from "etc/set_data". By the
> > way, this is the same program that experienced compiling problems
> > before due to the curses library and since fixed (at least I thought
> > so).
> 
> Look at the HAVE_KEYPAD line in src/include/config.h. If the macro is
> undefined, then your curses library doesn't support the use of cursor
> keys (at least, configure failed to detect the keypad() function). If
> the macro is defined, then either it's a bug in the curses library, or
> xterm's termcap/terminfo entry is broken.
> 
> BTW, Ctrl-K should have the same effect as the up-arrow key, Ctrl-L
> the same effect as the right-arrow key, and Return/LineFeed the same
> as the down-arrow key; there isn't an exact equivalent to the
> left-arrow key.
> 
> > After I enter <ESC><ENTER> and proceed to working in the GRASS
> > terminal window, then the cursor keys start working again.
> 
> Bash doesn't use curses; it has it's own ad-hoc mechanism for handling
> extended keys.
> 
> GRASS uses the standard curses interface, i.e. it calls keypad() to
> enable the cursor keys, then processes the extended codes (KEY_LEFT
> etc) which the curses library should generate for extended keys.
> 
> If curses fails to process the keys correctly, then they won't work.
> 
> -- 
> Glynn Clements <glynn.clements at virgin.net>
>