2bk

Вот файл, пожалуйста. Система, драйверы и абсолютно весь остальной софт разной направленности (включая 3 автоматически авторизующихся мессенджера, программы синхронизации с разными сетевыми и bluetooth-устройствами, игры, геймерское и стримерское ПО, захваты изображений, всяческие афтербернеры, несколько VPNов и тд) работают идеально даже после вот такого отключения света. А вот Keyran, к сожалению, в такой ситуации сбоит описанным образом. Надеюсь, лог поможет выявить проблему. В event viewer->application ошибок в наблюдаемый период нет, это я перед публикацией еще проверил. У меня есть версия, что Keyran сбоит в условиях настоящей админской среды (встроенной учетной записи "Administrator"), т.к. аномалии наблюдались и на других версиях Windows и других физических системах, объединялись которые в первую очередь этим фактором. all.log

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

Да-да, я понял, что вы перепутали тему обращения, потому повторно акцентирую Ваше внимание: багрепорт посвящен исключительно ошибкам в редакторе макросов, в интерфейсе программы. Драйверы, эмуляция нажатий в целом, взаимодействие с устройстами и ОС - ничего из этого не упоминалось, ибо никакого отношения к теме не имеет (с этим пока всё норм!). Спасибо за внимание 🤝

Я думал, Вы и есть производитель Keyran. Багрепорт посвящен функционалу редактора макросов и интерфейсу - у Вас в них кнопки местами перепутаны (помимо очень странных названий данных клавиш, из-за которых, очевидно, и допустили ошибку). Довольно подробно же описал. Еще раз, только кратко: в текст макроса вбивается Button4down-Button4Up, когда мы вбиваем в него пятую кнопку мыши. И зеркально с другой указанной кнопкой. Причем тут драйвер? 🙂 Макросы неправильные создаются (даже без запуска основной части программы, которая нажатия имитирует). Хоть в оффлайн режиме, при любых настройках и тд. Вы это все побороть можете исправлением интерфейса, переименовав везде строго в Mouse4 и Mouse5 без путаницы 🙂 А текущие названия при использовании в разных частях программы дают разный результат.

А теперь об ошибках непосредственно внутри софтины. 1) Эти невыносимые названия кнопок мыши, которые постоянно путают пользователя (Mouse4 и Mouse5 почему-то называются в интерфейсе "Боковая кнопка мыши (вверх)"/"Боковая кнопка мыши (вверх)") - это крайне неприятно в использовании, но терпимо, если не пользуешься постоянно. Что за таинственная "боковая кнопка мыши" и почему она то вверх, то вниз, - непонятно, но да ладно. Усугублялось тем, что при написании макроса эти "вверх" и "вниз" легко перепутать с KeyDown и KeyUp - нажатиями и отжатиями. Но это еще косметика, допустим. 2) Гораздо хуже оказалось другое. То, что в главном окне программы называется "Боковая кнопка мыши (вверх)", - это Mouse5. То, что в главном окне программы называется "Боковая кнопка мыши (вниз)", - это Mouse4. А в редакторе макросов все ровно наоборот (сколько же это крови попило, прежде чем обнаружилось). "Боковая кнопка мыши (вверх)" это уже Mouse4, а "Боковая кнопка мыши (вниз)" это уже Mouse5. То есть назначаем одну кнопку - вместо нее работает другая. И наоборот. Мне кажется, если бы их изначально назвали нормально (4 и 5, а не вот это вот все), то этой ошибки бы и не произошло. В англоязычной версии, насколько помню, та же ошибка. 3) Синтаксис. У одной из этих двух кнопок нажатия и отжатия почему-то "down", но "Up". У другой - "Down", но "up". Не только нет единой иерархии, которой подчинены остальные кнопки мыши (там везде с большой буквы - "Up"/"Down"), но и между собой у них нет соответствия. Button4down Button4Up Button5Down Button5up Причем программа отказывается выполнять действия, в коде которых есть хоть какие-либо отклонения от предусмотренного регистра, что тоже неприятно удивляет, т.к. это ограничение не имеет абсолютно никакого практического смысла, ни от чего не защищает и ничего не приносит. По крайней мере, для пользователей. Хотелось бы когда-нибудь увидеть отсутствие этого ограничения, тем более когда в синтаксисе команд нет единой нормы.

Это еще ерунда. Хуже - когда ОС/браузер англоязычные. В этом случае любые попытки оплатить программу, в том числе переходом с акционных ссылок со скидками из русскоязычной версии программы, в том числе с РУ IP, в том числе сколько ни выбирай на самом сайте русский язык, - все равно принудительно перенаправляет на англоязычную форму оплаты с совершенно другими ценниками в другой валюте.

Мы же с Вами понимаем, что софтина-индикатор - просто датчик, запускается только для наглядной демонстрации проблемы (а в целом не используется вообще). Сама-то проблема повсеместная, везде (от рабочего стола до игр) воспроизводится идентично, вне зависимости от выбранного датчика и версии этого датчика. И ее не получается обойти никоим образом. 😞 И только после осознания неотвратимости этого бага мы уже запускаем клавиатурный тест и демонстрируем в нем. Следующий встреченный баг сниму в другой версии, без проблем. А пока бы этот устранить. Благо в логах активно спамятся сообщения об ошибке - у Вас наверняка есть понимание своих логов.

https://disk.yandex.ru/d/QnQXNnjvfDoW2A ну вот тут файл макроса, файл логов и полноэкранное видео с воспроизведением ошибки (хотя в нем происходит все то же самое, что я уже демонстрировал). все тот же баг - вместо однократного воспроизведения всего макроса идет спам его неполного сценария (трудно не заметить, что в тексте имеется заметная - почти трехсекундная - задержка, а на деле ее нет - вместо это строчит, как пулемет). этот баг касается именно режима "без повторений". если тому же самому макросу присвоить режим "зажать, чтобы запустить" - то макрос начинает сразу же работать корректно.

а какая утилита устроит для демонстрации? и не совсем понял, как можно еще более прямо продемонстрировать проблему, чем крупным планом наглядно показав работу двух режимов (исправный VS неисправный) 🙂

Долго не мог понять, в чем же снова ошибка. Нашел: Когда макросу присвоен режим "без повторений", запускающая его клавиша вместо однократного воспроизведения начинает просто дико спамить часть макроса. Это настолько необъяснимо, что решил создать соответствующий топик. Макрос специально сделал кратчайший и нагляднейший. 1 зажатие длиной 6сек + пауза 6 сек. Пока макросу присвоен режим вопроизведения при зажатии - все работает нормально. Переводим в режим однократного воспроизведения - макрос сходит с ума и вместо единственного заданного действия начинает просто люто спамить кнопку, полностью "забив" на заданные паузы..... Не происходит даже одного выполнения заданного 12-секундного сценария. Нагляднейшая демонстрация: https://disk.yandex.ru/i/ihn00etPpgXOuw

Макросы с участием нажатий Button4down, Button5Down работают неадекватно. Возможно, и других кнопок мыши - не тестил. По крайней мере, макросы с участием детектора цвета как минимум. Чего я только не перепробовал - макрос с определением цвета пикселей постоянно прерывался. Либо "сходил с ума", уходил в бесконечность (выполнялся до бесконечности, и это в режиме "зажатия", что нонсенс). Грешил на баг с определением цвета. Но нет, ошибка состоит именно в использовании озвученных кнопок мыши. Как только поменял их на клавиатурные нажатия (ничего более не трогая), все заработало идеально. Более того, обращаю Ваше внимание на то, что у них даже синтаксис странный. У одних Down/Up с заглавной, у других - с обычной: Button5Down, но Button4down. Button4Up, но Button5up. Времени на это убилось очень много. Надеюсь, не зря делюсь результатами. Заранее благодарю. Макросы с демонстрацией замены прикладываю. _dalwjd.amc +dalwjd.amc

Я немного о другом спрашивал, но не суть. Целый день уже суммарно убил на это, но, кажется, нашел причину ошибки. Пойду зарепорчу ее в соответствующей ветке.

В макросе есть несколько проверок цвета различных пикселей. Все выверено, но все равно работает максимально нестабильно. Хотя, казалось бы, это маловероятно, ведь правила всегда одни. У меня возникает подозрение, что определение цвета работает либо с большой задержкой (просто сильно отстает и "скипается"), либо все определения всех цветов всех участков происходят в один момент - момент запуска макроса (и процесс вообще не реагирует на изменения цветов пикселей во время активной работы макроса). Можно ли получить сколь-либо подробное описание этой функции? В какой момент происходит анализ цветов заданных пикселей?