Single Post - Autorun :: Total Commander

Single Post

Topic: Autorun

Author

Message

Loopback

Posted: Fri Jun 14, 2024 14:31 Post subject:

Версия Autorun 2.2.11 beta

История изменений

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

Объекты

Изначально объектный синтаксис вообще не планировался. Собирался сделать только какой-нибудь списочный тип данных, с которым можно было бы работать по индексам. Какое-то подобие можно было изобразить и имеющимися средствами:

Code:

For i = 1 to 10
Set %'"var" & i' %'i*10'
Next

MsgBox %'Eval("var" & 4)'

Но выглядит это довольно устрашающе.

Понятно, что для работы с массивом пришлось добавлять синтаксис сабскриптов для обращения к переменной в виде var[index]. Ну а дальше, учитывая что массив это комплексный тип данных, объектный синтаксис добавился как-то естественно и породил новую сущность - объект.

В данный момент объекта два - List и Plugin. Почему List а не Array: c существующим API, похоже, я уперся в потолок. Реализовать массив так, как хотелось - с автоматическим контролем времени жизни - не выходит. Получается кривой, нестабильно работающий набор костылей. В то же время есть желание оставить свободу манёвра и не занимать имя Array, на случай появления возможности сделать более правильный массив.

Таким образом, в данный момент главное ограничение объектов - это то, что их нужно освобождать вручную функцией Free. В этом смысле они близки к объектам Delphi (типа TStringList). Если объект не освободить явно, то он все равно освободится при выгрузке плагина, но до того момента потребление памяти будет постоянно расти. В скриптовых языках массивы обычно освобождаются автоматически, когда переменная выходит из зоны видимости.

Второе ограничение: обращение через точку и с сабскриптом возможно только к одному объекту, не "нанизывая" их:

Code:

# не будет работать
r = obj1.prop.item[2]

# так правильно
prop = obj1.prop
r = prop.item[2]

Третье (условное) ограничение - нет традиционных обработчиков исключений. Но здесь нет и работы со сторонними объектами, а методы могут устанавливать переменную error, как и функции.

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

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

Дополнительные поля

Добавлена возможность создания из скрипта дополнительных полей, т.е. Autorun может выступать в роли обычного WDX плагина, только с формированием данных в скрипте. Фича достаточно несложная и тут без особых сюрпризов, если не считать того, что скриптовая часть не отличается высокой скоростью работы. Перспективы для оптимизации есть, но все равно, я бы не рассматривал это как полноценную замену тому же WinScript Advanced. Зато представляется более полезным для продвинутого формирования данных для стандартных подсказок тотала на основе данных других плагинов, т. е. по типу super_wdx.

Прочее

Также есть еще несколько существенных изменений, которые требуют внимания и тестирования:

Переделана работа пользовательских функций в многопоточном режиме. Раньше использование одной функции из разных потоков было чревато спонтанными ошибками. Сейчас в разных потоках выполняется свой экземпляр функции и больше таких проблем быть не должно.
Запуск и остановка скрипта перенесены в функции ContentSetDefaultParams и ContentPluginUnloading соответственно. Тестирую в этом режиме уже давно и как мне кажется, работа стала существенно стабильнее, особенно при выгрузке плагина с cm_UnloadPlugins. Каких-то побочных эффектов не заметил.
Затронуты функции, загружающие что-то резидентно (LoadLibrary, RunThread, ShellExecute с ключами /T и /TT, LoadFont),т.к. переделан метод хранения этих данных.
Был заметный баг, когда переменные могли напрямую разворачиваться в строчных и некоторых других функциях, чего быть не должно (в т.ч. согласно документации). Не исключено, что у кого-то мог код быть завязан на этом баге.

В остальном добавлены полезные и не очень функции, исправлено множество багов и наверняка добавлена куча новых.

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