|
Just as an example:
Identification Division.
Program-Id. 'testprog'.
Environment Division.
Configuration Section.
Special-Names.
Crt Status Is Keyboard-Status
Cursor Is Cursor-Position.
Data Division.
The later in working storage......
Working-Storage Section.
1 Keyboard-Status.
3 Accept-Status Pic 9.
3 Filler Pic X.
3 System-Use Pic X.
3 Function-Key Pic X.
1 Cursor-Position.
3 Cursor-Row Pic 9(2) Value 1.
3 Cursor-Column Pic 9(2) Value 1.
Check values after Accept.
Values may vary depending on the terminal software you are using.
Xterm, Gnome, Putty and so on....... For example, gnome on Ubuntu
will hijack F1, so I always use Xterm.
I also found a script to adjust these values......
#!/bin/sh
# vax
# 09-17-96 Bob Ess - initial creation
# 09-26-96 Shig Katada - Additional keybindings
#
# Script file to incorporate keybindings
and command line
# options for connecting to a VAX node
# Usage statement
Usage(){
echo
echo " Usage : vax -options"
echo
echo " Options: -80 for 80 column terminal"
echo " -132 for 132 column terminal"
echo " -fg colorname"
echo " -bg colorname"
echo " -fn fontname"
echo " -fb bold fontname"
echo " -host [altair] [devel] [leonis]
[castor]"
echo ""
echo " Example: \"vax -80 -fg white -bg black -fn
9x15 -fb 9x15b -host castor\""
echo " Starts a VAX session with an 80
column terminal"
echo " with a black background, white
foreground, a normal"
echo " font of 9x15 and a bold font of
9x15b, and connects"
echo " to the node 'castor'"
echo
echo " If you need additional help,
please call Workstation"
echo " Services at x92396."
echo
exit 1
}
# Default to a black foreground with a white background.
what happened in Benghazi
# Use the 9x15 and 9x15bold fonts. Connect to castor by
default.
#
FG=black
BG=white
HOST=localhost
FONT=10x20
BFONT=10x20
COLS=84
# Parse the command line arguments
#
while [ $# != 0 ];
do
case $1 in
-80) COLS=84
FONT=spc12x24c
BFONT=spc12x24b
shift
;;
-132) COLS=132
FONT=9x15
BFONT=9x15b
shift
;;
-fg) shift
FG=$1
shift;;
-bg) shift
BG=$1
shift;;
-fn) shift
FONT=$1
shift;;
-fb) shift
BFONT=$1
shift;;
-host) shift
HOST=$1
shift;;
-help) Usage;;
*) Usage;;
esac
done
xterm -title "GNU-COBOL " -sb -sl 1200 -geo ${COLS}x30
-fg ${FG} -bg ${BG} \
+cm -cr red -fn ${FONT} -fb ${BFONT} -xrm \
'XTerm*VT100.translations: #override \n\
<Key>F1: string(0x1b)
string("OP") \n\
<Key>F2: string(0x1b)
string("OQ") \n\
<Key>F3: string(0x1b)
string("OR") \n\
<Key>F4: string(0x1b)
string("OS") \n\
<Key>F11: string(0x1b)
string("[23~") \n\
<Key>F12: string(0x1b)
string("[24~") \n\
Button1<Btn2Up>: ignore()' \ &
On 12/15/2014 04:17 PM, Scott McKellar wrote:
How can I correct the behavior of ACCEPT when reading the keyboard via ncurses?
On my own computer at home (Kubuntu 10.4 on amd64, accessed via an xterm session), ACCEPT appears to behave as expected, although I haven't tested exhaustively. That is, the value returned in COB-CRT-STATUS agrees with the documentation.
However when I run the same test program at work (Red Hat on amd64, accessed via putty from Windows 7), some of the keys misbehave.
Here's my test program:
IDENTIFICATION DIVISION.
PROGRAM-ID. cob_fld.
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
01 in-fld pic x(6).
01 out-fld pic x(6).
PROCEDURE DIVISION.
0000-MAINLINE.
SET ENVIRONMENT 'COB_SCREEN_EXCEPTIONS' TO 'Y'.
SET ENVIRONMENT 'COB_SCREEN_ESC' TO 'Y'.
DISPLAY 'Hello, Keyboard!' at line 1 column 1.
*> Endless loop; terminate with ctrl-C
perform forever
ACCEPT in-fld LINE 2 COL 1
move in-fld to out-fld
display out-fld at line 3 column 1
display cob-crt-status at line 4 column 1
end-perform.
stop run.
In both environments I compile with "cobc -x cob_fld.cob" using GnuCOBOL 1.1, built from source with no special options. In both environments the value of $TERM is "xterm".
On the Red Hat box, most of the keys work as expected, but function keys 1 through 4 act very strangely.
Suppose I enter "foobar" into the entry field and then press F1. The program displays "foobar" in the output field, as expected, but then replaces the contents of the input field with "[11~". Thereafter it behaves as if I had typed those weird characters myself. The value returned in COB-CRT-STATUS is 2005, which is supposed to be denote the Escape key (and when I use the Escape key, that's the value I get.)
The F2, F3, and F4 keys give similar results, except that the replacement strings are "[12~", "[13~", and "[14~", respectively. The higher-numbered F keys work as expected.
I *think* what's happening is that my putty client encodes the F keys as an ESC character followed by "[nn~", where "nn" varies with the number of the F key. However for some reason the first four aren't recognized properly. Ncurses sees the ESC and treats it as such, and then treats the next four characters as literal keypresses.
I know that F1 works as expected in vim, so the putty encoding seems to work in that context. vim uses the termcap database, as I understand it, whereas ncurses usually uses terminfo.
So I suspect there's a problem in the terminfo database. Never having ventured into the deep voodoo of terminfo, I don't know how to approach it. I don't even know what the right questions are, nor what to ask of our system administrators, who will probably be the ones to fix it.
Any suggestions?
Scott McKellar
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
|