Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!sri-spam!ames!amdcad!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: RefreshGadgets Message-ID: <23948@sun.uucp> Date: Tue, 21-Jul-87 19:43:13 EDT Article-I.D.: sun.23948 Posted: Tue Jul 21 19:43:13 1987 Date-Received: Thu, 23-Jul-87 07:15:55 EDT References: <10550@amdahl.amdahl.com> Sender: news@sun.uucp Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 29 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.