Autorun

[Orion9]

Loopback
Возможно, нашел в чем причина зависаний. Похоже, поток с циклом просто вылетает без каких-либо сообщений об ошибке.

Шаги в цикле разделены так:

Код: Выделить всё

Step 1. TorrentGet
Step 2. WinSetText
Step 3. FileFindEv
Step 3. aQuery.Text 
Step 4. aCount.Add
Step 5. sList
Step 6. sDirs
Step 7. StrReplace
Step 8. Next

Третий шаг продублирован, т.к. я исключил aQuery.Text из строки запроса и сделал дополнительный, временный шаг через строковую переменную. Проблема не ушла, и я уж думал, что стоит попробовать обновить Everything, но тут пришла мысль "а что происходит с циклом? он что, так и продолжает висеть?". Т.е. если 3-4 раза зависнет, то по идее 3-4 потока должно висеть и ждать ответа, к тому же вы говорили про тайм-аут, который никак о себе не говорит. В общем, вложил вызов функции в поток:

Код: Выделить всё

Func FindTorrentParts(lParam)
    RunThread "ThreadTorrentParts" lParam
EndFunc 

И сразу все увидел. Старт происходит нормально:

Код: Выделить всё

Thread #1:
    Origin: Main
    ThreadID: 7128
    Started: 06.10.2025 18:14:54

Thread #2:
    Origin: RunThread
    Function: Function: ThreadTorrentParts
    ThreadID: 1548
    Started: 06.10.2025 18:15:16

Thread #3:
    Origin: RunThread
    Function: Function: WinFindTorrentData
    ThreadID: 2020
    Started: 06.10.2025 18:15:16

Но затем поток ThreadTorrentParts просто исчезает, а окно прогресс-бара продолжает висеть, т.к. оно крутится в отдельном потоке:

Код: Выделить всё

Thread #1:
    Origin: Main
    ThreadID: 7128
    Started: 06.10.2025 18:14:54

Thread #3:
    Origin: RunThread
    Function: Function: WinFindTorrentData
    ThreadID: 2020
    Started: 06.10.2025 18:15:16

И кстати, как только я стал запускать отдельным потоком, в отладочной информации остановка не только на третьем шаге стала фиксироваться, но и на пятом и даже на восьмом, что особенно забавно, учитывая, что между восьмым шагом и первым стоит всего одно условие проверки глобальной переменной:

Код: Выделить всё

# перечисление файлов в торренте
For j = 0 To nCount - 1
    
    If gTorrentDbg Then gDbgStep = "Step 1. TorrentGet j=" & j & auCRLF
    
    ....
    ....
    
    If gTorrentDbg Then gDbgStep &= "Step 8. Next"
    
    # опрерация прервана закрытием окна прогресса
    If g_FindTorrTask = 0 Then Break
Next

В общем, надеюсь, мне удалось обозначить проблему, но есть еще один существеный нюанс. Этот косяк происходит только в ТСх64. В ТСх32 работает стабильно.

A55555
Даже не знаю, что у вас не так с экраном. У меня подобной проблемы нет - обновление и перерисовка происходят в штатном режиме. А вот проблема с зависанием, увы, никуда не делась, но будем надеяться, что то, что я написал выше, поможет Loopback найти причину.

Дело, конечно, не только в Blu-ray дисках. На любых торренах, где есть много вложенных файлов (аудио, музыка и т.д.), такое случается, и часто. Хотя, как я уже говорил, эта проблема характерна только для 64-битного ТС. Вы проверяли работу функционала на 32-битном ТС? Может быть и проблема с экраном тоже уйдет.

Если проблема только с перерисовкой, то решение, которое я вчера запостил должно помочь. Обе эти команды - 70501 и 70504 - заканчивают свою работу функцией GoToPathFromMsg, которая и осуществляет переход. В обновленную функцию выше я уже добавил команды для перерисовки и обновления панели, поэтому нет необхожимости отдельно их добавлять к 70501 и 70504.

В следующий раз когда экран не обновится, просто нажмите Ctrl+R, если это поможет, то и посылка SendCommand(540) тоже должна помочь.

[A55555]

A55555
Даже не знаю, что у вас не так с экраном. У меня подобной проблемы нет - обновление и перерисовка происходят в штатном режиме.

Orion9
я нашел причину.
В Torrent.aucfg активирован gCapsReverse = 1 (не спрашивать ничего при выключенном CapsLock).

В подсказке MediaInfo тоже активирована ваша для удобства опция gHintCaps = false (показывать расширенную подсказку при выключенном CapsLock).

Это привело к накладке.
Курсор не каждый раз, но попадал во время старта поиска (через горячие клавиши), то на торрент файл, то на медиафайл и ваша расширенная подсказка MediaInfo успевала перехватить на себя фокус или вроде того.
Если специально отводить курсор в "нейтральное" место, где подсказка не сможет найти себе работу (перед стартом поиска), то всё будет нормально или через кнопку на панели, если бы я это делал, то даже и не столкнулся бы с этой накладкой, но я горячими клавишами.

Пожертвовал подсказкой MediaInfo и указал только при включенном CapsLock через gHintCaps = true и всё стало хорошо с обновлением противоположной панели при поиске.


С добавлением строк в Func GoToPathFromMsg(Target)

Код: Выделить всё

WinRedraw(1)
       SendCommand(540)     # cm_RereadSource 

совместное вот такое использование подсказка_MediaInfo при выключенном CapsLock также проблематично, проверил ради интереса, тоже всякое случается.

[Loopback]

Похоже, поток с циклом просто вылетает без каких-либо сообщений об ошибке.

При нормальном выполнении поток не может "вылететь" просто так. Единственная для него возможность завершиться - это либо выполнение всего кода, либо по сигналу завершения при закрытии тотала или перезапуске скрипта.

Однако подобная картина может возникнуть при необработанном исключении в какой-то функции потока, и пока что (судя по данным отладки на предыдущей странице) всё указывает на проблему в FileFindEv. Когда доберусь до кода, проверю её на предмет очевидных косяков, если что сделаю отладочную версию.

[Orion9]

A55555
Надеюсь, что так и есть и проблема с экраном больше не будет вам мешать. Можно еще попробовать увеличить задержку у подсказки через gHintWait (если вы хотите, чтобы она всегда висела без CapsLock), но тогда все три подсказки будут появляться медленнее.

А на счет зависаний, попробуйте все-таки 32-битную версию ТС, будет у вас виснуть? У меня вроде нет. Вообще, ТСх32 более стабилен во многих ситуациях, поэтому есть смысл проверять в 32-битной версии, в случае каких-то проблем в 64-битной.

Loopback
Надеюсь, найдете причину. Но поток на самом деле завершается без сообщения об ошибке. Второй поток с окном прогресса при этом просто продолжает висеть не получая новых сообщений об изменении текста в заголовке, что и вводит в заблуждение, что операция зависла.

[A55555]

A55555
А на счет зависаний, попробуйте все-таки 32-битную версию ТС, будет у вас виснуть? У меня вроде нет. Вообще, ТСх32 более стабилен во многих ситуациях, поэтому есть смысл проверять в 32-битной версии, в случае каких-то проблем в 64-битной.

Orion9
попробовал ТСх32 из той же сборки.
Действительно, пока ни одного зависания на том полноценном Blu-Ray.
Если так и есть, то 70504 получается на все случаи подходит.

[Orion9]

A55555
Спасибо, что проверили и подтвердили работоспособность в 32-битной версии. Это вселяет надежду, что в ТС х64 все тоже будет нормально.

Да, 70504 более универсальна, но если нужен поиск по полному размеру раздачи, то лучше сначала использовать 70501, так будет быстрее. 70504 перебирает файлы внутри, поэтому будет немного дольше и менее точнее, но зато может найти частично закаченные данные.

[Orion9]

Loopback
В последней версии GetRaw у буфера сломался. Хотел подумать, как лучше обойти ограничение у той эксперементальной функции, а тут такое. Раньше этот вызов, кстати, работал.

Может добавить объекту Buffer метод сохранения всего содержимого сразу в файл? Пригодилось бы.

[Orion9]

Loopback
В последней версии в окно DebugView стали попадать лишние сообщения о "SaveStatic:". Некоторые функции, запущенные в цикле, буквально засыпают это окно и не дают им нормально пользоваться.

[Loopback]

В последней версии GetRaw у буфера сломался.

Точно, закралась мелкая ошибка.

Может добавить объекту Buffer метод сохранения всего содержимого сразу в файл? Пригодилось бы.

Не знаю даже, только сохранение без загрузки кроме незначительного удобства для отладки не дает. А если делать парно, то по-сути получается повторение функционала BinaryFile.

В общем надо подумать.

В последней версии в окно DebugView стали попадать лишние сообщения о "SaveStatic:". Некоторые функции, запущенные в цикле, буквально засыпают это окно и не дают им нормально пользоваться.

Ага, забыл убрать отладочный код.

Файл с исправлениями ниже.

Версия от 13.10.2025

Код: Выделить всё

- исправлен метод GetRaw объекта Buffer
* оптимизированы некоторые критичные к скорости функции
* дальнейшие внутренние чистки

[Orion9]

по-сути получается повторение функционала BinaryFile

Да, вот до BinaryFile я еще не успел добраться, а у него есть метод WriteRaw, который как раз и делает что нужно. В общем, осталось только вспомогательную функцию сделать в самом Autorun, не должно быть сложно.

Файл с исправлениями ниже.

Проверил, все работает. Спасибо.

Без просмотра буфера будет туго. Обнаружил тут прикол на сайте майкрософт. В статье говорится, что тип данных у ExtentCount - DWORD, а по факту он 8 байт получается. Заменил в коде все "dword" на "int64" - работать стало как часы. Би$$и за такое на линух пересаживать надо, а то я уж хотел MakeInt подлючать, чтобы собирать юнион задом наперед.

[Orion9]

Loopback
Добрался до расширенного меню. Всё классно, но есть небольшой бажек.

Функция UserFunc не будет вызываться, если в записи не указан индекс иконки:

Код: Выделить всё

MENUITEM "Функция UserFunc", em_aucmd UserFunc

Пока решил обходить параметром -1:

Код: Выделить всё

MENUITEM "Функция UserFunc", em_aucmd /C -1 UserFunc

Ещё воппрос. А как макрос SYSINFO_USERLANG получает своё значение?

[Loopback]

Обнаружил тут прикол на сайте майкрософт. В статье говорится, что тип данных у ExtentCount - DWORD, а по факту он 8 байт получается.

Мне кажется там всё правильно, просто дело в выравнивании структуры. Хотя ExtentCount и DWORD, в этой структуре он будет выровнен по границе 8 байт и будет фактически занимать 8 байт, т. к. следующее поле - 64 битное целое. Т.е. с начала структуры 4 байта DWORD, а за ним еще 4 неиспользуемых байта (т.н. padding). Суммарный размер структуры получается минимально 32 байта + 16 байт на каждый последующий элемент массива.

Всё классно, но есть небольшой бажек.

Функция UserFunc не будет вызываться, если в записи не указан индекс иконки:

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

Так что использование -1 правильный вариант, если нужно получить значок по умолчанию. Или можно использовать пустую строку "", если значок не нужен.

А как макрос SYSINFO_USERLANG получает своё значение?

Код: Выделить всё

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SABBREVLANGNAME, buffer, BUFFER_LENGTH);

[Orion9]

Loopback
Да, я понял потом, что это было выравнивание. Сначала просто был нацелен на результат и оставил разбирательства на потом, хотя уже тогда подумалось, что как-то не лепится за 4 байтами смежно цеплять 8-байтовую структуру и эти оставшиеся 4 байта все-равно должны будут где-то всплыть, вот они и всплыли в итоге. Спасибо вам за объяснение.

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

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

Ясно. Как всегда не дочитал. Но хорошо, что так. В смысле, что не баг.

GetLocaleInfo(LOCALE_USER_DEFAULT, LOCALE_SABBREVLANGNAME, buffer, BUFFER_LENGTH);

Спасибо. Гляну.

[yahuu]

SendCommand(1001,, 1)
--2.2.19 ：OK
--2.2.21 ：Incorrect numeric parameter in SendCommand call.

В командной нотации, если нет параметров при + wait, как следует писать SendCommand?

SendCommand 1001 "" 1 ?

[Loopback]

SendCommand(1001,, 1)

Официально синтаксис с пропуском параметра пока не заявлен, не все функции адекватно реагируют на него. Пропущенный параметр фактически передает пустую строку.

Это действительно было сломано при оптимизации, пустая строка для числового параметра должна приводиться к 0. Исправленная версия ниже.

SendCommand 1001 "" 1

Да, можно и так, но более правильно:

Код: Выделить всё

SendCommand 1001 0 1 

Версия от 15.10.2025