nor1675@dsacg1.UUCP (Michael Figg) (02/15/89)
This is a posting for a friend who doesn't have access. 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 related 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 -- "Better graphics with crayons" Michael Figg Have since switched to oil based paints DLA Systems Automation Center but find they really screw up the color Columbus, Oh. map and pens! (614)-238-9036
nor1675@dsacg2.UUCP (Michael Figg) (02/16/89)
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. -- "Better graphics with crayons" Michael Figg Have since switched to oil based paints DLA Systems Automation Center but find they really screw up the color Columbus, Oh. map and pens! (614)-238-9036
dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) (02/17/89)
: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
jimm@amiga.UUCP (Jim Mackraz) (02/22/89)
In article <8902161959.AA19279@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes:
):Could someone refresh us on what the window to front bug is/was?
)
) 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.
That one is a deadly embrace by Workbench holding the layers locks
--necessary to drag an icon across other people's windows--until
it hears an upclick, and Intuition demanding the layers locks to pop
the window to front before it processes any more input.
There are other operations which can cause the deadlock (such as opening a
window), but I am unaware of any cases which don't involve WB dragging an
icon. I'd love to hear of any, of course, ... with some details ;^)
) 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.
LayerToFront? Hmm, you weird. I expect this to be all fixed up for V1.4,
probably by deferring the WindowToFront until the user is done dragging the
icon (lets go of the button). Probably need to think of some way to keep
multiple WindowToFront requests from queuing up.
) -Matt
jimm
--
Jim Mackraz, I and I Computing "Like you said when we crawled down
{cbmvax,well,oliveb}!amiga!jimm from the trees: We're in transition."
- Gang of Four
Opinions are my own. Comments are not to be taken as Commodore official policy.