dbPositionMouse() is faulty

[GoogleCodeExporter]

What steps will reproduce the problem?
1. dbPositionMouse(dbMouseX(), dbMouseY());

What is the expected output? What do you see instead?
As long as the mouse pointer is within the window, it should remain still and 
under normal user control. But what happens is that it tends to move in a 
straight line, on its own.

Please provide any additional information below.
I tracked down the cause. The mouse position calculations are scaled according 
to the current window size (i.e. if the window has been resized by the user, 
maximized, etc). And the scale is a floating point calculation. However the 
input and output position information is quantized to integers. So there is 
continuous truncation of essential precision needed to keep the mouse stable.

Thus, in my own copy of the source code, I changed those mouse position 
variables (including how they're used and recalculated in the various 
functions) from ints to floats. This solved the problem. The mouse is now 
stable whether it's in full-screen, windowed mode, or maximized window mode.

Original issue reported on code.google.com by pcowe...@yahoo.com on 30 Nov 2014 at 7:42

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I discovered a very odd bug that's closely related to this one. If you do a 
dbBox command to create a box for the section of the screen the mouse is in, 
then whenever you hit vertical screen (window) boundaries, the mouse pointer 
will bounce away from the vertical boundary and to the right - a fairly 
significant distance. But no dbBox in that section of the screen: No bounce! 
This occurs when the window is set to lower than the desktop resolution and is 
maximized. From briefly glancing at the code, it appears that the code for the 
two functions (dbBox and mouse position retrieval/setting) are unrelated, and 
yet they're producing this bug together - which leads me to believe it may be a 
Microsoft bug. But in hopes that it's not, one possible place to look would be 
in the setup of the WinProc callback function, since the mouse coordinates are 
retrieved from the right-most parameter which that function receives. I only 
glanced at the code though.

Original comment by pcowe...@yahoo.com on 6 Dec 2014 at 12:22