Автокликер Clickermann :: Форум

Основной раздел => Общие вопросы => Topic started by: Cleoss on November 22, 2016, 02:09:36 PM

Title: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 22, 2016, 02:09:36 PM
Решил организовать в своём скрипте вызов функции по хоткею. Для этого полез в руководство и стырил пару строк оттуда:
[spoiler=Проверка нажатия клавиши/комбинации]
Code: (clickermann) [Select]
// проверка нажатия пробела
if ( iskeydown(#space)=1 )
 logwrite("space!")
END_IF

// проверка нажатия пробела и клавиши A
if ( (iskeydown(#space)=1) & (iskeydown(#a)=1) )
 logwrite("space and a!")
END_IF
[/spoiler]
Решил проверить на практике, работает ли функция так, как ожидается. А вышло, как всегда -- "тут помню, а тут не помню"  :D
Добавил ожидание в 10 мс в конце. Вышло, что лограйт срабатывает несколько раз за нажатие.
Чтоб исключить такое поведение (многократное срабатывание), дописал переменную с инкрементацией и проверкой:
Code: (clickermann) [Select]
$a=0
if ( ( $a < 1 ) & ( iskeydown(#a) = 1 ) )
 logwrite("a!")
 inc($a)
END_IF
waitms(10)
Перепробовал несколько вариантов написания синтаксиса строки проверки: 
Code: (clickermann) [Select]
if (($a<1)&(iskeydown(#a)=1))
if ( ($a<1) & (iskeydown(#a)=1) )
if ( ( $a < 1 ) & ( iskeydown(#a) = 1 ) )
и прочие с пробелами/скобками/без оных

Но увы, при каждом из вариантов скрипт каждый раз выдавал ошибку и предлагал сделать аборт:
[spoiler=Ошибка при интерпретации строки Кликерманн](http://image.prntscr.com/image/722775b1f0ee42b5bec711e1b469d1c9.png)[/spoiler]

Сама ошибка очевидно связана с обработкой оператора присваивания значения строки &, точнее с его неверной интерпретацией не как символа булевой операции, поскольку в сообщении об ошибке данный оператор отсутствовал.

Попробовал также запасной вариант с подусловием, результат тот же (но здесь ожидаемо, ведь с каждым запуском переменная нулится):
[spoiler]
Code: (clickermann) [Select]
$a=0
if (  ( iskeydown(#a) = 1 ) )
   if ( $a < 1 )
      logwrite("a!")
      inc($a)
   END_IF
END_IF
Неожиданно:
(http://image.prntscr.com/image/1e830399800343a3bb0725c4b26140a3.png)
[/spoiler]

Теперь даже не знаю, какие варианты рассматривать. Может, заморочиться с потоками и переменными проверки/состояния в них? И что-то задний моск мне подсказывает, что без потоков туточки не обойтись.
Title: Re: Проверка условия повторного нажатия вместе с хоткеем iskeydown
Post by: Vint on November 22, 2016, 03:24:32 PM
Конечно, здесь очень нужны потоки. Просто необходимы.

Раз
Code: (clickermann) [Select]
IF(($a < 1) & (iskeydown(#a) = 1))
    logwrite("a!")
    inc($a)
END_IF
waitms(20)

Два
Code: (clickermann) [Select]
DEFINE($a, 0)
IF(($a < 1) & (iskeydown(#a) = 1))
    logwrite("a!")
    inc($a)
END_IF
waitms(20)

Самый нормальный, три
Code: (clickermann) [Select]
IF(iskeydown(#a) = 1)
    logwrite("a!")
   
    WHILE(iskeydown(#a) = 1)
        waitms(20)
    END_CYC
END_IF
waitms(20)

P.S. Пробелы здесь не критичны, они при парсинге игнорируются от слова "совсем".
Title: Re: Проверка условия повторного нажатия вместе с хоткеем iskeydown
Post by: Cleoss on November 22, 2016, 08:42:03 PM
Первый вариант печатает лограйтом один раз и больше уже не печатает, сколько ни жми клавишу, вместо того, чтоб печатать один раз за нажатие.

Второй как ни странно делает то же самое, хотя казалось, что DEFINE($a, 0) и $a=0 эквивалентны и должны действовать одинаково, но мой вариант с $a=0 печатает много раз за нажатие, как уже писалось выше.

А вот в третьем разе как раз вроде и делается всё, как полагается, даже несмотря на такое казалось бы нетривиальное решение:
Code: (clickermann) [Select]
    WHILE(iskeydown(#a) = 1)
        waitms(20)
    END_CYC
то есть внутри цикла нет ничего.. кроме паузы и ожидания. Я б до такого не додумался Х(
Спасибо, Винтец! Щёлкаешь всё с закрытыми глазами)) (https://ds03.infourok.ru/uploads/ex/1280/00013777-4f497fad/hello_html_2ae0783.gif)

Терь попробую добавлю сразу несколько хоткеев и потестирую, как будет загружаться проц вместе с проверкой всех нажатий с короткими паузами 10-20 мс (у меня delay_between_lines = 0 в конфиге).  Поищу компромисс между загруженностью, быстродействием и правильным функционированием нажатий.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown
Post by: Cleoss on November 22, 2016, 09:05:15 PM
А, вот! Дошло, почему здесь нужны треды: цикл вайл выполняется до тех пор, пока не будет отжата клавиша, то есть значит тем временем нажатие других клавиш не проверяется, а проверяется в текущем цикле только одна клавиша/комбинация. То есть чтоб проверять сразу несколько нажатий, нужно сделать это всё во множестве отдельных потоков, чтоб мочь обработать все возможные нажатия. Ну не знаю, может, как-то там можно и через GETKEYSDOWN. Щас бум пробовать.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown
Post by: Cleoss on November 22, 2016, 09:25:46 PM
Ппц, вот такой код: [spoiler=Пара тредов с двумя паузами по 5 мс]
Code: (clickermann) [Select]
thread(a)
  IF(iskeydown(#a) = 1)
    logwrite("a!")
    WHILE(iskeydown(#a) = 1)
        waitms(5)
    END_CYC
  END_IF
  waitms(5)
end_thread

thread(b)
  IF(iskeydown(#b) = 1)
    logwrite("b!")
    WHILE(iskeydown(#b) = 1)
        waitms(5)
    END_CYC
  END_IF
  waitms(5)
end_thread
[/spoiler]
загружает двухъядерный проц почти на 100 %, а временами и вешает комп, не давая мыши ни на что нажимать.
И этого проверка только двух клавиш.. А как же организовать тогда сотни комбинаций?!

ПС. Скрипт загружает проц даже без нажатий, зависания происходят на несколько секунд примерно раз в минуту.
Без работы скрипта проц загружен на 15-20%. Хотя может загрузка будет меньше, если вместо лограйта юзать кейпресс?
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Oraven on November 22, 2016, 09:47:04 PM
Выстави в конфиге "delay_between_lines = 1"
Значение 0 приводит к чрезмерной нагрузке. Вернее сказать при значении 0 кликер постоянно грузит проц на 50% даже в задержке (по крайней мере у меня так).
Рекомендую ставить задержку в скрипте 20 мс и выше.

Вот вариант с GETKEYSDOWN
Code: (clickermann) [Select]
GETKEYSDOWN ($arr_key)
IF(ARRSIZE($arr_key) > 0)
   WHILE(ISKEYDOWN($arr_key[0])=1)
      WAITMS(20)
   END_CYC
   
   SWITCH($arr_key[0])
   CASE(#A)
      LOGWRITE ("A")
   CASE(#B)
      LOGWRITE ("B")
   END_SWITCH
   
ELSE
   WAITMS(20)
END_IF
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 22, 2016, 10:30:39 PM
Если сделать вот таким макаром (по примеру из доки):
[spoiler]
Code: (clickermann) [Select]
// пример 2, анализ нажатых клавиш через switch
// данный пример использует тот факт что $kvar тоже самое что и $kvar[0]
getkeysdown($kvar)
SWITCH($kvar)
CASE(#q)
   print("Q")
CASE(#w)
   print("W")
CASE(#e)
   print("E")
CASE(#R)
   print("R")
CASE(#T)
   print("T")
CASE(#Y)
   print("Y")
CASE(#U)
   print("U")
CASE(#I)
   print("I")
CASE(#O)
   print("O")
CASE(#P)
   print("P")
CASE(#A)
   print("A")
CASE(#S)
   print("S")
CASE(#D)
   print("D")
CASE(#F)
   print("F")
CASE(#G)
   print("G")
CASE(#H)
   print("H")
CASE(#J)
   print("J")
CASE(#K)
   print("K")
CASE(#L)
   print("L")
CASE(#Z)
   print("Z")
CASE(#X)
   print("X")
CASE(#C)
   print("C")
CASE(#V)
   print("V")
CASE(#B)
   print("B")
CASE(#N)
   print("N")
CASE(#M)
   print("M")
END_SWITCH
waitms(10)
[/spoiler]
то скрипт грузит проц уже на 50 про, слава б-гу хоть не на сто)) Это уже терпимо.

Но здесь пример простейший, проверка одна -- только на буквы, и печатаются они посему по нескольку раз за нажатие (на моём компе с моей клавой минимум 3-5 раз), также нету проверок на нажатие клавиш-модификаторов, поэтому и небольшая сравнительно загруженность даже при низкой задержке.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 22, 2016, 11:02:19 PM
Выстави в конфиге "delay_between_lines = 1"
Значение 0 приводит к чрезмерной нагрузке. Вернее сказать при значении 0 кликер постоянно грузит проц на 50% даже в задержке (по крайней мере у меня так).
Рекомендую ставить задержку в скрипте 20 мс и выше.

Вот вариант с GETKEYSDOWN

Спасиб за готовое решение, Андрей! Вот вроде Винт уже использовал похожий код:
[spoiler=Цикл вайловый с массивом набранных клавиш]
Code: (clickermann) [Select]
   WHILE(ISKEYDOWN($arr_key[0])=1)
      WAITMS(20)
   END_CYC
[/spoiler]
а вот чёт я б и не смог допетрить, как запихнуть массив в в цикл. Мне б такое и в голову не пришло, спасибо ещё раз.

Ну а по поводу задержки я эти моменты понимаю и сам уже не раз тестировал разные варианты загруженности с разными задержками, а также меру задержек для адекватного поведения приложений. Для меня эти тесты актуальны, поскольку машина не фонтан, а.. редиска у меня. Но я бы согласился на загрузку кликера 20-60 процентов в случае успешной обработки всех нужных/возможных комбинаций (ориентировочно около 1000 вариантов хоткеев), но чую над этим решениям ещё надо буит малость попотеть. Не исключаю и вариант, что не получится обрабатывать всю эту 1к вариантов нажатий с адекватным поведением системы. А относительно "Рекомендую ставить задержку в скрипте 20 мс и выше" -- дилемма в том, что длительность самых коротких нажатий составляет как раз 20-30 мс, и если сделать задержку чаще/дольше, то будут часто пропускаться эти сами "короткие нажатия" ввиду редкости проверок нажатия (та же проблема и с вайлом).

Но delay_between_lines = 1 я конечно же приму к сведению (1 мс не б-г весть какая долгая длительность и для нажатия погоды не сыграет, а вот проц наверняка подразгрузит). Главное, опять же в тестах определить баланс адекватности и отсутствия пропусков нажатий. Но я при тестах пару недель назад понял, что надеяться на загрузку моего не ахти-какого процессора кликером меньше, чем на 10-20 процентов слишком глупо (либо работаем/обрабатываем нажатия и грузим проц, либо отдыхаем/остываем и ничего не обрабатываем). Но по началу я надеялся на загрузку в пределах 2-10 про (кстати, такой загруженности можно добиться при работе скрипта в фоне, без нажатий, но с величиной задержки проверок 50-150 мс и больше). Но чем дольше задержек, тем опять же больше пропусков нажатий, и к сожалению даже при задержке 50 мс пропуски достаточно часто случаются, хотя казалось бы интервал достаточно не большой.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 22, 2016, 11:46:41 PM
Отсюда, из последнего абзаца, можно сделать вывод (как вариант, может кому и подойдёт такое), что если вам нужно сделать систему, которая обрабатывает 1000-2000 хоткеев, то можно просто спроектировать скрипт таким образом, что задержки будут достаточно большими (от 100-200 мс и выше с шагом в 100 мс) и при этом вам придётся достаточно долго (соответственно 0,2+ сек, хотя не так уж это и много, можно и полсекунды подержать) нажимать на каждую клавишу, причём делать это сознательно и каждый раз, но думаю, через полчаса-час таких "осознанных" долгих нажатий рука с мозгом сами привыкнут и выработают моторику, благодаря которой вы станете автоматически каждую клавишу нажимать (относительно) "долго" (то есть столько, сколько нужно для успевания обработки и срабатывания нужной вам функции). Кстати, в некоторых программах-хоткеизаторах есть отдельные обработчики для коротких/длинных нажатий, то есть при коротком нажатии срабатывает вызов обычной для клавиши функции, а при длительном нажатии запускается особая, отдельно запрограммированная/заданная функция, примерно такую же реализацию охота и мне заиметь в своём обработчике))

Также нужно отметить, что при моих экспериментах с прошлым кликером тоже проводил эксперименты по ускорению скриптов и при этом более-менее вменяемому поведению окон определилось (у меня, для моего компа), что при клике на заголовках окон для переключения фокуса на него нужно для адекватного поведения окошка делать задержку между кейдавном и кейапом в пределах 300-350 мс (не меньше) и примерно аналогичную задержку после кейапа по заголовку, иначе время от времени скрипт может глюкануть (чем меньше задержка, тем более вероятность этого) и перетащить окно вместо клика по нему или переставить фокус на другой элемент, на который скрипт жмёт следующим. Даже больше, если все задержки будут очень короткими либо отсутствовать, многие действия в скрипте не смогут быть выполнены либо же будут выполнены неверно и исполнение скрипта пойдёт совсем не по нужной колее, может даже испортить чтот в системе или перенастроить. В остальных же местах можно ставит достаточно короткие задержки (имхо 100-200 не такие уж и долгие задержки, как возможно здесь принято считать, но местами могут позволить вашим приложениям работать более стабильно) по своему усмотрению и в зависимости от величины быстродействия вашего компа. То бишь клик по окну часто является слабым звеном при работе со многими окнами и при переключении между ними всеми в том смысле, что он требует отдельную, бОльшую задержку. Мени прыкро, что такую важную инфу я пишу где-то в глубине какой-то своей узкоспециальной темы, тем более что пользователи кликера часто неграмотно работают с задержками (точнее, убирают их под ноль) да и в мануале нету толковой наводки на эту тему. Единственное место, где нужны особо большие задержки это пинги (ожидание загрузки/дозагрузки веб-страницы и отдельных/всех её элементов), но благо для обхода этого в Клмн есть циклы и ифпикин.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Vint on November 23, 2016, 01:03:30 PM
то скрипт грузит проц уже на 50 про, слава б-гу хоть не на сто)) Это уже терпимо.
Ремонтируй свою систему. У меня на очень не новом компе 3-7%, в среднем 5%.

хотя казалось, что DEFINE($a, 0) и $a=0 эквивалентны и должны действовать одинаково
Они НЕ одинаковы.

Первый вариант печатает лограйтом один раз и больше уже не печатает, сколько ни жми клавишу, вместо того, чтоб печатать один раз за нажатие.
Второй как ни странно делает то же самое
Это пример без "окружающего скрипта". Кто знает что ты там собирался делать. Вот вне циклов и нужно сбрасывать переменную.

А, вот! Дошло, почему здесь нужны треды: цикл вайл выполняется до тех пор, пока не будет отжата клавиша, то есть значит тем временем нажатие других клавиш не проверяется, а проверяется в текущем цикле только одна клавиша/комбинация. То есть чтоб проверять сразу несколько нажатий, нужно сделать это всё во множестве отдельных потоков, чтоб мочь обработать все возможные нажатия.
Обычно хоткеи не используются как управление и им не нужна одновременная реакция на разные. Но соглашусь, если юзание активное, то ожидать отпускание только при делении по потокам.

Ппц, вот такой код: [spoiler=Пара тредов с двумя паузами по 5 мс]
загружает двухъядерный проц почти на 100 %, а временами и вешает комп, не давая мыши ни на что нажимать.
Потому что погрешность waitms как раз 5 мс. И на некоторых компах и в некоторых случаях, это всё равно что задержки нет совсем.
У меня на преведущем рабочем компе всё меньше 5 было равно 0.
Сейчас конечно и 2 мс рабочие.

имхо 100-200 не такие уж и долгие задержки, как возможно здесь принято считать
никто так не считает. Это у тебя в скриптах то 5, то 10.
Я только в самых нужных, нагруженных местах ставлю 5-20. При обработках массивов данных, например в файле.

То бишь клик по окну часто является слабым звеном при работе со многими окнами и при переключении между ними всеми в том смысле, что он требует отдельную, бОльшую задержку. Мени прыкро, что такую важную инфу я пишу где-то в глубине какой-то своей узкоспециальной темы, тем более что пользователи кликера часто неграмотно работают с задержками (точнее, убирают их под ноль) да и в мануале нету толковой наводки на эту тему.
менi прикро - тебя не все поймут  :)
Клик по окну = сделать активным окно и перевести на него фокус - время реакции это не проблема кликера, а проблема реакции системы, которая зависит от железа, загруженности компа и загаженности системы. У меня эта реакция на глаз совсем не отличается от многих других. Но я и не ставлю 5-10 мс.
По задержкам много индивидуальностей и много зависит от приложений и задач. Что там в мануале писать? Солить по вкусу? Или расписывать все возможные варианты?...
Ну, трудные места не мешало бы упомянуть. Всех проблем всех пользователей это не решит пока они не будут писать и писать. Потом придёт просветление и в голове у каждого будет "свой" мануал, не совпадающий с другими.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 23, 2016, 02:58:17 PM
А кто это тут "король автоматизации" судя по опросу? А ну отзовись!))
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Золотой on November 23, 2016, 03:12:22 PM
А кто это тут "король автоматизации" судя по опросу? А ну отзовись!))
Королей не знаю и знать не хочу, но судя по опросу, Я БОГ АВТОМАТИЗАЦИИ!     :P
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Vint on November 23, 2016, 03:29:03 PM
Голосование подтасовано  ;D
Мой любимый 2 пункт
Quote
"Мне это нужно, но не часто. Было б хорошо добавлять хоткеи с лёгкостью."
испорчен. Мне подходит "Мне это нужно, но не часто". Но зачем здесь сопутствующий товар в виде
"Было б хорошо добавлять..." ?

Что это за тяга к "чехол не нужен?"  :D
Выходит от моего имени там чего то просят.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: i0 on November 23, 2016, 03:31:01 PM
Мне подходит "Мне это нужно, но не часто". Но зачем здесь сопутствующий товар в виде
"Было б хорошо добавлять..." ?
поэтому 5+
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Vint on November 23, 2016, 03:54:31 PM
Опрос с нарушением правил составления.

10 правил составления опросов (http://art-con.ru/node/1794)

Вот прям пункт 1 нарушается.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 23, 2016, 04:21:41 PM
Ремонтируй свою систему. У меня на очень не новом компе 3-7%, в среднем 5%.
Нет, ну я ж не говорю, что на всех скриптах так, в среднем по палате у меня тоже пару процентов, в "обычных" скриптах. А вот этом, со множеством проверок, делеями по 10-20 мс и с delay_between_lines = 1 выходит примерно наполовину загрузка проца или чуть больше, и это, повторюсь, считаю вполне приемлемым результатом для такого нагруженного скрипта, да и не окончательным вариант это ещё. Хотя может пока просто не знаю  неких хитростей оптимизации по определению нажатых в текущий момент клавиш и их комбинаций, и пока что я их здесь не нашёл. Просто с месяц назад я в розовых очках верил, что серьёзный скрипт может работать не нагружая комп, сейчас я к счастью с этой иллюзией расстался.

казалось, что DEFINE($a, 0) и $a=0 эквивалентны
Они НЕ одинаковы.
И в чём там цимус дефайна (если в двух словах)?

Кто знает что ты там собирался делать. Вот вне циклов и нужно сбрасывать переменную.
Ха-ха, ха-ха-ха-ха-ха!  :-[ *нервный смех*
Переменную? Вне циклов? Без тредов?
А это ваще реально?
Не, ну я по сути так и сделал (объявил а перед ифом), но я имею ввиду другое. Скрипт работает без хальта и безостановочно, что само по себе уже и есть цикл без его объявления? Разве можно указать переменную вне этого цикла, но чтоб она обнулялась только раз (пока текущий хоткей нажат)? Ну мож можно присобачить инклуд, но ведь он же будет исполняться с каждой итерацией скрипта или он всё-таки include-once?

Обычно хоткеи не используются как управление и им не нужна одновременная реакция на разные. Но соглашусь, если юзание активное, то ожидать отпускание только при делении по потокам.
Уф! Неет, только не это! Винт дал добро на потоки!
Но и это ещё не всё. Как уже писал, хочу вклинить проверку на длительность нажатия и в соответствии с величиной длительности уже варьировать реакцию. То есть это удобно чем: на одну и ту же клавишу можно повесить сразу нескольку действий, такое поведение может быть особо ценным ввиду того, что, как говорил тов. Золотой, "клавиш лишь ограниченное количество" и что их часто не хватает, особенно при пользовании сразу несколькими программами и соответственно скриптами, приспособленными под них. Но это также и усложняет разработку скрипта, и сейчас если честно у меня есть большие сомнения, что это вообще получится реализовать так, как это задумано, ввиду такой загрузки Клмном.

Потому что погрешность waitms как раз 5 мс. И на некоторых компах и в некоторых случаях, это всё равно что задержки нет совсем.
У меня на предыдущем рабочем компе всё меньше 5 было равно 0.
Сейчас конечно и 2 мс рабочие.
Вот это, про погрешность вейта надо бы учесть да не забыть как-то. А ещё лучше тестануть каким скриптом. Винт, а может есть у нас топики с уже готовым скриптом с такой проверкой "работоспособности компьютера"? Кстати, если что, у меня две машины (обе примерно начала этого десятилетия): 2-ядерник AMD C-60 1.0-1.3 GHz и 2-ядерный Пень G620 2.6  GHz. Ну и мобилка примерно того же времени и той же мощности, что и амд. Правда, пока что у нас нету Клмна под Андроид  ::) До войны было несколько i5 неплохих, потом один сгорел, а второй.. тоже недавно сгорел, спасибо кенту))

имхо 100-200 не такие уж и долгие задержки, как возможно здесь принято считать
никто так не считает. Это у тебя в скриптах то 5, то 10.
Я только в самых нужных, нагруженных местах ставлю 5-20. При обработках массивов данных, например в файле.
Да, но здесь на форуме я часто встречаю, что советуют задержки в пределах 20-50 мс, и меня аж коробит от этого. И как я уже писал, многие ваще "умеют" обходиться без вейтов. А я вот считаю более "человечными" (в смысле эмулирующими работу человека) задержки в диапазоне 200-500 мс (бывает задержка нужна до пары секунд, что здесь наверняка сочтут изуверством)), но об этом часто спрашивают, когда хотят чтоб скрипт был "человечным"), это может быть актуальным при работе с веб-браузером и его не столь отзывчивым (по сравнению с десктопом) веб-интерфейсом, с которым нам зачастую приходится иметь дело. Да и Джонни помнится писал не так давно, что хотелось бы, чтоб кто-то протестировал более-менее адекватные меры задержек, вот я и подытожил свои эксперименты в этом плане, что самый критичный при очень быстрой работе скрипта это щелчок по окну (это обнаруженное в течение экспериментов бутылочное горлышко быстроты), или у себя в скриптах ты обходишься без кликов по заголовку и даёшь фокус по окну как-то по-другому?

менi прикро - тебя не все поймут  :)
Ну не наю, как это по-ёмчей сказать, в общем испанский стыд (http://pikabu.ru/story/ispanskiy_styid_2726729)))
Кстати, Винт, как я понимаю у тя родина Первомайск, а ты щас в Харькове обитаешь? А как там у вас щас обстановка и как город, сильно пострадал? У нас в Луче уже с год +/- тихо, ну иногда гремит вдалеке, но пока что рядом не бомбят. А вот слышал недавно, что около Донецка грады работы так, что громыхало капец. Ну как всегда, хоть в подвал беги.

Клик по окну = сделать активным окно и перевести на него фокус - время реакции это не проблема кликера, а проблема реакции системы, которая зависит от железа, загруженности компа и загаженности системы. У меня эта реакция на глаз совсем не отличается от многих других. Но я и не ставлю 5-10 мс.
По задержкам много индивидуальностей и много зависит от приложений и задач. Что там в мануале писать? Солить по вкусу? Или расписывать все возможные варианты?...
Ну, трудные места не мешало бы упомянуть. Всех проблем всех пользователей это не решит пока они не будут писать и писать. Потом придёт просветление и в голове у каждого будет "свой" мануал, не совпадающий с другими.
Что в мане писать? Ну вот это и есть дилемма, как подытожить разные сценарии. Но проблема разумеется не в кликере, а частично в том, что здесь часто советуют очень маленькие задержки, и в том, что пользователи думают, что раз они тратят на по паре секунд на каждое действие, то и кликер будет поступать так же, и как следствие они не учитывают по наивности задержек в своих алгоритмах. Я не говорю, что это плохо и что скрипты должны выполняться долго/ медленно/ стабильно, но просто понятно, что иногда такие недочёты могут выходить боком, как примерно и дилемма с хальтом и прочими препроцессорными штуками. Надо приучить людей к культуре и объяснить, что делеи в рамках 0,3-0,5 с это норм. А так ясно, что всё весьма индивидуально, но можно и опрос на эту темку замутить. И сильно сомневаюсь, что даже в новой системе на мощном железе скрипт сможет работать адекватно без задержек. У кента есть i7 и 32 гб оперативки, но они тоже лагают в той браузерке с флешем, под которую он прётся, когда запускает все-навсего 50 окон обновившегося Огнелиса (говорит, в версии 25 всё было путём).
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 23, 2016, 04:28:24 PM
Голосование подтасовано  ;D
Мой любимый 2 пункт
Quote
"Мне это нужно, но не часто. Было б хорошо добавлять хоткеи с лёгкостью."
испорчен. Мне подходит "Мне это нужно, но не часто". Но зачем здесь сопутствующий товар в виде
"Было б хорошо добавлять..." ?

Что это за тяга к "чехол не нужен?"  :D
Выходит от моего имени там чего то просят.

Да-да)) Молодой челувек, вам подсказать что-нибудь?
Снимаю завесу. На самом деле сначала написал нормальные варианты, но ввиду того, что в опроснике есть только 5 вариантов, не больше, пришлось шить дело)
Такой вот он, наш скрытый маркетинг с внедрёнными интентами. Очки ннада?
А кстати что, разве не "Было б хорошо добавлять..."?  ;)

Королей не знаю и знать не хочу, но судя по опросу, Я БОГ АВТОМАТИЗАЦИИ!     :P

Трудно поспорить  :) Бог это вне вариантов аки код:
[spoiler]
Code: (clickermann) [Select]
switch($opros)
case(noob)
  print("Совпадений не найдено")
case(user)
  print("Он меня троллит?")
case(korol)
  print("Не желаю знать таких")
default
  print("Я Бог!")
end_switch
[/spoiler]
"Царь, оч приятно. Оч приятно, царь"

Мне подходит "Мне это нужно, но не часто". Но зачем здесь сопутствующий товар в виде
"Было б хорошо добавлять..." ?
поэтому 5+
Но должны же быть и у политтехнологов свои правила?! Пусть грязные, но правила.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 23, 2016, 04:43:29 PM
Кстати, диагноз прогноз подтверждается: у нас даже короли нашлись, а вот взяться утверждать, что "Не знаю как сделать хоткей" никто не берётся!  :P
Кто-нибудь, поправьте ситуацию, плиз!
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Vint on November 23, 2016, 05:33:21 PM
А вот этом, со множеством проверок, делеями по 10-20 мс
Я пробовал именно указанный скрипт из твоего поста.

И в чём там цимус дефайна (если в двух словах)?
Справка
Quote
Примечания
Инструкция сработает только если переменная не была объявлена раньше. В противном случае инструкция игнорируется.

Скрипт работает без хальта и безостановочно, что само по себе уже и есть цикл без его объявления? Разве можно указать переменную вне этого цикла

Так всё просто - объяви его. Постарайся забыть про дефолтный цикл всего скрипта и сделать цикл самому. Мало ли что будет в следующей версии, вдруг выполнение по кругу отключат, а ты уже готов.

Уф! Неет, только не это! Винт дал добро на потоки!
Да не вопрос, пользуйся  ;D.
Неужели ты до сих пор не понял, что я против потоков там где они не нужны абсолютно.
А то сейчас выходит: "телевизор не включается... так, так, так... а если через потоки..."


Я вот не пойму, ты действительно неординарная личность и способен запомнить эти "несколько сотен"/1000/2000 хоткеев и с ними реально работать? При чём несколько могут быть нажаты одновременно.
Я вот нет. Я десяток еле использую и то общеуниверсальных. Изредко в спецпрограммах + 5-7 штук, на больше меня не хватает. Получается очередь: последние зашедшие выталкивают нафиг первых  ;D

Думаю даже 3-й концерт Рахманинова и то проще залабать, он всего на 88 клавишах +2 педали. Но мне до него как до луны.

Вот это, про погрешность вейта надо бы учесть да не забыть как-то. А ещё лучше тестануть каким скриптом.
Не благодари
Code: (clickermann) [Select]
$timer1 = $_ms
WAITMS(5)
LOGWRITE ("время выполнения : ", $_ms - $timer1, " мс")
LOGWRITE (" ")
WAIT(1)
Сейчас с этим всё нормально. Я просто тестировал на прошлом компе, вот там и 5 мс часто становилось 0, а меньше так 100%

А я вот считаю более "человечными" (в смысле эмулирующими работу человека) задержки в диапазоне 200-500 мс (бывает задержка нужна до пары секунд, что здесь наверняка сочтут изуверством))
Вот первый попавшийся пример из моих рабочих скриптов:
[spoiler]
Code: (clickermann) [Select]
#include "..\Libs\Copy_Paste.cms"
#include "..\Libs\brawser.cms"
#name "Занесение атрибутов по одному"

//==============================================================================

// количество позиций
$all = 10

$part = 1
// 1 - тип
// 2 - материал
// 3 - напор
// 4 - производительность

$type = "циркуляционный" // скважинный
$mat = "нержавеющая сталь"  // чугун, нержавеющая сталь, хромоникелевая сталь

STRSEPARATE("4:6:8:10:12:4:6:8:10:12", ":", $nap)
STRSEPARATE("6,2:7,7:8,6:9,3:9,9:7,8:9,3:10,2:10,5:9,9", ":", $pr)

//==============================================================================


WAITMS(500)

FOR($iter=0, $iter < $all)
    next_tab()
    WAITMS(1000)
    HINTPOPUP(STRCONCAT("из ", $all), $iter + 1)
   
    // формат строки напора
    $s = $nap[$iter]
    IF(STRLEN($s) < 2)
        $napor =  STRCONCAT("  ", $s, " м")
    ELSE
        $napor =  STRCONCAT(" ", $s, " м")
    END_IF
   
    // формат производительности
    $s = $pr[$iter]
    IF(STRLEN($s) < 4)
        $proizv = STRCONCAT(" ", $pr[$iter], " м3/час")
    ELSE
        $proizv = STRCONCAT($pr[$iter], " м3/час")
    END_IF
   
   
    LCLICK(400,324)  // добавить атрибут
    WAITMS(600)
    LCLICK(406,394)  // список атрибутов
    WAITMS(800)
   
    // мотаем вниз на $n страниц
    IF(($part = 1) | ($part = 4))
        $n = 3
    ELSE
        $n = 2
    END_IF
    FOR($i=0, $i < $n)
        KEYPRESS(#PAGEDOWN)
        WAITMS(300)
    END_CYC
   
    // выбор атрибута
    SWITCH($part)
    CASE(1)
        LCLICK(456,497)  // тип  3
    CASE(2)
        LCLICK(515,784)  // материал  2
    CASE(3)
        LCLICK(515,784)  // напор  2
    CASE(4)
        LCLICK(504,481)  // производительность   3
    END_SWITCH
   
    // поле значение
    WAITMS(500)
    LCLICK(322,463)
    WAITMS(500)
   
    // вставляем значение
    SWITCH($part)
    CASE(1)
        TOCLIP($type)
    CASE(2)
        TOCLIP($mat)
    CASE(3)
        TOCLIP($napor)
    CASE(4)
        TOCLIP($proizv)
    END_SWITCH
   
    WAITMS(80)
    paste()
    WAITMS(300)
   
    // кнопка добавить
    LCLICK(266,507)
    WAITMS(1000)
END_CYC

HALT
[/spoiler]

Кстати, Винт, как я понимаю у тя родина Первомайск, а ты щас в Харькове обитаешь? А как там у вас щас обстановка и как город, сильно пострадал?
Я не в Харькове. А Первомайск - сильно. Все дома побиты и все школы, завод, шахта.
У друга квартира родителей сгорела, точнее весь подъезд.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Cleoss on November 25, 2016, 04:16:47 PM
Я пробовал именно указанный скрипт из твоего поста.
Тогда и не наю, что делать. У меня всё таки ж Пенёк, тут и частота послабее, и ядер меньше, кеш маленький/ шина тож не ого-го. Наверно поэтому и такая разница.

Я вот не пойму, ты действительно неординарная личность и способен запомнить эти "несколько сотен"/1000/2000 хоткеев и с ними реально работать? При чём несколько могут быть нажаты одновременно.
Я вот нет. Я десяток еле использую и то общеуниверсальных. Изредко в спецпрограммах + 5-7 штук, на больше меня не хватает. Получается очередь: последние зашедшие выталкивают нафиг первых  ;D
Думаю даже 3-й концерт Рахманинова и то проще залабать, он всего на 88 клавишах +2 педали. Но мне до него как до луны.
В том-то и фишка, я надеюсь, что как-нибудь найду некий инструмент, с помощью которого можно было б сделать интерфейс для набора подсказок-хоткеев в зависимости от запущенного/ активного окна (и не просто список, а кликабельный MRU). Хотя пару сотен хоткеев запомнить можно, если поморочиться неделю-другую, главное практика и повторы. Есть там много задумок для этой реализации, правда, опять же сильно сомневаюсь, что всё получится выразить в коде так, как изначально задумано. Но ещё охота зарезервировать некоторую долю хоткеев под часто употребимые символы юникода (там уж точно не нужно запоминать, а лучше их сделать по тегу-описанию).

Не благодари
Сейчас с этим всё нормально. Я просто тестировал на прошлом компе, вот там и 5 мс часто становилось 0, а меньше так 100%
Не, ну как же ж, благодарю  :) Как у автобусников: за спасибо спасибо, а за проезд плати.

Я не в Харькове.
Ну я имею ввиду, что не в ЛНР/ДНРе?
Просто, думаю.. что ж тут делать-то тебе?! Ни работы, ни банков, ни почты. Одни цены только как полагается -- на уровне Мск и выше. В общем, совок такой совок. Украинские каналы почти все пропали.

А Первомайск - сильно. Все дома побиты и все школы, завод, шахта.
У друга квартира родителей сгорела, точнее весь подъезд.
Мде, ппц, не повезло вам, нас меньше зацепило. И что, многие после этого съехали? стёкла многие восстановили? У нас в первые полгода с начала обстрелов город как затих, на улице почти никого, а примерно с весны уже повозвращались многие. Пригородам не хило досталось, многие дома частные разбиты, там две армии на танках схлестнулись. У соседа брата там завалили. Больше полугода обстрелы были, ну ты сам знаешь, а терь вот тишина +-, по крайней мере круглосуточной долбёжки нету как раньше. А в первую весну после войны ездил в Антрацит, так там наоборот кишило всё людьми, хотя у нас город как вымер тогда, меня это оч удивило.
Title: Re: [РЕШЕНО] Проверка условия повторного нажатия вместе с хоткеем iskeydown + ОПРОС
Post by: Золотой on November 25, 2016, 06:20:17 PM
В общем, совок такой совок. Украинские каналы почти все пропали.
Тут не принято банить за политическую пропаганду? Пусть у человека появится больше времени на просмотр любимых каналов, а то видимо сайт для перемогозрад попутал.