drag stack window
rcozens at pon.net
Tue Sep 5 10:20:39 CDT 2006
Scott, et al:
I must be feeling defensive or argumentative this morning: I had
deleted your admonishment re polling the mouse state--it's worked
flawlessly for me since March, but as you said, "Your mileage may
Anyway, seems I can't let it go at that.
First: we are talking about polling the mouse state in a mouseMove
handler, not in general.
Second: we are talking specifically about a user action to drag a
window across the screen.
So what can go wrong?
A. The user releases the mouse simultaneously with ending a "mouse
motion" and the mouseMove handler finds its state to be up?
Since mouseMove continues to be sent until the mouse is released, the
window ends up at the coordinates sent in the penultimate mouseMove
B. The user presses the mouse simultaneously with ending a "mouse
motion" and the mouseMove handler finds its state to be down?
The window locates under the mouseLoc one mouseMove message earlier
than it should.
I seriously wonder if you can find a way to force polling the mouse
state in a mouseMove handler to return a state different from the
state of the mouse when the mouseMove message was sent.
Actually, I thought someone might comment on the differences in the
visual manifestation of the two approaches. Klaus' approach
maintains the relative positioning of the window under the mouse (eg.
if mouseDown in upper right corner, the window is moved so the upper
right corner remains under the mouse), whereas mine places the loc of
the window under the mouse. These are two different effects.
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
More information about the use-livecode