acs@amdahl.amdahl.com (Tony Sumrall) (07/22/87)
References:
Is there an easy, sure-fire way to tell that a RefreshGadgets call has
completed its business? I'm nearing the end of a clean-up on VT100 R2.6
and this little deal is holding me up. I've inserted a Delay(3L) to
circumvent the problem that I'm seeing but would much prefer to let the
system tell me when it's done.
Any ideas are appreciated.
For those interested, here's what I've done to VT100:
* Put the requester into a separate window. This allows cancelling
an xfer (requesters block all input to the window till they're
satisfied). This change also allows you to push the VT100 window
to the background, work in the CLI and still the the status of the
transfer
* Kermit properly handles compressed filenames.
* NAK from the host on a kermit send-init packet will cause a retry.
* spack() calls now use the correct number ande type of arguments.
* kermit xfers now use the host's requested end-of-line character.
* multi_xfer() in xmodem.c is no longer recursive.
* AbortIO() fixes (i.e. wait for the completion of the Abort).
Yet to be fixed: kermit always sends an end-of-batch packet during a send.
(I have yet to investigate this in any detail.)
Once the RefreshGadgets question has been answered to my satisfaction, I'll
post the stuff to comp.sources.amiga (well, doc, actually).
--
Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs
[ Opinions expressed herein are the author's and should not be construed
to reflect the views of Amdahl Corp. ]cmcmanis%pepper@Sun.COM (Chuck McManis) (07/22/87)
In article <10550@amdahl.amdahl.com> acs@amdahl.UUCP (Tony Sumrall) writes:
.>Is there an easy, sure-fire way to tell that a RefreshGadgets call has
.>completed its business? I'm nearing the end of a clean-up on VT100 R2.6
.>and this little deal is holding me up. I've inserted a Delay(3L) to
.>circumvent the problem that I'm seeing but would much prefer to let the
.>system tell me when it's done.
When I use 'RefreshGadgets' or its kin 'RefreshGList' is doesn't return to
me until it is done. My question is 'Why do you think it isn't done yet?'
.>For those interested, here's what I've done to VT100:
.> * Put the requester into a separate window. This allows cancelling
.> an xfer (requesters block all input to the window till they're
.> satisfied). This change also allows you to push the VT100 window
.> to the background, work in the CLI and still the the status of the
.> transfer
This is what the NOISY_REQUEST flag is for, when it is set the requester
*won't* block input. It is very useful for those people who want to support
mouse clicks as well as keystrokes to end requesters.
.>
.>Once the RefreshGadgets question has been answered to my satisfaction, I'll
.>post the stuff to comp.sources.amiga (well, doc, actually).
.>Tony Sumrall acs@amdahl.amdahl.com <=> ...!{ihnp4,hplabs,seismo}!amdahl!acs
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.