Re: Arrow keys in informix generally

Sorry this is a little long ... Richard Donkin <richardd@inset.co.uk> writes - > Ron Lees wrote: > > > > I don't know whether its the 'fault' of either SCO or Informix. We have > > the problem using Informix under SCO too, but we also got it when we were > > using ISC rather than SCO and when we were using vi across a network. > > It is actually because of the user interface design, which uses ESC as a > command key in itself, and also as the component of other keys, such as > the cursor keys, transmitting things like <ESC>[A. > > Occasionally, a cursor/function key's characters can be sent to Informix in > two parts, the first being <ESC>. When the first part arrives, the program > has no way of knowing if it is a command key or part of a cursor/function key. > It therefore waits a certain amount of time for the second part, and if none > arrives assumes it is a command key. The problem arises when the waiting time > is less than the delay between the first and second part. > > This happens particularly frequently when > > - auto repeat is used to move the cursor keys (common in novice users > of vi, or in Informix display array etc.), because a large > number of escape sequences are sent at once, and may be broken > up as a result due to I/O buffering. > > - a network is involved, because the delay between first and > second parts can be unpredictable and is usually larger > than with directly connected terminals. The real problem is that whatever interpreter you're running - vi, or a 4gl executable, or Uniplex, for example - has to accept commands and act on them. Function keys transmit *more than 1 char* and the meaning of the group of characters actually sent is mapped to a token (e.g. F1) by curses, or equiv., using the termcap or terminfo libraries. The application knows what to do for that token. Where commands are normal words, they are easily distinguished/delimited by whitespace (as in, "SELECT * FROM foo") and there is no problem even where some commands contain others as substrings (as in, FOR and FOREACH). Where function keys are used as commands, curses can only guess where commands start and finish by looking for gaps in the flow of input characters and, as Richard says, this is often unsatisfactory over a network. Note that the actual characters are unimportant: if my F1 key returns ^AA and my F2 key returns ^AAB, the F2 key can still appear to be F1 followed by the letter B. > [ DBESCWT stuff deleted ] > This is just that, a work-around. It will work in particular cases as > long as delays due to network or whatever do not change in the life of the > system to become bigger than DBESCWT. There is another related problem you may find. On this system, vi is preloaded with macros that map function key return values to the appropriate vi commands: for example, ^[J is typically mapped to dG with the effect that hitting the function key which returns ^[J causes the rest of the file to be deleted. This is just fine, once you know which key does what. However, with these macros in place I can type a normal ^[J (to end insert mode and then join two lines) and delete the rest of the file ... This was unutterably frustrating until I discovered the cause and unmapped the F-keys. I don't believe there is a way of preventing this if the application can receive normal keystrokes rapidly (i.e. on a direct connect line). > The best solution is to do as GNU Emacs does and avoid using <ESC> as a > command key. I'm not sure if this is possible in current versions of > Informix or not, but it is in other 4GLs and is the best option. Also, > I'm not sure if this will cause Informix to wait as long as needed if > only an ESC is received. Maybe someone else can confirm this. As in, "OPTIONS ACCEPT KEY CONTROL-V" or equiv., and it works as described. However, the problem isn't the use of ESC !!! The problem is the multi-char output from the function keys. > If you want your users to be able to press the ESC key, and you have > a customisable keyboard (e.g. via a PC terminal emulator), you can > re-program the ESC key to send a distinct Escape sequence that is > not used by any other keys, which will provide the users with the > same interface but remove the problem. It may not apply in your user environment, but I'd just hate this ! Like pressing the "A" key and getting "Q" back ! It'll also tend to louse up other applications. There are some fixes, but they have other problems. Anyhow, here's some thoughts. Many applications load or reload function keys with default or specific values. Beware of these, particularly if they're all being used on the same screen, they load different values, they don't reset the values on completion and/or they can easily be killed without restoring old values. Very irritating. Often, different applications use different selections from termcap, terminfo and home-brew or PD terminal control libraries. Check fairly carefully that they're reading what you think they are when checking that they're all going to be compatible. To get the application to work, if you can edit it, you can simply specify control keys to do accept, delete, etc: see 7-172, Options, in the Reference Manual. If you define ^N for next, for example, it cannot get split in two network packets Your users may not like this very much, depending on how easy their function keys are to work. I prefer it, since your hands remain on the keyboard. To use the function keys, you can usually load the values you've selected (^P, etc) as the default values on terminal boot, or write something to load them on starting the informix application if they have to be different the rest of the time. Once the OPTIONS values are loaded in the function keys, the keys'll work as usual. If you can't edit the application, edit the informix termcap file (keep a backup) and modify the entry for the terminal (or copy the old entry to a new name, and modify the new-name entry) so that the function keys are stated to return the control codes decided earlier (e.g., F1 is stated to return ^N). Then load the function keys so that they really do return these values. termcap's plain text, and pretty easy to work on. If you use terminfo, which I believe is in the latest informix version out, you'll have to use untic(1) and tic(1) to decompile and recompile the entry. Still pretty easy, so long as you've got the commands. Hope this helps. At least you can cure the problem, tho' the whole thing's a bit of a kludge because of the way curses and the function keys work. -- Cheers - Tony. ********************* LAST FEW DAYS AT THIS ADDRESS ************************ Tony Heskett: theskett@lhr-sys.ssf-sys.dhl.com | Vox: (+44) 81 747 8330 DHL Systems : Kings House, Great West Road, TW8 9HS | Fax: (+44) 81 747 0875