dueus_minor
Да, сейчас плагин ограничивает создание переменных с именами, содержащими скобки и другие спецсимволы. Скорее всего, это сделано потому, что чтение внутренних переменных и переменных окружения производится единообразно (сейчас понятно, что это было не лучшее решение). Хотя имена переменных окружения разрешены любые, единственный запрещённый символ "=".
Интересно, что за все время существования плагина это ограничение всплыло только сейчас. Больших сложностей разрешить произвольные имена для создания переменных окружения вроде бы нет, но стандартный метод с использованием окаймляющих % для их чтения будет непригоден. Возможно, тогда придется ввести дополнительную функцию типа EnvGet для получения значения по имени строки.
Autorun
Модераторы: Моторокер, Avada, CaptainFlint, Nik, d-view
-
dueus_minor
- Сообщения: 4
- Зарегистрирован: Ср сен 16, 2020 11:36
Loopback
Спасибо, что откликнулись на мою "затею". Что ж, буду ожидать очередного релиза.
Возможно, конечно, это описка, логичнее функцию назвать GetEnv, по аналогии с SetEnv.
Всплыло потому, что решил обновить и перелопатить базу плагинов, которые были где х32, где х32-64, до актуального состояния х32-64, для более универсальной переносимости (к сожалению, многие не обновляются с две тысячи лохматого года, многие из х32 морально устарели, некоторых не х32-64 будет не хватать, и придётся "перенастраивать пальцы" под новое нажатие кнопок
). А на моё ИМХО, ярлык должен быть один .
Раньше был ярлык на .cmd'шник, что, ИМХО, уже не комильфо, т.к. наткнулся на сей замечательный плагин, почему то не попавший в мою обойму ранее. Ну, и пошло, поехало...
В .cmd'шнике я создавал или дополнял в зависимости от битности ОС две переменные окружения по аналогии с переменными среды, которые уже были для ТС однозначными и не имели вариаций в зависимости от битности ОС или самого ТС: ProgramFiles(x86) и ProgramFiles(x64). Далее, ссылался на них в ini'шках. А тут незадача... Соответственно и вариантов немного: остаться на .cmd'шке и/или дождаться реализации в плагине.
З.Ы.:На данный момент пользуюсь версией 2.2.3b.
Спасибо, что откликнулись на мою "затею". Что ж, буду ожидать очередного релиза.
Возможно, конечно, это описка, логичнее функцию назвать GetEnv, по аналогии с SetEnv.
Всплыло потому, что решил обновить и перелопатить базу плагинов, которые были где х32, где х32-64, до актуального состояния х32-64, для более универсальной переносимости (к сожалению, многие не обновляются с две тысячи лохматого года, многие из х32 морально устарели, некоторых не х32-64 будет не хватать, и придётся "перенастраивать пальцы" под новое нажатие кнопок
). А на моё ИМХО, ярлык должен быть один .Раньше был ярлык на .cmd'шник, что, ИМХО, уже не комильфо, т.к. наткнулся на сей замечательный плагин, почему то не попавший в мою обойму ранее. Ну, и пошло, поехало...
В .cmd'шнике я создавал или дополнял в зависимости от битности ОС две переменные окружения по аналогии с переменными среды, которые уже были для ТС однозначными и не имели вариаций в зависимости от битности ОС или самого ТС: ProgramFiles(x86) и ProgramFiles(x64). Далее, ссылался на них в ini'шках. А тут незадача... Соответственно и вариантов немного: остаться на .cmd'шке и/или дождаться реализации в плагине.З.Ы.:На данный момент пользуюсь версией 2.2.3b.
-
dueus_minor
- Сообщения: 4
- Зарегистрирован: Ср сен 16, 2020 11:36
StrPart
Возможно, нашёлся баг в команде StrPart.
По крайней мере, мне не удалось получить описанный в Справке результат, согласно которой, цитата: "Если не было найдено ни одного разделителя, команда возвращает строку целиком и устанавливает %ERROR% в 1."
Строка конфига:
MsgBox %"StrPart('%COMMANDER_INI%', '/', 1)" "%ERROR%"
Ожидаемый результат:
сообщение с содержанием полного пути ini-фала, в заголовке сообщения "1"
Полученный результат:
сообщение с содержанием полного пути ini-фала, в заголовке сообщения "0"
Испытания проводились в Win'10 х64, ТС'9,51 х32.
З.Ы.: А всего-то перепутал знаки "\" "/"...
По крайней мере, мне не удалось получить описанный в Справке результат, согласно которой, цитата: "Если не было найдено ни одного разделителя, команда возвращает строку целиком и устанавливает %ERROR% в 1."
Строка конфига:
MsgBox %"StrPart('%COMMANDER_INI%', '/', 1)" "%ERROR%"
Ожидаемый результат:
сообщение с содержанием полного пути ini-фала, в заголовке сообщения "1"
Полученный результат:
сообщение с содержанием полного пути ini-фала, в заголовке сообщения "0"
Испытания проводились в Win'10 х64, ТС'9,51 х32.
З.Ы.: А всего-то перепутал знаки "\" "/"...
Да я не назвал бы затеей, в общем-то это недоработка исходной функции. Раз такие имена переменных окружения разрешены и (тем более) используются системой, значит поддержка должна быть.dueus_minor писал(а):Спасибо, что откликнулись на мою "затею". Что ж, буду ожидать очередного релиза.
Возможно, конечно, это описка, логичнее функцию назвать GetEnv, по аналогии с SetEnv.
Разумеется, просто по привычке пишу имена аналогов из Autoitdueus_minor писал(а):логичнее функцию назвать GetEnv, по аналогии с SetEnv.
Завтра выложу версию с поддержкой.
Подтверждаю, в описанном случае ERROR не выставлялась.dueus_minor писал(а):Возможно, нашёлся баг в команде StrPart.
Версия 2.2.4 beta
- StrPart не устанавливала значение ERROR в определенных ситуациях
+ GetEnv для получения значения переменных окружения с именами, содержащими спецсимволы
* SetEnv теперь может устанавливать переменные окружения с любым разрешенным именем
- StrPart не устанавливала значение ERROR в определенных ситуациях
+ GetEnv для получения значения переменных окружения с именами, содержащими спецсимволы
* SetEnv теперь может устанавливать переменные окружения с любым разрешенным именем
Тут на оффоруме вопрос про AutorunLoadInSubrocess возник, она не решает свою задачу в режиме /S=L. Я предположил, что плагин не запускается в этом режиме, Гислер подтвердил догадку.
Но если контентные плагины не загружаются в подпроцессах в принципе, то директива в этом же самом принципе бесполезна? Либо нужно уточнить, что для её работы нужен какой-то экзотический способ загрузки плагина, не через механизм окраски файлов.
Я видел в теме мысль о том, чтобы её вообще убрать, но там не учитывался этот весьма толстый момент.
Но если контентные плагины не загружаются в подпроцессах в принципе, то директива в этом же самом принципе бесполезна? Либо нужно уточнить, что для её работы нужен какой-то экзотический способ загрузки плагина, не через механизм окраски файлов.
Я видел в теме мысль о том, чтобы её вообще убрать, но там не учитывался этот весьма толстый момент.
MVV
Да, интересное наблюдение. Если я правильно помню, делалось это для поиска файлов в отдельном процессе, но похоже явно не был учтен момент, что автоматически плагин загрузиться просто не сможет. Думаю, "экзотическим" способом плагин точно никто не захочет загружать, в этом просто нет смысла. Действительно, более чем весомый аргумент к удалению.
Кстати, пробежал поиском по теме, похоже началось всё отсюда, продолжилось здесь. Получается тогда вызов листера в отдельном процессе как-то загружал Autorun и прагма была оправданна, сейчас что-то изменилось?
Да, интересное наблюдение. Если я правильно помню, делалось это для поиска файлов в отдельном процессе, но похоже явно не был учтен момент, что автоматически плагин загрузиться просто не сможет. Думаю, "экзотическим" способом плагин точно никто не захочет загружать, в этом просто нет смысла. Действительно, более чем весомый аргумент к удалению.
Кстати, пробежал поиском по теме, похоже началось всё отсюда, продолжилось здесь. Получается тогда вызов листера в отдельном процессе как-то загружал Autorun и прагма была оправданна, сейчас что-то изменилось?
BeTeP
Да, можно, но в этих диалогах не удастся изменить размер и положение кнопок +F7, +F8, т.к это графческий элемент, а не контрол.
А так в принципе главное настроить условия, чтобы различать их, поскольку класс TInpComboDlg используется для многих других диалогов. Простейший способ по тексту заголовка, т.к. он различается и у этих диалогов, и отличается от других, используем AddCondition:
Теперь ширина первого диалога будет увеличиваться на 100, второго на 200. Высота обоих увеличится на 50.
Размер изменился, но контролы остались на том же месте, т.е. надо их тоже исправить. Проще всего взять Au3Info, и для необходимых контролов создать правила изменения их положения/размера. К примеру, в диалоге загрузки расширим первый комбобокс до новой ширины диалога. Из запущенного Au3Info тащим перекрестье "Finder Tool" на верхний комбобокс, видим, что в группе "Basic Control Info" появились данные "Class" - TMyComboBox и "Instance" - 2. Используем эти данные:
/W:100 - увеличиваем ширину на 100 пикселей.
В конце всего вызываем ModifyDialogs.
Итого, c учетом загрузки плагина получим:
Таким же образом можно найти и добавить остальные доступные контролы, но как уже говорилось, некоторые недоступны для изменения.
Да, можно, но в этих диалогах не удастся изменить размер и положение кнопок +F7, +F8, т.к это графческий элемент, а не контрол.
А так в принципе главное настроить условия, чтобы различать их, поскольку класс TInpComboDlg используется для многих других диалогов. Простейший способ по тексту заголовка, т.к. он различается и у этих диалогов, и отличается от других, используем AddCondition:
Код: Выделить всё
AddDialog /W:100 /H:50 "TInpComboDlg"
AddCondition /TEXT "" 0 "Загрузка"
AddDialog /W:200 /H:50 "TInpComboDlg"
AddCondition /TEXT "" 0 "Закачка"Размер изменился, но контролы остались на том же месте, т.е. надо их тоже исправить. Проще всего взять Au3Info, и для необходимых контролов создать правила изменения их положения/размера. К примеру, в диалоге загрузки расширим первый комбобокс до новой ширины диалога. Из запущенного Au3Info тащим перекрестье "Finder Tool" на верхний комбобокс, видим, что в группе "Basic Control Info" появились данные "Class" - TMyComboBox и "Instance" - 2. Используем эти данные:
Код: Выделить всё
AddControl /W:100 "TMyComboBox" 2В конце всего вызываем ModifyDialogs.
Итого, c учетом загрузки плагина получим:
Код: Выделить всё
LoadLibrary Plugins\Autorun_ModifyDialogs.dll
AddDialog /W:100 /H:50 "TInpComboDlg"
AddCondition /TEXT "" 0 "Загрузка"
AddControl /W:100 "TMyComboBox" 2
AddDialog /W:200 /H:50 "TInpComboDlg"
AddCondition /TEXT "" 0 "Закачка"
ModifyDialogs
Приветствую.
Решил воспользоваться плагином Tweaks и столкнулся с отсутствием реакции на действие
Не срабатывает именно на команду 2920. Если заменить к примеру на 483, то все открывается без проблем.
Windows 10 x64, TC 10 x32 (в x64 не проверялось), Autorun 2.1.1
Решил воспользоваться плагином Tweaks и столкнулся с отсутствием реакции на действие
Код: Выделить всё
# Alt+ПКМ по табуляторам активной панели = настроить текущий набор колонок:
ControlSetMouseAction /R:U /K:A 10001 SendCommand 2920Windows 10 x64, TC 10 x32 (в x64 не проверялось), Autorun 2.1.1
TC 11.58 combo, Windows 11 x64
-
Monarch-LFV
- Сообщения: 367
- Зарегистрирован: Пн июл 22, 2019 13:20
Дорогой автор!
Скажите пожалуйста, а можно ли с помощью SetEnv удалить существующую переменную окружения?
Стандартно в DOS/Windows, при присвоении переменной окружения пустого значения происходит её удаление.
Если использовать для изменения переменных wfx-плагин Environment Variables Ex 1.0, то поведение именно такое.
А вот если вызвать SetEnv с пустым значением, то переменная только опустошается, но не удаляется (это видно в том же Environment Variables Ex).
В принципе, это не критично, так как практический результат идентичен что с пустой переменной, что с удалённой. Но всё же интересно, можно ли добиться полностью стандартного поведения. Может быть, я какой-то переключатель у SetEnv не знаю или эскейп-последовательность?
P.S. Кстати, по ходу, для чего мне это вообще надо. При использовании TC на HiDPI-экране (4K на ноутбуке) для получения желаемой картинки пришлось настроить параметры совместимости. Но проблема в том, что эти параметры, как известно, наследуются любым процессом, запущенным из контекста TC (как при непосредственном запуске исполняемого файла, так и при открытии файла ассоциированным приложением). А другие приложения совсем не обязательно нормально выглядят с теми настройками совместимости, что хороши для TC. Настройки совместимости передаются через переменную окружения __COMPAT_LAYER. Удаление или очистка этой переменной "внутри" работающего TC не влияет на сам TC, зато устраняет передачу его настроек совместимости дочерним процессам. Пока тестирую этот вариант, если всё будет ок, сделаю отдельную тему на форуме, поделюсь опытом.
Скажите пожалуйста, а можно ли с помощью SetEnv удалить существующую переменную окружения?
Стандартно в DOS/Windows, при присвоении переменной окружения пустого значения происходит её удаление.
Если использовать для изменения переменных wfx-плагин Environment Variables Ex 1.0, то поведение именно такое.
А вот если вызвать SetEnv с пустым значением, то переменная только опустошается, но не удаляется (это видно в том же Environment Variables Ex).
В принципе, это не критично, так как практический результат идентичен что с пустой переменной, что с удалённой. Но всё же интересно, можно ли добиться полностью стандартного поведения. Может быть, я какой-то переключатель у SetEnv не знаю или эскейп-последовательность?
P.S. Кстати, по ходу, для чего мне это вообще надо. При использовании TC на HiDPI-экране (4K на ноутбуке) для получения желаемой картинки пришлось настроить параметры совместимости. Но проблема в том, что эти параметры, как известно, наследуются любым процессом, запущенным из контекста TC (как при непосредственном запуске исполняемого файла, так и при открытии файла ассоциированным приложением). А другие приложения совсем не обязательно нормально выглядят с теми настройками совместимости, что хороши для TC. Настройки совместимости передаются через переменную окружения __COMPAT_LAYER. Удаление или очистка этой переменной "внутри" работающего TC не влияет на сам TC, зато устраняет передачу его настроек совместимости дочерним процессам. Пока тестирую этот вариант, если всё будет ок, сделаю отдельную тему на форуме, поделюсь опытом.
Последний раз редактировалось Kirr Чт мар 10, 2022 23:45, всего редактировалось 2 раза.