|
On Sun, Jan 16, 2000 at 10:48:21PM +1300, Carey Evans wrote: > "Jason M. Felice" <jasonf@Baldwingroup.COM> writes: > > > This also means you should resubmit any outstanding bugs which have not been > > resolved. For the most part, I consider all prior issues closed due to the > > extent of work in 0.15.x, but I certainly expect there to be a few more >issues. > > Here's what I've found in 0.15.6: > > In an unsigned numeric field-exit required field, the cursor remains > on the last character but on pressing field exit, the last character > is erased. 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? I'll have to check this next time I have enough time to brave SDA and impose my brazen l'userness on a 400. > > In both DFU (e.g. UPDDTA) and PDM (e.g. WRKOBJPDM), the cursor returns > to the first field on the screen. In DFU it should move to the first > field in the record. In PDM, it usually moves to the first entry in > the list. > > In SEU, the Home key almost works. It returns the cursor to the > initial cursor position, but once there it doesn't send a Home command > to the AS/400, to move the cursor to the command entry at the top of > the screen. 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. > > Using Alt- or the Escape key still doesn't work right - tn5250 doesn't > notice the key until another key is pressed. Yeah, it's been on my TODO list to look at how vim handles this forever. I just downloaded and checked the vim source. Oh my god that's ugly - it basically uses termcap plus hand-codes all features not supported by termcap for other terminals. It has it's own key decomposition routine. Ouch, way to much work. 4,217 lines of code for handling the terminal. 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'll play around with it, but no promises. I think I'll also see if ncurses can be improved (or if it hasn't been already). > > A few more issues with SEU, too. The first thing I noticed is that > Client Access usually doesn't process a field exit just by spacing > past the end of the field, but tn5250 seems to. We process half of the 'Field Exit' functionality when you exit the field by keying past the end. We don't zero out the remainder of the field, but we perform any adjustments such as justification and padding, if possible. 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? > > When editing a DDS source member, the Len field has problems. It > should be possible to enter "+1" or "-1" (or +2, -10, etc.) in the > field, but tn5250 reuses the "+" and "-" keys which makes this > impossible. I'm not sure what a good solution would be. (I can still > enter the info directly, without prompting, so it's not a disaster!) 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) > > Also, field-minus in this field still does strange things, but not the > same strange things in tn5250 as other emulators. Well, I just made one correction - field exit will no longer clear out the sign on a signed number field. Any other specific cases? > > Hope this helps! Certainly. Well, it helps the emulator anyway, just not my notion of sleep ;-> -Jay 'Eraserhead' Felice P.S. Changes should be in CVS in a few hours. +--- | 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.