Escape key problem with 4gl 7.30

We just upgraded a major application from 4gl 7.2x to 7.3. Everything seems to work well except for the escape key which now completely aborts the application instead of exiting the current statement (input, prompt etc.) as intended. The problem is only with the compiler version, not RDS. There is only one options statement at the beginning of the program which looks like this: options form line first, message line last, comment line last-1, prompt line last, error line last, field order unconstrained, input attribute (reverse), display attribute (bold,blink,underline), help key f1, insert key insert, delete key delete, next key nextpage, previous key prevpage, accept key f2 The accept key has been assigned to f2 leaving the escape key unassigned. All user interaction statements (input, prompt etc.) trap for the escape key with an on key clause, e.g. "on key (escape,f8) exit input". As mentioned, the problem occurs only with the compiler version. The escape key causes the program to terminate, no matter how deeply the user is entrenched in menus and forms. The exit status is 1, similar to the quit key but without any interrupt code. The version is I4gl 7.30.UC1 on hp-ux 10.20. Any solutions are greatly welcome. Thanks, John H. Frantz Sent via Deja.com http://www.deja.com/ Before you buy.

A quick update on the problem. Apparently the escape key (which does in fact send the escape character) always aborts the 4gl program, even if it is designated as the accept key. Can anyone confirm this problem with I4gl 7.30.UC1 on hp-ux 10.20? Thanks, John In article <8hgjfv$6va$1@nnrp1.deja.com>, john_h_frantz@my-deja.com wrote: > We just upgraded a major application from 4gl 7.2x to 7.3. > Everything seems to work well except for the escape key which > now completely aborts the application instead of exiting the > current statement (input, prompt etc.) as intended. > > The problem is only with the compiler version, not RDS. > > There is only one options statement at the beginning of the > program which looks like this: > > options > form line first, > message line last, > comment line last-1, > prompt line last, > error line last, > field order unconstrained, > input attribute (reverse), > display attribute (bold,blink,underline), > help key f1, > insert key insert, > delete key delete, > next key nextpage, > previous key prevpage, > accept key f2 > > The accept key has been assigned to f2 leaving the escape key > unassigned. All user interaction statements (input, prompt > etc.) trap for the escape key with an on key clause, e.g. "on > key (escape,f8) exit input". > > As mentioned, the problem occurs only with the compiler > version. The escape key causes the program to terminate, no > matter how deeply the user is entrenched in menus and forms. > The exit status is 1, similar to the quit key but without any > interrupt code. > > The version is I4gl 7.30.UC1 on hp-ux 10.20. > > Any solutions are greatly welcome. > > Thanks, > John H. Frantz > > Sent via Deja.com http://www.deja.com/ > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy.

Question, what does "stty -a" report are the 'intr' and 'quit' characters? Could it be Escape (will show as ^[ or ^{ depending on your system)? Then execute 'stty intr ^c' or 'stty quit ^\\' (control backslash) which are the more usual values. Art S. Kagel john_h_frantz@my-deja.com wrote: > > A quick update on the problem. Apparently the escape key (which does in > fact send the escape character) always aborts the 4gl program, even if > it is designated as the accept key. > > Can anyone confirm this problem with I4gl 7.30.UC1 on hp-ux 10.20? > > Thanks, > John > > In article <8hgjfv$6va$1@nnrp1.deja.com>, > john_h_frantz@my-deja.com wrote: > > We just upgraded a major application from 4gl 7.2x to 7.3. > > Everything seems to work well except for the escape key which > > now completely aborts the application instead of exiting the > > current statement (input, prompt etc.) as intended. > > > > The problem is only with the compiler version, not RDS. > > > > There is only one options statement at the beginning of the > > program which looks like this: > > > > options > > form line first, > > message line last, > > comment line last-1, > > prompt line last, > > error line last, > > field order unconstrained, > > input attribute (reverse), > > display attribute (bold,blink,underline), > > help key f1, > > insert key insert, > > delete key delete, > > next key nextpage, > > previous key prevpage, > > accept key f2 > > > > The accept key has been assigned to f2 leaving the escape key > > unassigned. All user interaction statements (input, prompt > > etc.) trap for the escape key with an on key clause, e.g. "on > > key (escape,f8) exit input". > > > > As mentioned, the problem occurs only with the compiler > > version. The escape key causes the program to terminate, no > > matter how deeply the user is entrenched in menus and forms. > > The exit status is 1, similar to the quit key but without any > > interrupt code. > > > > The version is I4gl 7.30.UC1 on hp-ux 10.20. > > > > Any solutions are greatly welcome. > > > > Thanks, > > John H. Frantz > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > > > > Sent via Deja.com http://www.deja.com/ > Before you buy.

Thanks Art for the effort. "stty -a" reports this: intr = ^C; quit = ^\\; erase = ^H; kill = ^U eof = ^D; eol = ^@; eol2 <undef>; swtch <undef> stop = ^S; start = ^Q; susp <undef>; dsusp <undef> It looks pretty standard to me. The interrupt key is deferred in the 4gl program but not the quit key which we have mapped to F12 and is used as a "fire escape" exit. The shell script that launches the program contains 'trap "clear" 3' which causes the screen to clear when F12 (the quit key) is hit. The screen is not cleared when escape is hit. By the way, the escape key does send an escape character, ala "^[". Thanks again, John H. Frantz john@rl.is In article <393CF3A5.B1BC3A78@bloomberg.net>, kagel@bloomberg.net wrote: > Question, what does "stty -a" report are the 'intr' and 'quit' characters? > Could it be Escape (will show as ^[ or ^{ depending on your system)? Then > execute 'stty intr ^c' or 'stty quit ^\\' (control backslash) which are the > more usual values. > > Art S. Kagel > > john_h_frantz@my-deja.com wrote: > > > > A quick update on the problem. Apparently the escape key (which does in > > fact send the escape character) always aborts the 4gl program, even if > > it is designated as the accept key. > > > > Can anyone confirm this problem with I4gl 7.30.UC1 on hp-ux 10.20? > > > > Thanks, > > John > > > > In article <8hgjfv$6va$1@nnrp1.deja.com>, > > john_h_frantz@my-deja.com wrote: > > > We just upgraded a major application from 4gl 7.2x to 7.3. > > > Everything seems to work well except for the escape key which > > > now completely aborts the application instead of exiting the > > > current statement (input, prompt etc.) as intended. > > > > > > The problem is only with the compiler version, not RDS. > > > > > > There is only one options statement at the beginning of the > > > program which looks like this: > > > > > > options > > > form line first, > > > message line last, > > > comment line last-1, > > > prompt line last, > > > error line last, > > > field order unconstrained, > > > input attribute (reverse), > > > display attribute (bold,blink,underline), > > > help key f1, > > > insert key insert, > > > delete key delete, > > > next key nextpage, > > > previous key prevpage, > > > accept key f2 > > > > > > The accept key has been assigned to f2 leaving the escape key > > > unassigned. All user interaction statements (input, prompt > > > etc.) trap for the escape key with an on key clause, e.g. "on > > > key (escape,f8) exit input". > > > > > > As mentioned, the problem occurs only with the compiler > > > version. The escape key causes the program to terminate, no > > > matter how deeply the user is entrenched in menus and forms. > > > The exit status is 1, similar to the quit key but without any > > > interrupt code. > > > > > > The version is I4gl 7.30.UC1 on hp-ux 10.20. > > > > > > Any solutions are greatly welcome. > > > > > > Thanks, > > > John H. Frantz > > > > > > Sent via Deja.com http://www.deja.com/ > > > Before you buy. > > > > > > > Sent via Deja.com http://www.deja.com/ > > Before you buy. > Sent via Deja.com http://www.deja.com/ Before you buy.