Summary of received responses

I'm finally getting around to summarizing the responses to my request for information last week.

We're using ORACLE v.6.0.34.2.1, SQL*Forms v.3.0.16.8.1 on a HP/UX 9000 Series 800. As terminals, we use vt220 (actually something called pctcp if that means anything to anyone?) (on PCs) and hpterm.

I'm trying to set up a universal (uniform) key mapping for Forms so that no matter what kind of terminal you're on, the function keys remain the same. I know this subject has come up a few times in this group, and I've even got copies of those dORACLE*Terminal handbook.

I've tried the *u.r files which exist (in $oracle_home/forms30/admin/resource), i.e. att600u.r, att730u.r, vt100u.r, vt220u.r, etc., but they don't work. That is, a few keys work, but many don't.

So, I tried creating my own resource file. I copied oraterm.r, renamed it to karenterm.r, and in it copied the device vt220, naming it pctcp. I altered karenterm.r by changing the escape sequences under Device Key Definition. (I got the escape sequences by pressing ctrl-v then the key in the vi editor.)

Again, the problem is that some keys work and some don't. The function keys 1 thru 4 work on the pc and on hpterm but I can't get f5 thru 58 to work on the pc (they work on hpterm).

I've kept the keys (1) to only those which are common to both the hp and to the pc and (2) have tried to make the functions based on the function keys, similar to WordPerfect (e.g. F1 is List, Ctrl-F1 is Menu, Shift-F1 is Block Menu, etc.), so that I could use a template on the keyboard. Number (2) is not essential, of course, but number (1) is.

Does anyone have any general information and/or tips on things I could check for?

1. The first person said that the only way to make a universal key mapping was to use the block menu (operates like Lotus 1-2-3, each menu choice is activated by one letter). "That way you only neen to universally map the block menu key to the same thing on all terminals, like <control>G. At first this seems slower that function keys, however with a little practice..."

   I thought that sounded like a good idea, but we just had our hearts    set on those function keys, so I kept plugging away.

2) The next person told me that he used HP terminals that emulate vt220

   and pc's that use kermit 3.1 that also emulate vt220. He said they    DO use shift, ctrl and alt with the function keys f1-f10! But he    pointed out that "regardless of whether you're trying to connect to    Oracle to it, the keys must first, of course, respond and send something    back." If not, he suggested trying another emulation.

   That seemed to be our problem: the keys weren't responding.

3) The next suggestion was to look at the "initialization sequence.

   It may be sending out a sequence which is forcing the terminal into    true vt100 emulation (which only has f1 thru f4), then another sequence    in the termination which does the reverse." The writer has been using    customized vt100 on wyse terminals and sqlreport numeric keypad.

   Well, I think these (2 and 3) were our problems. We changed and added    some key sequences to the file vt220.kyb on the pc (pctcp is similar    to vt220) and then f5-f8 worked! We added unique sequences ctrl-f5,    shift-f5, etc. in vt220.kyb, then added them all to my resource file,    using oraterm, and they all work now!

   The problem now is that on hpterm and xterm the escape sequences for    ctrl-fn, alt-fn, and shift-fn are not different from fn!    That means I can use the function keys alone, but not in combinations.    So, I'm almost back where I started from, only this problem isn't as    "easy" to solve as the one on the pc! (I've even considered going to    the numeric keypad, but THAT doesn't work on hpterm!)

4) Considering this, I then had more understanding for the fourth person,

   who said he had given up trying to have the same layout on all    terminals! They changed their layouts, but have different ones for    each terminal and use a stencil next to the keyboard. He said that    with the many different functions in the tools, it wasn't worth the    trouble.

   Well, after a consultation with the boss, it looks like we'll be    doing the same, i.e. using a different layout for each terminal.    After all, most of our users stick to one terminal type.

So, many thanks to all those who responded. (I couldn't successfully get a mail out to you, Mr. Weinstein.)

Karen Schillinger :) Received on Tue Oct 20 1992 - 09:40:19 CET