• Subject: Re: 0.15.x -> 0.16.x
  • From: Carey Evans <c.evans@xxxxxxxxxxxx>
  • Date: 18 Jan 2000 20:27:43 +1300
  • User-Agent: Gnus/5.0803 (Gnus v5.8.3) XEmacs/21.1 (Bryce Canyon)

"Jason M. Felice" <jasonf@Baldwingroup.COM> writes:

> Hmm, interesting.  Is there really a difference between pressing field exit
> when on the last character of the field and pressing field exit after typing
> the last character, but still on the last character in a Field Exit Required
> field?  Catch-22 - I don't want to add YASF (yet another state flag).  What
> if you typed up to the end of the field, but then want to clear the last
> character with Field Exit?

There *is* a difference between before entering the last character in
a field, and having entered the last character and waiting for Field
Exit.  ISTR a real 5250 terminal that changed the cursor appearance in
this case.

How I think this works:

We have a four-character field, for instance:      ____
                        with the cursor here:      ^

Enter three characters:                            ABC_

Enter the fourth character, and the state changes: ABCD

Now if the user presses Field Exit, all the associated processing is
done, and the cursor moves to the next field.  If the cursor is just
positioned over the fourth character:
and field exit is pressed, then the final character is erased, and the
cursor moves to the next field.
                                                   ABC_     ____

> We are now handling Home key according to spec, which doesn't seem to jive
> 100% with what you're saying, but it's a lot closer than what we *were*
> doing :)  I also checked against Mocha5250 before abiding by the spec.

Here's what I see in Client Access.  I edit a file in SEU, move the
cursor to one of the line numbers, and press Enter.  The line number
gets highlighted, and the cursor moves to the beginning of the line.
Now I move the cursor up a few lines and press Home, and the cursor
returns to where it was after pressing Enter.  Up to here, tn5250
behaves the same.

However, if I now press Home again, the cursor moves to the command
line at the top of the screen in Client Access.  Nothing happens in


> There seems to be an intermediate way to do this - tell curses not to parse
> key codes and parse them ourselves.  It looks like we can be smarter about
> it.  (I wonder if that can be considered a ncurses bug?  Its probably doing
> something *really* generic).

I think ncurses tries to be bug-for-bug compatible with SVR4 curses,
where possible.

Hmm.  How does cursesterm.c notice when something has to get done?  If
it's only waiting for keypresses, but ncurses is waiting for a delay
to decide whether our Meta-key is an escape sequence or not, then
ncurses won't get a chance to report it until the next keypress.  This
sounds very much like what we're seeing.


> Is it a bug or a feature?  I can't think of any case where this would hurt
> anything, and it seems pretty useful to me.  Is it annoying to any 5250
> veterans?

I noticed it when trying to type *PARMS in the from position of a
field in a system data structure in ILE RPG.  I could learn to cope
with it just by pressing Tab instead.


> Good argument for the key-to-5250-function map.  Wait - does X allow us
> to use a different vt100 translation for the number-pad - and +?  I'll
> look into that.  And the console, too.  (Ugh, linux key maps)

In application keypad mode, with num-lock off, xterm sends "ESC O k"
instead of "+" for the keypad plus key.  This doesn't seem to be in
the terminfo description.  XTerm should be able to tell the difference
from X, though.

         Carey Evans  http://home.clear.net.nz/pages/c.evans/

         This message was composed from the finest electrons
         used by many of the world's greatest writers.
| This is the LINUX5250 Mailing List!
| To submit a new message, send your mail to LINUX5250@midrange.com.
| To subscribe to this list send email to LINUX5250-SUB@midrange.com.
| To unsubscribe from this list send email to LINUX5250-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].