11 replies to this topic

[Hacker]

Originally found in A double click hotkey.

A_TimeSincePriorHotkey returns higher values than it should. It also seems that it returns correct values if I move the cursor a little between the two clicks of the double-click, just between the confines of the XDblClickDiff and YDblClickDiff rectangle. See code:

#SingleInstance, Force

SysGet, XDblClickDiff, 36
SysGet, YDblClickDiff, 37
SystemDoubleClickTime := DllCall("GetDoubleClickTime")

~LButton::
	MouseGetPos, X, Y
	IfEqual, A_ThisHotkey, %A_PriorHotkey%
		IfLess, A_TimeSincePriorHotkey, %SystemDoubleClickTime%
		{
			EnvSub, PriorX, %X%
			Transform, PriorX, Abs, %PriorX%
			IfLessOrEqual, PriorX, %XDblClickDiff%
			{
				EnvSub, PriorY, %Y%
				Transform, PriorY, Abs, %PriorY%
				IfLessOrEqual, PriorY, %YDblClickDiff%
					SoundBeep
			}
		}
	PriorX = %X%
	PriorY = %Y%
Return

Roman

[PhiLho]

Wow, old style code!
I rewrote it a bit so I can understand better...

#SingleInstance, Force

SysGet, xDblClickDiff, 36
SysGet, yDblClickDiff, 37
systemDoubleClickTime := DllCall("GetDoubleClickTime")
OutputDebug DoubleClickTime: %systemDoubleClickTime%

~LButton::
	MouseGetPos, X, Y
	If (A_ThisHotkey = A_PriorHotkey)
	{
		OutputDebug %A_TimeSincePriorHotkey%
		If (A_TimeSincePriorHotkey <= systemDoubleClickTime)
		{
			priorX := Abs(priorX - X)
			If (priorX <= xDblClickDiff)
			{
				priorY := Abs(priorY - Y)
				If (priorY <= yDblClickDiff)
					OutputDebug OK
			}
		}
	}
	priorX := X
	priorY := Y
Return

And it works fine for me...
systemDoubleClickTime is 500 for me.
If I click slowly in Firefox, I get values around 516 or up, and no selection is done.
If I click faster, 482 or below, word is selected and the script displays OK, unless if I move the mouse too much between the clicks.
So what is wrong?

BTW, this script can be seen as a game: try to click to get exactly 500ms!

Oh, and why this is in the Bug Reports section?

[Hacker]

PhiLho,
Thanks for testing!

So what is wrong?

You pointed me in the right direction - try clicking on the title bar of a maximized window (to restore the window) - there it doesn't seem to work for me.

Oh, and why this is in the Bug Reports section?

Well because it doesn't work as expected?

Roman

[PhiLho]

I don't get it. What do you mean by "there it doesn't seem to work"? What doesn't work? Your script don't seem to do anything except beeping.

[Hacker]

PhiLho,
Let me quote myself:

A_TimeSincePriorHotkey returns higher values than it should.

When double-clicking on the title bar, I don't get times (A_TimeSincePriorHotkey) lower than cca. 200ms.

Roman

[PhiLho]

Ooh, you expect lower times? You are that fast? :-) How do you know your real speed, then?

Well, irony apart , I tested again (my script), and I routinely get times around 140, even went as low as 125 (double-clicking in my text editor).
Double-clicks on Firefox title bar: 140 156 140 etc. Can't go lower, but probably more a limitation on my muscles / nerves than something else.

No bug here. And I guess Chris is making just system calls to get this value, so if there is a limitation, it is probably on Windows side, not on AHK's one.

[Hacker]

PhiLho,

Ooh, you expect lower times? You are that fast? Smile How do you know your real speed, then?

Well, double-clicking not on the title bar I get 80-120ms.
Double-clicking on the title bar, out of 26 tries I get 22 over 350ms and 4 in the 80-120ms range.

I wonder what's the mystery. Thanks again for helping out.

Roman
P.S.: Using XP SP2.

[numEric]

Roman,

The reason for this behavior is that the OS's window animation effects (that occur on minimize/maximize/restore) have a much higher priority than the AHK process running your script (Realtime vs. Normal).
This causes the script execution to be delayed until the OS has finished displaying the animation effect (a few hundred milliseconds), hence the script has no opportunity to detect the second click earlier!

If you need to reliably detect double clicks on title bars, you can either increase the priority of the AHK process like in the example below, or disable window animation effects.

#SingleInstance, Force

Process, Priority, , R	; Set script's priority to Realtime

SysGet, SM_CXDOUBLECLK, 36
SysGet, SM_CYDOUBLECLK, 37
DoubleClickTime := DllCall("User32\GetDoubleClickTime")

OutputDebug, [%A_ScriptName%] Double-click time: %DoubleClickTime% ms

~LButton::
   MouseGetPos, X, Y
   If (A_ThisHotkey = A_PriorHotkey)
   {
      OutputDebug, [%A_ScriptName%] Time since previous left click: %A_TimeSincePriorHotkey% ms

      If (A_TimeSincePriorHotkey <= DoubleClickTime
         && Abs(X - PriorX) <= SM_CXDOUBLECLK
         && Abs(Y - PriorY) <= SM_CYDOUBLECLK)
      {
         OutputDebug, [%A_ScriptName%] Double click detected!

         SoundPlay, *-1
      }
   }
   PriorX := X
   PriorY := Y
Return

[Hacker]

numEric,
Aha! Thanks a lot!

Roman

[Scoox]

Using AutoHotkey_L v1.0.92.02 and the following code:

WheelUp::
WheelDown::Tooltip %A_TimeSincePriorHotkey%

When I scroll the mouse wheel fast, I get strange results:

1) I can reach delays of 0 ms (theoretically impossible)
2) Autohotkey seems to like certain values and dislike other values. For example, the tooltip will display 0, 16 31, 32, but it won't display any values in between such as 5, 12, 23, etc.

Running the script with realtime priority makes no difference.

[VxE]

When I scroll the mouse wheel fast, I get strange results:
...
Running the script with realtime priority makes no difference.

Computers don't operate in 'real time'; they never have. All computers experience time in chunks (called 'clock cycles') and the operating system combines many clock cycles together into bigger chunks, which it then uses to decide which programs get to use the CPU at any given time.

These bigger chunks are around 15ms long (there's a little more detail on the Sleep page), so, when your script says that 0 ms have elapsed between events, it means that both events happened during the same time chunk.

[Lexikos]

A_TimeSincePriorHotkey is based on GetTickCount (as is A_TickCount), which is limited to the resolution of the system timer. You could always use something more accurate, like QueryPerformanceCounter, if it bothers you.