|
On Thu, Jan 06, 2000 at 04:36:08PM -0600, stevefx@us.ibm.com wrote: > I'll have to agree with you here. I connected to the same system again > previously, but the system load must have been down from before. Therefore > I connected to one of the slowest systems in our lab and reproduced the > problem easily. I would say this is definitely bound to the connecting > system. That doesn't make sense. There is no communications with the system in between the screen resize and the screen update. Unless it's updating again, after that due to the AS/400 sending something -- anything, even just turning on the message waiting indicator, for example. I think it's more likely a timing issue on the client side, however - most likely the xterm is still resizing when we indicate to curses that it is done, and curses retreives the current size of the xterm (which is the old size). Now I just have to figure out if xterm *does* send a SIGWINCH when you tell it to resize. Otherwise, we just have to insert like a 1/4 second usleep() or something. -Jay 'Eraserhead' Felice +--- | 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.