Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Window To Front bug
Message-ID: <8902161959.AA19279@postgres.Berkeley.EDU>
Date: 16 Feb 89 19:59:27 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 29

:I posted this a couple of days ago for a friend, who doesn't have access, so 
:I'm trying again. I'm interested also since I'm trying to run his software.
:
:Could someone refresh us on what the window to front bug is/was? 
:Specifically on how it relates to dmouse and other tasks. I know that 
:dmouse had it for a while. Matt, it seems like you had something to say
:about this in the past, could you repeat it please. Any other comments 
:would also be welcome. Thanks.

	Certainly.  The window-to-front bug (WindowToFront()/WindowToBack()) is
some kind of timing-window bug inside intuition or in the workbench-intuition
interaction.  It appears to crop up when programs WindowToFront()/Back() other
program's windows.

	It crops up even more often when dmouse and the workbench (loadwb) are 
running and dmouse is used to bring one or the workbench's windows to the 
front.  The problem has been linked to the workbench attempting to highlight
an icon and dmouse attempting to WindowToFront() at the same time.  Since both
use a click/double-click to accomlish their respective actions the case comes 
up often.

	To combat the problem, DMouse uses LayerToFront()/LayerToBack() by 
default.  Unfortunately, while this fixes the lock-up bug, it doesn't work 
well with SIMPLE_REFRESH or SUPER_BITMAP windows.  The -w1 option can be used
to switch back to WindowToFront()/WindowToBack().  One can also combat the
problem by setting the number of clicks required to bring the window to the
front > 1.

							-Matt