I wrote:Your original code does not update the tick count while the mouse is stationary on my system.
This was on Windows XP.
I ran the script on Windows 7, and got the following results:
- If I run the script as is, I get a rapid stream of mouse move messages.
- If I remove Critical, I get messages only when the mouse moves.
- If I remove ToolTip and use some other method of displaying the tick count, I get messages only when the mouse moves. Critical can be on or off.
There are comments in the source code indicating that showing a ToolTip window interferes with double click timing:
Code: Select all
// Don't call GetCursorPos() unless absolutely needed because it seems to mess
// up double-click timing, at least on XP. UPDATE: Is isn't GetCursorPos() that's
// interfering with double clicks, so it seems it must be the displaying of the ToolTip
// window itself.
Furthermore,
ControlGetFocus wrote:If ControlGetFocus is executed repeatedly at a high frequency (i.e. every 500 ms or faster), it will probably disrupt the user's ability to double-click.
A_CaretX / A_CaretY wrote:If the contents of these variables are fetched repeatedly at a high frequency (i.e. every 500 ms or faster), the user's ability to double-click will probably be disrupted. There is no known workaround.
What do they have in common? ControlGetFocus and A_CaretX both call
AttachThreadInput. Calling ControlGetFocus also causes another WM_MOUSEMOVE message to be sent, even though the mouse hasn't moved. Calling ControlGetFocus from some
other script has the same effect if it is targetting this script's GUI. Therefore, I assume that the ToolTip control internally uses AttachThreadInput or does something else which resets the thread's input state, thereby causing another WM_MOUSEMOVE message to be sent.