Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mintaka!olivea!uunet!cbmvax!peter From: peter@cbmvax.commodore.com (Peter Cherna) Newsgroups: comp.sys.amiga.programmer Subject: Re: front/back gadget and WindowToFront Message-ID: <22584@cbmvax.commodore.com> Date: 19 Jun 91 18:03:01 GMT References: <1991Jun19.001605.3317@crash.cts.com> Reply-To: peter@cbmvax.commodore.com (Peter Cherna) Organization: Commodore-Amiga, Inc. West Chester, PA. Lines: 29 In article <1991Jun19.001605.3317@crash.cts.com> hawk@pnet01.cts.com (John Anderson) writes: > I made a clock program under KS2.0 that brings itself to the front >every 30 seconds. However, if you happen to click and drag the mouse button >on workbench just as the clock window brings itself to the front, the mouse >freezes. There is no fully safe way for an application to freeze a shared screen, such as the Workbench screen, while still getting input through Intuition. A deadlock can result. However, Workbench must do this to allow dragging of icons. The technique to use is to set-up a watchdog task that looks for a deadlock and breaks the freeze. So for Workbench, that means if you're dragging icons and some other major event (eg. a new window or a depth-change) comes along, the system deadlocks for about a second, and then Workbench recovers. > The same thing happens any time you press left mouse button then >right mouse button to send a screen to the back. Is this a bug or feature :-) Under early releases of 2.0, Workbench drag selection began as soon as you clicked down in a Workbench window. Under 2.04, you must first move the mouse a small distance before drag-selection begins. That will cure your problem. Peter -- Peter Cherna, Operating Systems Development Group, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Gosh, didn't he have anything positive to say at all?"