ESC Key very slow

[Anonymous]

I'm exploring the possibility of using GNU Cobol to port/uplevel an ancient RM/COBOL application. The application is quite interactive via DISPLAY/ACCEPT w/o using a SCREEN SECTION. I'm trying to make this a "port" as much a possible - specifically making it operate as close to the original as possible.

So far I've been able to easily see how I might deal with the screen, function keys, etc., but I've run in to a stumbling block with the Escape key. I did figure out how to make it work at all, but it's ridiculously slow. Function keys respond/are recognized instantly, but Escape takes about half a second or so to be recognized. This is going to cause some issues with my client. It seems to happen both in cygwin (2.1) (ncurses?) and with a native windows build of 2.0 using pdcurses.

Any ideas?

[Brian Tiffin]

Try

ESCDELAY=25 ./tui-program

Export an environment variable, ESCDELAY=in-milliseconds

See if that has any effect with your versions. If it does, it may also exhibit the rare miss of proper cursor or function key detection, giving a three character squiggly string after an unintentional escape.

Otherwise, old school, means digging around in stty settings and terminfo files and, well, yikes, voodoo. :-)

Looked more, it might be better to try

CALL "set_escdelay" USING BY VALUE 25 ON EXCEPTION CONTINUE END-CALL

but I'm not sure if that works before curses init, it should.

Cheers,
Brian

[Simon Sobisch]

Brians first variant will only work for cygwin/MinGW.

It seems that ESCDELAY is not available in pdcurses at all (at least it doesn't have an exported function or static var for it).

Just tested with pdcurses builds (OpenCOBOL 1.1 MinGW and GNU Cobol 2.0 Visual Studio, different pdcurses versions) on Win7 with

::cmd
set COB_SCREEN_ESC=Y
set COB_SCREEN_EXCEPTIONS=Y
./mytestprog

I got all function keys immediately (both with/without ON EXCEPTION clause for ACCEPT) - no matter if/how ESCDELAY is set.

@Brian: please investigate this further (meaning try and check the results ;-)) as I wonder if it would be useful to change libcob/screenio.c to

::patch
+#ifndef    HAVE_LIBPDCURSES

+   /* set the ESCDELAY via the environment before initscr is called; this
+      means that it will be ignored by curses implementations that don't
+      support it */
+   if (getenv ("ESCDELAY")) == NULL) {
+       setenv("ESCDELAY", "25", 0);
+   }
+#endif
    if (!initscr ()) {
        cob_runtime_error (_("Failed to initialize curses"));
        cob_stop_run (1);
    }

Simon

[Anonymous]

Thanks, I'll try those suggestions a bit later and post back my result.

Bill

[Anonymous]

Just got a chance to try this under cygwin. The first variation Brian suggested works well, but the second doesn't work for me. But at least I have a working solution - thanks a lot.

Bill

[Brian Tiffin]

Cheers,
Brian

[Simon Sobisch]

@Brian: Do you investigate the suggested change to libcob/screenio.c (especially the pro/con)?
@Bill: Good that you have a working solution. Î suggest to get a SF login for further posts. Please tell us your conversion story (issues you had, how you solved them, ...)

Simon

[Brian Tiffin]

Not yet, but will. I'm cluttering a Fedora libvirt setup with various virtual machines. Pretty amazing technology, but anyway, it'll allow for more comprehensive testing.

Cheers,
Brian

[Bruce Martin]

if you have found this site (http://modern.ie/en-us/virtualization-tools) yet but Microsoft provides Virtual Machines for Testing internet Explorer on various versions of Windows. So If you want to test you Cobol generated HTML pages with IE.