Re: DBESCWT

Peter Lancashire wrote: > June Tong wrote: > > > > Gregory King wrote: > > > > > I have read the FAQ, and I know what DBESCWT does. The question is, > > > what is the default value? > > > > 1 second, I think. > > > > June > > -- > > june_t@hotmail.com > > Grounded in Palo Alto, living on Cafe Mocha > Yes, it is. Other values (integers only) are for the truly desperate as > it makes the user wait (for $ESCWAIT seconds) for 4GL to respond to the > pressing of an ESC key. > > A way to speed it all up is not to use the ESC key at all but a function > key which sends something else right after Esc. You need to change the > OPTIONS to make that other key the ACCEPT key. Thanks for the input Peter (and other posters of replies). One second is what we guessed (through repeated trials) the default to be, but we wanted to make sure. Anyway, with regards to the function keys, the function keys ARE the problem we are trying to fix!! What is happening is that users coming in over a X.25 network are having packet fragmentation where the subsequent characters of a function key sequence are not making it in the same packet as the ESC character, and thus the ESC is being processed alone (as an accept) and then the rest of the keys hit and are treated as menu instructions. As for it affecting other users, we are simply adding the environment variable only to those users coming in via X.25. Using an intelligent login script that checks the origin of the user, this is not difficult. However, bumping DBESCWT up to 2 seconds is still not resolving the problem, and it causing us to question whether we have correctly diagnosed the problem. It is difficult to believe that with an average packet delay of 400ms, that is could be an additional 1600ms for the next packet to arrive on a regular basis..... We will try 3 seconds, but are now looking around at other possibilities. Thanks again.