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).
After I enter <ESC><ENTER> and proceed to working in the GRASS terminal window,
then the cursor keys start working again.
As directed in an earlier discussion, the "TERMLIB" variable was commented out
in "src/CMD/head/head", and I'm using the ncurses library.
In the .grassrc5 file the setting for term is
TERM: xterm
I've also tried a variety of other terminals available (xterm-sun, xterms-sun,
xterm-vt220, ...) but nothing works right in the "set_data" window.
Thanks,
Wayne Gibson
-----------------------
Wayne Gibson
Oregon State University
gibson@coas.oregonstate.edu
(541) 737-5696
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@virgin.net>
Hitting the enter key moves you to the next selection, at least on windows
Paul
----- Original Message -----
From: "Glynn Clements" <glynn.clements@virgin.net>
To: "Wayne Gibson" <gibson@coas.oregonstate.edu>
Cc: <grasslist@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@virgin.net>