Спасибо, что предложили временное решение проблемы.Orion9 писал(а): Да, в AHK есть примеры, как сделать обработку двойного или даже тройного нажатия клавиш, но и в Autorun можно сделать что-то похожее. Самый простой пример:В примере не учитывается обработка одиночного нажатия, но если она нужна, то её можно добавить.Код: Выделить всё
SetHotkeyAction /H:F12 F12DoublePress Func F12DoublePress() Static t1 = 0 If (GetUptime() - t1) < 300 Then ShowHint("F12 double pressed") EndIf t1 = GetUptime() EndFunc
Autorun
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Оба варианта не работают:
Что я опять не так делаю?
Код: Выделить всё
FileCopy("c:\PortablePrograms\FileManagers\TotalCommanderPortable\Plugins\wlx\TC1by1\rus\1by1.exe", "c:\PortablePrograms\FileManagers\TotalCommanderPortable\Plugins\wlx\TC1by1\1by1", 1)
FileCopy(COMMANDER_PATH & "\Plugins\wlx\TC1by1\eng", COMMANDER_PATH & "\Plugins\wlx\TC1by1\1by1", 1)AkulaBig
В первом случае непонятно, 1by1 на конце целевого пути - это существующий каталог или имя файла? Если имя файла, то у меня работает, а если имя каталога - то действительно, что-то не копируется. Что очень странно, такой сценарий точно тестировался.
Во втором - eng и 1by1 это же скорее всего каталоги? Тогда надо использовать DirCopy.
В первом случае непонятно, 1by1 на конце целевого пути - это существующий каталог или имя файла? Если имя файла, то у меня работает, а если имя каталога - то действительно, что-то не копируется. Что очень странно, такой сценарий точно тестировался.
Во втором - eng и 1by1 это же скорее всего каталоги? Тогда надо использовать DirCopy.
Имя каталога. Ибо:Loopback писал(а):Если имя файла, то у меня работает, а если имя каталога - то действительно, что-то не копируется
Код: Выделить всё
dest Полный путь к целевому файлу или каталогу. Ну я опять-же прочитал:Loopback писал(а):Во втором - eng и 1by1 это же скорее всего каталоги? Тогда надо использовать DirCopy.
Код: Выделить всё
При указании каталога без маски будут скопированы все файлы, находящиеся в нём.Я конечно вас понял. Новые команды, синтаксис пока не обкатан. Не знаю, ошибка это или нет. Вы меня знаете, мне и так сойдет. Лишь-бы работало. Думаю вы сами примете решение, ошибка это или нет. Я думаю, как минимум, если синтаксис отличается от стандартного, примеры привести-бы. А то там пример не дает представление, какой синтаксис правильный.
Добавлено спустя 2 часа 32 минуты:
Вот сейчас переделал копирование через DirCopy. Все отлично работает и понятно. Может тогда убрать не совсем понятные опции FileCopy и оставить возможность только одиночного копирования файла? Единственное, чтобы целевой каталог можно было-бы задавать без имени файла.
Можно, конечно, иначе бы смысла не было. Но как раз с этим сценарием и была проблема, странно, как она просочилась в релиз. Исправил.AkulaBig писал(а):То-есть в справке написано, что можно использовать целевой каталог.
Это мой косяк, забываю уже. Разумеется, просто каталог передавать тоже можно. Не работало по той же причине.AkulaBig писал(а):Ну я опять-же прочитал:
Именно так, получается, это первые тесты "со стороны", больше никто проблему не репортил. Это ошибка, конечно.AkulaBig писал(а):Новые команды, синтаксис пока не обкатан. Не знаю, ошибка это или нет.
Думаю не стоит. DirCopy копирует рекурсивно с подкаталогами, это не всегда требуется. А FileCopy по такому же принципу работает в Autoit/AHK, я ориентировался на них. Хотя примеры разных сценариев нужны, тут спорить не о чем.AkulaBig писал(а):Может тогда убрать не совсем понятные опции FileCopy и оставить возможность только одиночного копирования файла?
В общем, исправил, попробуйте эту версию.
Версия 05.08.2025
Код: Выделить всё
- исправлено копирование файлов в существующий каталог с FileCopy
- исправлена установка размера буфера в параметрах DllCall (регресс с версии 2.2.17)
Loopback
Потестю. А сейчас новый вопрос. Что-то поиском не нашел TextFile.
Почему вот это не работает?
Добавлено спустя 9 минут:
Протестировал FileCopy. Все отлично работает.
Потестю. А сейчас новый вопрос. Что-то поиском не нашел TextFile.
Код: Выделить всё
Local txt_SumatraPDF = COMMANDER_PATH & "\Plugins\wlx\TCSumatraPDF\SumatraPDF\SumatraPDF-settings.txt"
Local LangSumatraPDF = TextFile(txt_SumatraPDF, rw)
Local UiLang
LangSumatraPDF.Begin()
While Not LangSumatraPDF.AtEOF
UiLang = obj.ReadLine()
OutputDebugString(UiLang)
WendС этим полностью согласен.Loopback писал(а):DirCopy копирует рекурсивно с подкаталогами, это не всегда требуется.
Добавлено спустя 9 минут:
Протестировал FileCopy. Все отлично работает.
Если исправить две очевидные ошибки - rw должно быть в кавычках и obj.ReadLine() -> LangSumatraPDF.ReadLine(), то всё читается.AkulaBig писал(а):Почему вот это не работает?
Видимо, вы пользуетесь версией x64, где проблему с автозакрытием окна ошибки полностью так и не удалось решить. Поскольку на этих ошибках вываливается сообщение, чётко указывающее причину.
Блин, какой глупый косяк. Все заработало. Но окна ошибки нет ни в 32, ни в 64 ТС. Очень странно. Я-бы тогда и не спрашивал.Loopback писал(а):obj.ReadLine() -> LangSumatraPDF.ReadLine()
А с окном ошибки я вопрос легко решаю. Но решение не для этого форума. Приходится в загашнике держать нужный файлик.
Добавлено спустя 42 минуты:
Я специально легкий вопрос про ошибку задал. Чтобы немножечко размять ваши мозги
А теперь серьезный вопрос. Ну вот такой код работает. Но конечно-же записывает значение в конец файла. А мне надо заменить существующее значение. Можно-ли это сделать в рамках объекта TextFile? У метода WriteLine нет свойства - номер строки.
Код: Выделить всё
Local LangSumatraPDF = TextFile(txt_SumatraPDF, "rw")
Local UiLang
LangSumatraPDF.Begin()
While Not LangSumatraPDF.AtEOF
UiLang = LangSumatraPDF.ReadLine()
If StrPos(UiLang, "UiLanguage") > 0 Then
LangSumatraPDF.WriteLine("UiLanguage = en")
Endif
Wend
Более чем, у меня обе ошибки выдавало.AkulaBig писал(а): Очень странно.
Тут не совсем правильно то, что добавляется в конец файла, должно записаться сразу за строкой, где найдено UiLanguage. Впрочем есть догадка почему, потом посмотрю.AkulaBig писал(а): Можно-ли это сделать в рамках объекта TextFile?
Но такой сценарий - найти что-то в строке и изменить только эту строку, не получится. К сожалению, таких вольностей в произвольной записи, как с бинарными файлами, текст не позволяет. Даже если сделать возможность возврата на начало только что прочитанной строки, при записи строки большего размера она наложится на следующую строку, а если меньшего - создаст еще строку. Воткнуть такую строку корректно без перезаписи всего файла невозможно.
В любом случае использовать объект для файлика в пару килобайт - это как из пушки по воробьям. Целесообразнее прочитать его целиком и работать в памяти. Конкретно для этой задачи проще всего будет использовать List:
Код: Выделить всё
Local txt_SumatraPDF = COMMANDER_PATH & "\Plugins\wlx\TCSumatraPDF\SumatraPDF\SumatraPDF-settings.txt"
Local lst = List()
lst.LoadFromFile(txt_SumatraPDF)
For i = 0 to lst.Count-1
If StrPos(lst[i], "UiLanguage") > 0 Then
lst[i] = "UiLanguage = en"
Break
Endif
Next
lst.SaveToFile(txt_SumatraPDF)
Free(lst)
Очень интересно. Пришлось поковыряться, но проблему все-же нашел. Оказывается, начиная с какой-то строки кода перестает выводиться нормальное сообщение об ошибке. То-есть написал я строке 111. Появилось сообщение об ошибке. Написал 111 на 15-20 строк ниже. Окно сообщения об ошибке стало появляться в верхнем левом углу экрана, причем за пределами экрана:Loopback писал(а):Более чем, у меня обе ошибки выдавало.

Так как я работаю с распахнутым окном ТС, я это сообщение не заметил сразу. Причем в ТС32 даже этого огрызка не видно. Похоже сообщение полностью уходит за границы экрана.
Спасибо, я так и подумал. Некоторый опыт работы с текстовым файлом через List и через Dll у меня есть. С вашим кодом разберусь. Просто хотелось попробовать новый функционал.Loopback писал(а):Конкретно для этой задачи проще всего будет использовать List
А вот это уже интересно. Похоже баг именно нового окна ошибки. Вероятно, связано с кодом позиционирования, который пытается расположить окно по центру окна TC. Но возможно, в момент его выполнения окно TC находится не в той позиции, где нужно. И остается непонятна зависимость от строчки кода, тут скорее все же какие-то другие факторы.AkulaBig писал(а):Окно сообщения об ошибке стало появляться в верхнем левом углу экрана, причем за пределами экрана:
В любом случае у себя так и не смог повторить. Сделал отладочную версию, c выводом в DebugView, можете глянуть у себя, какие получаются координаты окон в момент возникновения проблемы?
Понятно, но для всего свои инструменты. Для этой задачи объект не подходит.AkulaBig писал(а):Просто хотелось попробовать новый функционал.
Ну точно. Координаты минусовые:Loopback писал(а):какие получаются координаты окон в момент возникновения проблемы?

А вот когда окно ошибки видно:

Вот сама ошибка:

Странная проблема. Раньше при правильном расположении окно было видно пока не нажмешь кнопку. Я имею ввиду если не появляется наг-скрин. А сейчас я его только гифкой поймал. Оно показывается и быстро исчезает. Это не с тестовой версией плагина, а уже до этого. Сейчас проверю на оф версии.
Буду знать.Loopback писал(а):Понятно, но для всего свои инструменты. Для этой задачи объект не подходит.
Добавлено спустя 10 минут:
Блин. 2.2.1 у меня уже не работает. А 2.2.1.19.1 также работает. Не могу проверить. Именно это окно исчезает или на всех ошибках. Все забываю написать. ТС и 32 и 64.
Очень интересные координаты у окна тотала. Ничего удивительного, что диалог появляется где-то за экраном. В общем ясно, что центрировать относительно окна тотала можно не всегда, в таких вот пограничных состояниях надо выравнивать по центру экрана. Осталось только понять, как такое состояние достоверно отличить от нормального. Не уверен, что прямоугольник всегда будет 1 0 1 0.AkulaBig писал(а):Ну точно. Координаты минусовые
Вот что еще подумал, я не проверяю результат GetWindowRect, надо бы убедиться, что функция выполняется без ошибки, ну мало ли, иначе, полагаю, прямоугольник может содержать что-нибудь случайное. Заодно еще пару параметров проверим. Выложил по той же ссылке, проверьте, пожалуйста, еще раз. Достаточно будет только проблемного варианта.
Я не очень понял, что где проявляется, но вроде как проблемы автозакрытия окна никогда на 32-битном тотале не было.AkulaBig писал(а):Оно показывается и быстро исчезает
Ох уж эти ковровые блокировки, картинки только через впн удалось увидеть...
Дак это координаты окна ТС? Странно. Я думал координаты сообщения. Что верно по факту. Окно ТС находится на экране.Loopback писал(а):Очень интересные координаты у окна тотала.
Сейчас.Loopback писал(а): проверьте, пожалуйста,
Добавлено спустя 16 минут:
Loopback

Я понял про координаты ТС и окна ошибки. Просто до этого не разбирался с результатом. Конечно окно ТС показывает неадекватный результат. Из-за этого ваше окно и уходит за пределы экрана. Сегодня общался с Гислером. Он назвал мой файл странным:

Вот я ввел новый атрибут файла
Координаты тоже СТРАННЫЕ
AkulaBig
Ого. Всё даже ещё интереснее. GetWindowRect выполняется с ошибкой (соответственно, координаты неверны), GetLastError даёт ошибку "неверный дескриптор окна". Т.е. как будто полученный ранее хэндл окна тотала - неверный. По строке TCWindow ... Handle видно, что он не нулевой, а значит был чуть ранее успешно получен поиском TTOTAL_CMD. Однако именно в этом месте по этому хэндлу не удается ничего получить - ни координаты, ни класс окна...
Честно говоря, пока не знаю что думать. Конечно, исправить именно эту проблему с диалогом можно, но смущает этот "неверный дескриптор окна", учитывая что это значение используется в огромном количестве мест (в т.ч. переменная AUTORUN_TCHANDLE). Хотя до сих пор никто не жаловался, что её значение невалидное, да и много чего не работало бы.
Кстати, я так понимаю, это такое на обеих разрядностях? И, в случае нормального выполнения, в строке Class: показывается "TTOTAL_CMD"?
Плохо, что у меня не повторяется, даже проверил на виртуалке с Win11, но увы.
Ого. Всё даже ещё интереснее. GetWindowRect выполняется с ошибкой (соответственно, координаты неверны), GetLastError даёт ошибку "неверный дескриптор окна". Т.е. как будто полученный ранее хэндл окна тотала - неверный. По строке TCWindow ... Handle видно, что он не нулевой, а значит был чуть ранее успешно получен поиском TTOTAL_CMD. Однако именно в этом месте по этому хэндлу не удается ничего получить - ни координаты, ни класс окна...
Честно говоря, пока не знаю что думать. Конечно, исправить именно эту проблему с диалогом можно, но смущает этот "неверный дескриптор окна", учитывая что это значение используется в огромном количестве мест (в т.ч. переменная AUTORUN_TCHANDLE). Хотя до сих пор никто не жаловался, что её значение невалидное, да и много чего не работало бы.
Кстати, я так понимаю, это такое на обеих разрядностях? И, в случае нормального выполнения, в строке Class: показывается "TTOTAL_CMD"?
Плохо, что у меня не повторяется, даже проверил на виртуалке с Win11, но увы.