AHK: Альтернатива команды "sleep".

Попробуйте кол.во кликов замерить используя другие методы посыла, например sendinput и.т.п.
По поводу трёх секунд, смогу написать позже. Но можете сами, надо просто делать паузы равные оставшемуся времени делённому на оставшееся кол.во кликов.

  Оттачивать предлагаю самому.

Извиняю,видать не правильно сформулировал вопрос.
Нужно именно по удержанию Лмышки,набрать такое количество кликов,что бы в минуту вышло ровно 600 или за 30 секунд вышло ровно 300.
(Как на машине,нажал педаль газа и она разогналась до трёхсот км\ч ,отпустил педаль,и скорост падает...)

До оттачивался, даже грамотно вопрос поставить не могу=)не спал кучу времени с этим...
Пробовал разные значения команды "sleep", пробовал разные команды посыла клика...Не получается добиться нужного,точного результата.

Сегодня под утро,вроде докопался до сути проблемы...Для того что бы сделать 600 кликов в минуту,нужно делать ровно 10 кликов в секунду,соответственно 1 клик ровно в 100 миллисекунд,по моему. Вот только команда "sleep" не даёт это сделать,в связи с своим принципом работы (sleep 10 = 15.6мл\с). Я замерял время выполнения области с кликами

{
Click down
Sleep 52
Click up
Sleep 52
}

Так вот выполняется она то за 94 то за 109 мл\с.,то есть каждый клик с разной скоростью...то за 94 то за 109 и так далее.

В справке про "sleep" нашёл интересную штуку.Вот только так и не понял как ей пользоваться,как бы не кавырял....
В общем нужна какая то альтернатива задержек времени,альтернатива команде - "sleep".

{
Click down
Sleep 50    ;Ровно 50 мл\с
Click up
Sleep 50    ;Ровно 50 мл\с
}

Работает,но к сожалению не так как требуется...В любом случае спасибо за труд.

Может по такому типу?

#Persistent

SetTimer, Sub, 50
Return


Sub:
If GetKeyState("Lbutton", "P")   
    {
    If counter
        {
        Click down
        counter:=
        }
    Else
        {
        Click up
        counter++
        }
    }
Return

Есть подозрение что не проходит первый клик, попробуйте поставить слип перед кликом.
Главное сделано, точное кол.во кликов, за точный период.
Переделайте под 600 кликов, вставьте условие для выхода если кнопка отпущена, и повтора цикла если клики закончились.
Далее присмотритесь к settimer для упрощения кода, используя в нём задержки зависимые уже от пройденного времени, и уже сделанных кликов, либо попробовать переменную A_Msec.

Серж, штука с индивидуальным подбором времени между кликами,к сожалению не подходит. Хотя набрать нужное колличество кликов за определённый отрезок времени оно может. Но всё же нужна стабильность между кликами.
Может,можно как то добиться меньшей погрешности команды "sleep"?
А то "sleep 50",замеры показывают 46-47 мл.сек, "sleep 52" и вовсе то 47 то 62...

L::
While GetKeyState("L", "P")   
  {
   NV := A_TickCount
click down
sleep 52
click up
sleep 52
   ToolTip % (A_TickCount-NV)  ; Показывает стабильные колебания (то 94 то 109)
  }
Return

Работает более менее стабильно и клики проходят относительно ровно. Но неужели нельзя лучше?

З.Ы

   NV := A_TickCount
click down
sleep 54
click up
sleep 37
   ToolTip % (A_TickCount-NV)  ; Показывает тот же результат,а цифры меньше...

MyLabel, 94 получается 303,301,302 за 30 сек.
MyLabel, 95 получается 280...

Блин вот печаль вообще...=(
А A_Msec работает по тому же принципу как и A_tickcount?

Так и не могу до конца понять задачу. До какой степени стабильность устроит? Только идеально по 100 мс?
А то первым делом приходит мысль взять любой из наиболее стабильных вариантов и добавить промежуточные проверки. К примеру, каждую секунду проверять - не сделано ли лишних кликов или наоборот нет ли недостающих, а соответственно в следующую секунду принудительно убирать/добавлять клик. При таком подходе теоретически можно достичь стабильности по количеству на некие промежутки времени - это подходит?

В ВК есть приложение ,там даётся ровно 30 сек,сколько накликаешь...
Ещё непосредственно на компе есть прога,а так же есть батлфилд,в котором можно прослушать с какой частотой кликается мышь.
Кстати,вот! В идеале вот в идеале,хотел добиться так что бы - "Берёшь автомат в любой игрушке...нажимаешь мышь и выпускается вся обойма. Не захлёбывается и с размеренными паузами. И при этом очень быстро."

Ну, с академической точки зрения, довольно занимательный вопрос.

Мда, квантование по 15,6 мс видимо не оставляет другого выбора, кроме как занять некоторое время чем-то не основанным на этом квантовании.
Я бы попробовал так.

Lbutton::
Click
While GetKeyState("Lbutton", "P")
    {
    Sleep, 94
    Loop, 7700  ;на моем ноутбуке за те самые 15,6 мс происходит почти 20000 итераций, соответственно 
                         ;7700 примерно пропорционально недостающим 6 мс
        {
        FutileCounter++
        }
    Click
    }
Return

К сожалению, проверить не имею возможности - искать внешний счетчик кликов лень, а любой внутренний, как я понимаю, связан тем же квантованием по 15,6.

Разумеется. Уж не потому ли в примечании упоминается именно мой ноутбук?

Хоть что-то. Есть место для экспериментов. Все-таки 6 мс - не так много.

Это Вы перевод видно читали. А в англоязычной указаны и 10 и 15,6 как типичные величины, до кратности которым округляются значения квантов времени. Несколько нехитрых экспериментов позволили мне убедиться, что мой удел - именно 15,6. Несколько нехитрых умозаключений позволили прийти к выводу, что это удел большинства, если не всех, отписавшихся в теме.
Попросту говоря, при кратности квантования 10 мс как раз периоды в 100 мс задавались бы беспроблемно, а на самом деле получается или 93/94 или 109/110. Попробуйте, может Вы счастливчик с квантованием-10?

Process, Priority, , Realtime
SetBatchLines, -1

~Lbutton::
GoSub, Sub
Return

Sub:
If GetKeyState("Lbutton", "P")
    {
    ToolTip, % A_tickcount - TimeOfClick
    TimeOfClick := A_tickcount
    SetTimer, Sub, -100
    }
Return

Почему вы так упорно не хотите попробовать воспользоваться функциями?

DllCall("Winmm\timeBeginPeriod", uint, ***)
DllCall("Winmm\timeEndPeriod", UInt, ***)

По мне,в справке,явно написано...,конкретно моей ситуации оно поможет.
Вот только у меня проблема заключается в том что функция эта,как будто не работает... Разницы не заметно совсем...Да и возвращает она - "0" а мне кажется это показывает на то что сработала она,далеко не норм.

Вы, как обычно, отвлекаетесь на частности. Единый таймер дает те же результаты, так что доверьтесь этому и познайте уже свою кратность.

Слишком много букаff.
И что есть "единый таймер"?

А Вы каким кодом получили эти самые результаты?

Я так понял что результаты тестов, не устроили.

----

Вот почему это, не устраивает ТС  переделать под желаемое кол.во кликов, выход при отпускании кнопки или повтор цикла (который вроде как у него показывает стабильные результаты) если кнопка не отпущена, мне не ясно.

По-моему, у ТС методы контроля какие-то левые. Я же специально в скрипт встроил Tooltip, который отчитывается: сколько миллисекунд прошло, сколько сделано щелчков. И всё это отталкивается не от какой-то абстрактной точки отсчёта, а от часов компьютера.

В Вашем варианте 1 клик происходит каждые 94 мс, то есть с 17-го клика пойдет накапливаемое расхождение с требуемым количеством.
А 94 - не потому, что Ваш компьютер "съедает" 6 мс, а потому что 94 это близко к значению, кратному 15,6 мс. Именно квантом 15,6, как я понимаю, у всех отписавшихся оперирует система (в справке сказано - зависит от железа и дров). Поэтому задание временных параметров что для Sleep, что для SetTimer в промежутках между значениями, кратными 15,6 мс, по большому счету бессмысленно. 94 - как раз пороговое значение, при 95 фактический период становится близким 109 (при прогоне подряд меняется на единицу - видимо из-за дробной части у кванта). Такое же квантование и для A_tickcount, в чем нетрудно убедиться, замеряя время очень быстро выполняемых операций в цикле.

Если действие выполняется ровно каждые 100мс, то при старте мы увидим ну например 648 и далее должно быть 748, 848 и.т.д. Ок, первую цифру в учёт не берём и наблюдаем за 48. Пускай будет всегда плюс потом минус примерно 10 или даже 20 мс. Но по вашей теории, постоянно должно быть рядом с ~50. А на практике будет только смещение вперёд или назад.
Нельзя подобрать заранее точную задержку (тем более понимая, что в очередь команд (для процессора) процесса даже с высоким приоритетом, может всегда вмешатся система или такой же приоритетный процесс, что неминуемо приводит к увеличению времени исполнения), её нужно постоянно корректировать, и никакой дллкэлл или вычисления квантов тут не помогут, имхо конечно.

Ну и для наглядности теста, конечно нужно увеличить задержку до 300~500 мс.

Ну так речь идёт про алгоритм выполнения действий через определённый отрезок времени, который не надо под каждый случай и пк подгонять. И если он не в состоянии вовремя отобразить тултип, или как в приведённой теме перерисовать часы (там кстати как раз 1000мс, и очень быстро становится видно что секунды сбиваются), то зачем использовать такой алгоритм, когда есть уже простое решение?

Я запускал Ваш скрипт и ни разу не видел 600 в минуту. Может как раз у вас квант 10?
Если не затруднит, запустите у себя в таком виде и напишите, что отображается в тултипе:

Process, Priority, , Realtime
SetBatchLines, -1

SetTimer, MyLabel, 94
SetTimer, MyLabel, OFF
Return

~Lbutton::
N :=
t1 := A_tickcount
SetTimer, MyLabel, ON
Return

~Lbutton Up::
SetTimer, MyLabel, OFF
t2 := A_tickcount
ToolTip, % N . " щелчков за " t2 - t1 . " мсек `r`n" . 60*N/((t2 - t1)/1000) . " щелчков за минуту"
Return

MyLabel:
ToolTip % A_tickcount - t3
t3 := A_tickcount
Click
N ++
Return

У меня чередуются 94 и 109 (все из-за той же дробной части как я понимаю).
Потом попробуйте менять 94 на единицу в меньшую сторону, а затем в большую. В моем случае 93 и ниже до 79 включительно дает чередование 93/94, 95 и выше до 109 включительно дает 109/110. После преодоления этих порогов значение изменяется на 15 и т.д.

Тупо зажал Enter и в мелькании разглядел 15,625.

Действительно дает требуемое количество. Более того, не удалось воспроизвести ситуацию с лишним или недостающим кликом. То есть независимо от общего периода и прочих пришедших на ум условий. Почему у меня раньше были абсолютно другие результаты - ума не дам. Единственная разница - сейчас прописал в скрипт, а тогда нажимал вручную (может тачпад и его дрова?...).
Дальнейшие копания привели вот к чему.

Process, Priority, , Realtime
SetBatchLines, -1

SetTimer, MyLabel, 94
SetTimer, MyLabel, OFF
DllCall("QueryPerformanceFrequency", "Int64*", Frequency)
Return

Lbutton::
N :=
t1 := A_tickcount
DllCall("QueryPerformanceCounter", "Int64*", CounterBefore)
SetTimer, MyLabel, ON
Return

MyLabel:
if (A_tickcount > t1 + (1000 * 60))
    {
    SetTimer, MyLabel, OFF
    ToolTip, % N . " щелчков за " t2 - t1 . " мсек `r`n" . 60*N/((t2 - t1)/1000) 
    . " щелчков за минуту `r`n" . (CounterAfter - CounterBefore)/Frequency . " точное время  `r`n"
    . PeriodMax . " <-------> " . PeriodMin
    Return
    }
;Click
N ++
t2 := A_tickcount
CounterAfterOld := CounterAfter
DllCall("QueryPerformanceCounter", "Int64*", CounterAfter)

Period :=(CounterAfter - CounterAfterOld)/Frequency
PeriodMin := !PeriodMin ? 0.1 : PeriodMin > Period ? Period : PeriodMin
PeriodMax := !PeriodMax ? 0.1 : PeriodMax < Period ? Period : PeriodMax

Return

У меня дает реальную продолжительность периодов в пределах от 85 до 116 мс. Если большие периоды можно объяснить нагрузкой, то откуда меньшие?

Это раскуроченный скрипт из поста #15.
По нажатию левой кнопки мыши он в течение минуты замеряет длительность периодов таймера и после истечения минуты вместе с другой информацией выдает продолжительность максимального и минимального  периода.
Сначала, когда я пробовал этот скрипт ypppu у меня получались разные результаты, не отвечающие условиям. Но на следующий день сколько бы я его не гонял, получалось всегда требуемое количество кликов, причем очень точно.
Это меня заинтересовало в свете предыдущих изысканий и я стал измерять продолжительность периодов срабатывания таймера, поскольку в начальном виде скрипт выводил в конце только количество кликов и общее время.