drag stack window

[Rob Cozens]

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 
vary."

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 
message.

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.
-- 

Rob Cozens
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)