Mouse dragging: puzzling errors

[terrypin]

I've been puzzling over this for some time and would appreciate fresh thoughts please, even though I've now achieved my objective by another method.

 

Although I've simplified this extract greatly, I'm using script like the following to drag the starting mouse cursor position to a new position (where XDiff is the horizontal displacement from 960). I would expect exact results, whatever the application (possibly after setting the delay above some minimum value).

 

[b]Mouse Left Button Down
 Repeat Start (Repeat %XDiff% times)
   Mouse Move: 1, 0 Relative to Last Position
   Delay: 1 milliseconds
 End Repeat
Mouse Left Button Up[/b]

 

In a dozen arbitrary applications (Notepad, Outlook Express, Firefox, etc) I do get exact results. The cursor finishes at exactly x = 960.

 

But in the particular application for which the actual macro is intended, Memory-Map, not only do I get highly inaccurate results, but repeating the same run from the same starting point gives different errors each time. It's obviously because in this case it's the map that's dragged. (The purpose of the real macro is to centralise the map location at which the mouse is initially hovered, by pressing Keypad 5.) It seemed logical to me that I should get the same effect as dragging the mouse cursor. But I tried delays between 1 mS to 10 mS (although anything over 2 mS is impractically slow) yet the unreliability remains.

 

The new simpler method I've now used has rarely worked for me in other applications, but surprisingly here it does! I've just dragged the cursor directly to the desired screen position:

 

Mouse Left Button Down // At starting position.
 Mouse Move: 960, 600 Relative to Screen
Mouse Left Button Up

 

But, although it's now a matter of academic interest only, can anyone explain why the '1 pixel at a time' method fails please?

 

--

Terry, East Grinstead, UK

[paul]

But I tried delays between 1 mS to 10 mS (although anything over 2 mS is impractically slow) yet the unreliability remains.

Now try 1 second to 10 seconds and see if any work. If yes, then clearly moving a map imposes an intolerable load, and MEP is simply too fast for its own good (now that's a rare complaint, isn't it?).

[terrypin]

Now try 1 second to 10 seconds and see if any work. If yes, then clearly moving a map imposes an intolerable load, and MEP is simply too fast for its own good (now that's a rare complaint, isn't it?).

 

The errors were not getting progressively better as the delay was increased from 1 mS to 10 mS. But apart from that, with total displacement of up to 960 + 600 = 1560 pixels, with a delay of 1 second the macro would take up to 26 minutes, and at 10 seconds over 4 hours!

 

--

Terry, East Grinstead, UK

[paul]

The errors were not getting progressively better as the delay was increased from 1 mS to 10 mS. But apart from that, with total displacement of up to 960 + 600 = 1560 pixels, with a delay of 1 second the macro would take up to 26 minutes, and at 10 seconds over 4 hours!

All irrelevant! We're trying to locate the cause of a problem, which is why you need to follow my suggestion. I'm not suggesting the increasing delays as a solution to solving the problem, but as a solution to diagnosing the problem. And in your tests with these longer delays, there's no need to run the "total displacement", but merely some smallish subset simply to determine if the problem goes away or not.

If the timing turns out to be, say, 3 seconds, then increasing the delays from 1 ms to 10 ms is surely irrelevant!

[terrypin]

Fair point. Testing proved tedious but it turned out that anything over 40 mS gave the correct result of 960. Below 20 mS it became wildly erratic. Between 20-40 mS it got increasingly more accurate.

 

Thanks. I hate unsolved puzzles!

 

--

Terry, East Grinstead, UK