|
"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: ABCD ^ 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 tn5250. [...] > 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 +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.