🚀 go-pugleaf

X-posted to demon.ip.developers, demon.ip.support.pc

When using FTP, the dew still fresh in one's newbie eyes,
all seems wonderful.  A friend mentions 'hash', so those
longer files are still a pleasure to download, watching
the little hashes race across the screen.  Of course, by
now the (pusher) friend has got one hooked on TextWin,
and ka9q will never be the same again.

Oh joy, oh frabtious joy!

The novelty eventually wears thin, and one leaves FTP
windows to get on with their stuff, while busy with other
windows.  But <shock> <horror> the FTP seems to have
hung up.  No, it's only the screen updating that hangs,
the actual transfer proceeds, but even though the window
is visible, there is no indication of progress.  :-(

I've just added a similar progress indicator to the
HTTP client, and of course the same is true.  This is
a long-standing problem, and try as I may, I can't find
the relevant bit of code.  Even adding things like
"tflush()" or "alert(sp->Display, 1)" don't solve it.
It seems as if the ftp (or http) process is actually
running, so the screen output is being queued, but
unless there's a '\n' in the output, the corresponding
display task is not painting the screen.

Any developers with clues about this?

Any users care 2 hoots about this??

Any users of the http version worried if I change that
damn hash code to a bytecount???  (I like to see a number
updated every 1K or so, overwriting on the same line,
instead of those interminable hashes).

--
John Washington