It appears that INFLD under A-Shell/32 (Ver. 5.1.1115.2) with TYPECODE = "@" and FUNMAP = -1 is returning EXITCODE = 0 for f-keys, whereas the AMOS version returns the expected "-#" value.

I have been using "@" with "i" for prompt fields that accept any key including f-keys and other exit keys (ESC, arrows, etc.). Similar to XCALL MESAG but that accepts any key.

I would like an invisible field that accepts any key and returns all EXITCODES -- including 0, 1, etc. and the "-#" f-key exitcodes. Under AMOS, INFLD did just that. Anybody know the "magic" TYPECODE combination that might do the trick?

That seems to have been an oversight. (Just goes to prove that no matter how much INFLD developers may have in common, each person is likely to have discovered a feature that no one else uses.)

It'll be fixed in 5.1.1115.4, hopefully later this afternoon. (Try the Update Center in awhile to check.)

I have a related question based on a customer just reporting this. Function keys defined by a PFK file work on an Alpha under INPUT LINE and INFLD under ZTERM. But using the AM62CG driver with an AM62CG.PFK file in ATE aren't returning the Function keys. Switching to AM62C under ATE doesn't seem to work either.

I don't believe that I do anything differently in the programs. Is there a specific OP code that I should make sure is included?

This does appear to be a problem with ATE connections to AMOS. I'll have to investigate why. FIXTRN seems to work ok, and the entire process works ok from ATE to A-Shell.

It may be that we need a different AM62CG.PFK file for AMOS than we use for A-Shell. (Currently, the ATE PFK files are set up to send the "extended" protocol, i.e. chr(155) + chr(n) where n is a value between 128 and 255. That seems to work for FIXTRN itself, but I'm not sure why it isn't working for INFLD.

Looks like .4 fixed it the f-key EXITCODE issue.

Thanks as always.

The Function keys seem to be working within INFLD on the Alpha now thank you.

I am not sure when or why - but now the function keys are NOT working on the alpha. They work from a dot but not with INFLD. I am now using 5.1.1124.6

Hmmm, sorry Joe... 5.0 is Ok however... is this on every site or just 1? Perhaps the funkey translation has gotten stepped on?

I tried reproducing this by connecting via ATE 5.1.1125.0 from my PC to your AMOS box. From what I can tell, the function keys work ok as long as the AM62CG.IFX file is loaded and contains translations.

Try the INFLD.RUN test program in the ATE: test directory on your system, first loading AM62CG.IFX into user memory from the same directory. F3 should generate exitcode -3, and F8 should say "hello". At least it does for me.

If not, see if you can give me a more precise scenario.

I should add that I was assuming you were talking about text mode INFLD. In the case of GUI INFLD, it all happens on the client side, so I can't really see how the server would have any effect.

We use Zterm in GUI mode and the PFK creates an E and CR if F1 is hit.
We use ATE with AM62CG in GUI mode and the PFK does send an E if you are at a dot, but just does a CR if F1 is hit when in a program using INFLD.
I think I have missed some setting in INFLD that is ignoring the F1. Does that sound right?

I suspect that you meant to say you use Zterm in text mode. But aside from that, a few comments that might or might not be relevant:

1. Unlike the case under A-Shell, under AMOS, PFK and FIXTRN (IFX) files are not the same, so make sure you use FIXTRN AM62CG.IFX for the one and SET PFK for the other.

2. INFLD should be able to support either type, but the dot prompt only supports the PFK files.

3. Since Zterm and ATE are using different emulations, you may need to build two different versions of your PFK file, one for each emulation. Same goes for the IFX file, but at least there the naming convention is unambiguous. With the PFK files, the filename has no particular significance, and thus it is easy to lose track of which emulation a particular PFK goes with (unless you name it sensibly).

4. Unlike the A-Shell version of FIXTRN, under AMOS, you cannot look at a translation without having to re-enter it if you want to preserve it. I know when I was playing with it, this was causing me considerable confusion.

5. The keyboard input routines on the server side have no idea of what keys you are hitting, and thus can't have any special logic for F1. All they see is what bytes get transmitted, which is also what FIXTRN shows. I had no problem using FIXTRN to set F1 to "E^M" and it seemed to work ok for me.

6. The symptom of INFLD ignoring the E and just processing the CR sounds like what you would get in a field that didn't accept alphabetic characters. You might want to confirm the TYPE codes.