Loopback
А, ну ОК, тогда я спокоен.
Autorun
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Версия 2.2.3 beta
+ добавлены сообщения об ошибках синтаксиса в циклах
- исправлено сообщение, когда отсутствует Then в условнии
+ Tab может использоваться аналогично пробелу в выражениях
+ дополнительная проверка ошибок синтаксиса в выражениях
+ добавлена директива LegacyExpressions
+ добавлено сообщение при попытке добавить функцию с дублирующимся именем
- при разбиении строк пробел перед _ не будет удаляться
- исправлена передача параметра по ссылке
- исправлена проблема с остановкой парсера на неподдерживаемых символах
- исправлен парсинг задания переменных без начального значения
- исправлен запрет на присвоение значений макросам и константам
- исправлена ошибка парсера с ключевыми словами or, and, not в условиях
- Tweaks: исправлена работа с модификаторами (снова, и снова, и снова)
Крупных изменений нет, в основном фиксы и оптимизации. Обсуждаемая ранее директива реализована и действует. Страница бета-функционала дополнена.
По поводу ControlSetMouseAction - менять что-то нет смысла, в ФЗ она и будет записываться, как в этом посте, за исключением того, что в "новом" режиме имя команды ShellExec также должно быть в кавычках (т.к. это обычная строка, один из параметров ControlSetMouseAction).
Но с этой командой без исключений никак, есть один момент: трюк, когда при запуске команды выполняется вычисляемая строка в ее параметрах, в функциональной записи невозможен (и неважно в каком режиме). Т.е. если в командной записи
при каждом запуске CommandExec выполняется вычисляемая строка с IniRead, то в функциональном режиме она выполнится только один раз при запуске ControlSetMouseAction. Но вообще-то такое поведение в командной записи ControlSetMouseAction и не предполагалось, по сути это баг 
Нужного эффекта можно достигнуть через пользовательскую функцию-прослойку, но по-моему, если нужен именно этот результат, проще записать команду в командном виде.
+ добавлены сообщения об ошибках синтаксиса в циклах
- исправлено сообщение, когда отсутствует Then в условнии
+ Tab может использоваться аналогично пробелу в выражениях
+ дополнительная проверка ошибок синтаксиса в выражениях
+ добавлена директива LegacyExpressions
+ добавлено сообщение при попытке добавить функцию с дублирующимся именем
- при разбиении строк пробел перед _ не будет удаляться
- исправлена передача параметра по ссылке
- исправлена проблема с остановкой парсера на неподдерживаемых символах
- исправлен парсинг задания переменных без начального значения
- исправлен запрет на присвоение значений макросам и константам
- исправлена ошибка парсера с ключевыми словами or, and, not в условиях
- Tweaks: исправлена работа с модификаторами (снова, и снова, и снова)
Крупных изменений нет, в основном фиксы и оптимизации. Обсуждаемая ранее директива реализована и действует. Страница бета-функционала дополнена.
По поводу ControlSetMouseAction - менять что-то нет смысла, в ФЗ она и будет записываться, как в этом посте, за исключением того, что в "новом" режиме имя команды ShellExec также должно быть в кавычках (т.к. это обычная строка, один из параметров ControlSetMouseAction).
Но с этой командой без исключений никак, есть один момент: трюк, когда при запуске команды выполняется вычисляемая строка в ее параметрах, в функциональной записи невозможен (и неважно в каком режиме). Т.е. если в командной записи
Код: Выделить всё
ControlSetMouseAction /R /H:64 0 CommandExec em_Lang %"IniRead('~/R', %COMMANDER_INI%, Configuration, LanguageIni)" Нужного эффекта можно достигнуть через пользовательскую функцию-прослойку, но по-моему, если нужен именно этот результат, проще записать команду в командном виде.
Виде? Без смены режима? Это как?Loopback писал(а):если нужен именно этот результат, проще записать команду в командном виде.
У LegacyExpressions свитч-то есть? Ты же обещал 2 прагмы. Иначе смысл?
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Ну записи. В общем, как в приведенном примере.Flasher писал(а):Виде?
Две-то зачем? Нет прагмы - новый режим, есть - старый.Flasher писал(а):У LegacyExpressions свитч-то есть? Ты же обещал 2 прагмы. Иначе смысл?
Код: Выделить всё
Pragma LegacyExpressions
Так без LegacyExpressions он не работает.Loopback писал(а):В общем, как в приведенном примере.
Как это зачем? Сперва пишу в LegacyExpressions, а потом отключаю и пишу в умолчательном, что избежать проблем старого режима. В этом и суть.Loopback писал(а):Две-то зачем?
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Естественно, Configuration и LanguageIni без кавычек. Если включить LegacyExpressions - будет работать.Flasher писал(а):Так без LegacyExpressions он не работает.
Ничего не понялFlasher писал(а):Как это зачем? Сперва пишу в LegacyExpressions, а потом отключаю и пишу в умолчательном, что избежать проблем старого режима. В этом и суть.
Зачем что-то писать в режиме LegacyExpressions, если всё что у тебя есть - и так в нём написано?Если есть желание исправлять старый код под новую версию - без LegacyExpressions исправляешь, не хочешь - включаешь LegacyExpressions - и все работает как в прошлой релизной версии.
Я спросил "Без смены режима?", ты ответил "Ну записи.".Loopback писал(а):Естественно
Я тем более. Как это зачем? Если всё в нём написано, то логично в нём и писать. А если после надо какую-то часть написать в ФЗ (например, для указания переменных без %), то логично переключиться обратно.Loopback писал(а):Ничего не понял
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Ты вроде тут писал, что стало понятно.Flasher писал(а):А если после надо какую-то часть написать в ФЗ
ФЗ - она при любой прагме ФЗ. Я же в обновленной справке в разделе "Синтаксис" разжевал всё подробно: прагма управляет интерпретацией ФЗ. По умолчанию включена правильная, которая исключает неоднозначности и обеспечивает корректную обработку ошибок, но можно переключиться на старую, если сложно/лень/нет времени вносить изменения в свой имеющийся код.
Что и как будет работать в каждом из режимов — да, стало понятно. Но я не хотел и не предполагал, что один из режимов будет выбит наглухо...Loopback писал(а):Ты вроде тут писал, что стало понятно.
Тем более, что сам пишешь, что есть не только функциональная разница, но и отладочная. И тут дело не в лени вовсе.
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
У меня возникает стойкое ощущение, что иногда мы мыслим в противофазе. Полное отсутствие взаимопонимания.
В общем своё понимание я подробно документировал. Что куда и почему "выбито", откуда вообще взялось ожидание каких-то двух прагм и для чего они две нужны - мне так и осталось непонятным. Лучше я объяснить уже не смогу, так что я - пас.
В общем своё понимание я подробно документировал. Что куда и почему "выбито", откуда вообще взялось ожидание каких-то двух прагм и для чего они две нужны - мне так и осталось непонятным. Лучше я объяснить уже не смогу, так что я - пас.
При чём тут взаимопонимание? Я твой ликбез в целом прекрасно понял. Да и ты мой нужник наверняка тоже. А вот отсутствие желания с твоей стороны и только, это уже совсем другой разговор.
Почему "выбито" толком объяснено не было. Была только констатация текущего положения. Любая прагма работает с места, а не по всему коду, если не задана первой строкой. То есть имеем потенциал разделения на две части. С остальными прагмами понятно, там переключатель бессмысленен. А почему тут нет доступа к переключателю для возврата к синтаксису, который как минимум "имеет корректную обработку ошибок", так однозначного (хотя бы что-то типа "это очень трудоёмко, по такой-то причине надо много переписывать", "замедлится скорость" и т. п.) пояснения и не было.
Почему "выбито" толком объяснено не было. Была только констатация текущего положения. Любая прагма работает с места, а не по всему коду, если не задана первой строкой. То есть имеем потенциал разделения на две части. С остальными прагмами понятно, там переключатель бессмысленен. А почему тут нет доступа к переключателю для возврата к синтаксису, который как минимум "имеет корректную обработку ошибок", так однозначного (хотя бы что-то типа "это очень трудоёмко, по такой-то причине надо много переписывать", "замедлится скорость" и т. п.) пояснения и не было.
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
И нафига бы это мне? Слишком много лишнего времени, что захотелось поразвлекаться перепиской на несколько страниц?Flasher писал(а): Да и ты мой нужник наверняка тоже.
Ну наконец хоть что-то стало проясняться. Вот это была большая ошибка так думать. До сих пор единственная прагма, работающая в конкретном месте - это была FinalizeSection. Теперь добавилась Include, вставляющая по этому месту содержимое файла. Всё. Остальные прагмы - глобальные, и размещать их можно не в первых строках, а где угодно.Flasher писал(а):Любая прагма работает с места, а не по всему коду
Резюме: это на самом деле трудоемко. Потому что прагмы читаются на этапе препроцессинга. И если с Include проблем нет (всё что нужно реализуется на этапе препроцессинга), то даже под FinalizeSection пришлось городить специальную обработку (если бы не совместимость, сейчас я бы лучше сделал специальную функцию "OnExit"). В парсер выражений сейчас передается единственный глобальный флаг. А чтобы реализовать включение/выключение по месту, придется сначала как-то сохранить с препроцессинга и проставить флаги в каждый узел дерева скрипта, учитывая вложенности, потом их проверять при выполнении.
Не то чтобы это было невозможно, но есть вопрос целесообразности. Были бы скрипты длиной в тысячи строк, об этом еще можно было бы говорить. А так в среднестатистическом скрипте всё исправить - дело от силы десятка-другого минут. И это не говоря о том, что само наличие каких-то сегментов, в которых один и тот же код выполняется по-разному, явно всё только усложнит. И ладно бы каждый из этих режимов давал какой-то уникальный профит, а так один раз перешел и забыл.
Мы после выкладки беты даже до второй не дошли, а ты уже несколько насчитал.Loopback писал(а):И нафига бы это мне? Слишком много лишнего времени, что захотелось поразвлекаться перепиской на несколько страниц?
Нафига тебе понимать мою нужду? Хороший вопрос, но не ко мне он, не телепат я. )У тебя очень интересно в описании:Loopback писал(а):Вот это была большая ошибка так думать. До сих пор единственная прагма, работающая в конкретном месте - это была FinalizeSection.
И тут же следующей строкой:Директивы выполняются на этапе предварительной обработки скрипта, результат их обработки действует на протяжении всего времени выполнения скрипта.
Такие противоречия заставляют задуматься, что там да как на самом деле.Часть скрипта после этой директивы обрабатывается при завершении Total Commander.
Совместимость уже поломалась в синтаксисе, поэтому можно делать не глядя.Loopback писал(а):если бы не совместимость, сейчас я бы лучше сделал специальную функцию "OnExit"
По остальному ясно-понятно, вопросов больше не имею...
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Мда, двусмысленно вышло. Надо было полностью цитировать.Flasher писал(а): Нафига тебе понимать мою нужду? Хороший вопрос, но не ко мне он, не телепат я. )
Доработаю. Но как раз это и должно было наводить на мысль, что не всё однозначно.Flasher писал(а):Такие противоречия заставляют задуматься, что там да как на самом деле.
Прям таки и поломалось, не нужно преувеличивать масштабы проблемы. Когда переход с дельфи 7 был на новые версии, все ansi-зависимые типы данных были по умолчанию заменены на юникодные, вот это - поломалось. А тут только прагму включить и всё. Ну почти, командный синтаксис в условиях все равно нельзя было дальше тянуть.Flasher писал(а):Совместимость уже поломалась в синтаксисе, поэтому можно делать не глядя.
Функцию теперь нет смысла делать, раз уж секция осталась.
-
dueus_minor
- Сообщения: 4
- Зарегистрирован: Ср сен 16, 2020 11:36
Имя переменной
Здравствуйте!
Возник вопрос следующего характера:
В Wind'е есть переменная среды вида "ProgramFiles(x86)". Ясно, что она неоднозначна для разных битностей ОС и самого ТС, ну, т.е. она может быть (в Win_х64), а может и не быть (в Win_x32).
Вопрос - возможно ли реализовать в плагине создание переменной с именем, содержащим скобки "()"?
З.Ы.: я знаю, что такое можно реализовать через .cmd(.bat), знаю, что есть и другие переменные, вопрос именно реализации через плагин Autorun.
З.Ы.2.: да, добавлю, что речь идёт про переменную среды в рамках процесса ТС. Т.е. добавление в реестр (утилита setx.exe и иже с ней) пользователя не задуман.
Возник вопрос следующего характера:
В Wind'е есть переменная среды вида "ProgramFiles(x86)". Ясно, что она неоднозначна для разных битностей ОС и самого ТС, ну, т.е. она может быть (в Win_х64), а может и не быть (в Win_x32).
Вопрос - возможно ли реализовать в плагине создание переменной с именем, содержащим скобки "()"?
З.Ы.: я знаю, что такое можно реализовать через .cmd(.bat), знаю, что есть и другие переменные, вопрос именно реализации через плагин Autorun.
З.Ы.2.: да, добавлю, что речь идёт про переменную среды в рамках процесса ТС. Т.е. добавление в реестр (утилита setx.exe и иже с ней) пользователя не задуман.