Total Commander

dueus_minor
Да, сейчас плагин ограничивает создание переменных с именами, содержащими скобки и другие спецсимволы. Скорее всего, это сделано потому, что чтение внутренних переменных и переменных окружения производится единообразно (сейчас понятно, что это было не лучшее решение). Хотя имена переменных окружения разрешены любые, единственный запрещённый символ "=".

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

Loopback
Спасибо, что откликнулись на мою "затею". Что ж, буду ожидать очередного релиза.

Возможно, конечно, это описка, логичнее функцию назвать GetEnv, по аналогии с SetEnv.

Всплыло потому, что решил обновить и перелопатить базу плагинов, которые были где х32, где х32-64, до актуального состояния х32-64, для более универсальной переносимости (к сожалению, многие не обновляются с две тысячи лохматого года, многие из х32 морально устарели, некоторых не х32-64 будет не хватать, и придётся "перенастраивать пальцы" под новое нажатие кнопок ). А на моё ИМХО, ярлык должен быть один .
Раньше был ярлык на .cmd'шник, что, ИМХО, уже не комильфо, т.к. наткнулся на сей замечательный плагин, почему то не попавший в мою обойму ранее. Ну, и пошло, поехало... В .cmd'шнике я создавал или дополнял в зависимости от битности ОС две переменные окружения по аналогии с переменными среды, которые уже были для ТС однозначными и не имели вариаций в зависимости от битности ОС или самого ТС: ProgramFiles(x86) и ProgramFiles(x64). Далее, ссылался на них в ini'шках. А тут незадача... Соответственно и вариантов немного: остаться на .cmd'шке и/или дождаться реализации в плагине.

З.Ы.:На данный момент пользуюсь версией 2.2.3b.

Возможно, нашёлся баг в команде StrPart.
По крайней мере, мне не удалось получить описанный в Справке результат, согласно которой, цитата: "Если не было найдено ни одного разделителя, команда возвращает строку целиком и устанавливает %ERROR% в 1."

Строка конфига:
MsgBox %"StrPart('%COMMANDER_INI%', '/', 1)" "%ERROR%"

Ожидаемый результат:
сообщение с содержанием полного пути ini-фала, в заголовке сообщения "1"

Полученный результат:
сообщение с содержанием полного пути ini-фала, в заголовке сообщения "0"

Испытания проводились в Win'10 х64, ТС'9,51 х32.

З.Ы.: А всего-то перепутал знаки "\" "/"...

dueus_minor писал(а):Спасибо, что откликнулись на мою "затею". Что ж, буду ожидать очередного релиза.

Возможно, конечно, это описка, логичнее функцию назвать GetEnv, по аналогии с SetEnv.

Да я не назвал бы затеей, в общем-то это недоработка исходной функции. Раз такие имена переменных окружения разрешены и (тем более) используются системой, значит поддержка должна быть.

dueus_minor писал(а):логичнее функцию назвать GetEnv, по аналогии с SetEnv.

Разумеется, просто по привычке пишу имена аналогов из Autoit

Завтра выложу версию с поддержкой.

dueus_minor писал(а):Возможно, нашёлся баг в команде StrPart.

Подтверждаю, в описанном случае ERROR не выставлялась.

Версия 2.2.4 beta

- StrPart не устанавливала значение ERROR в определенных ситуациях
+ GetEnv для получения значения переменных окружения с именами, содержащими спецсимволы
* SetEnv теперь может устанавливать переменные окружения с любым разрешенным именем

Тут на оффоруме вопрос про AutorunLoadInSubrocess возник, она не решает свою задачу в режиме /S=L. Я предположил, что плагин не запускается в этом режиме, Гислер подтвердил догадку.
Но если контентные плагины не загружаются в подпроцессах в принципе, то директива в этом же самом принципе бесполезна? Либо нужно уточнить, что для её работы нужен какой-то экзотический способ загрузки плагина, не через механизм окраски файлов.
Я видел в теме мысль о том, чтобы её вообще убрать, но там не учитывался этот весьма толстый момент.

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

Кстати, пробежал поиском по теме, похоже началось всё отсюда, продолжилось здесь. Получается тогда вызов листера в отдельном процессе как-то загружал Autorun и прагма была оправданна, сейчас что-то изменилось?

Забавно, но быстрый тест показывает, что тотал загружает плагин и в режиме листера, и в режиме поиска в отдельном процессе. Я добавил ShellExec для отображения сообщения и оно отображается при вызове TOTALCMD /S=L и по Alt+Shift+F7.

Подскажите пожалуйста.
Возможно ли с помощью ModifyDialogs изменить размеры вот этих диалогов:

Показать

Желательно рабочий пример т.к. у самого не хватает знаний.

BeTeP

Да, можно, но в этих диалогах не удастся изменить размер и положение кнопок +F7, +F8, т.к это графческий элемент, а не контрол.

А так в принципе главное настроить условия, чтобы различать их, поскольку класс TInpComboDlg используется для многих других диалогов. Простейший способ по тексту заголовка, т.к. он различается и у этих диалогов, и отличается от других, используем AddCondition:
Теперь ширина первого диалога будет увеличиваться на 100, второго на 200. Высота обоих увеличится на 50.

Размер изменился, но контролы остались на том же месте, т.е. надо их тоже исправить. Проще всего взять Au3Info, и для необходимых контролов создать правила изменения их положения/размера. К примеру, в диалоге загрузки расширим первый комбобокс до новой ширины диалога. Из запущенного Au3Info тащим перекрестье "Finder Tool" на верхний комбобокс, видим, что в группе "Basic Control Info" появились данные "Class" - TMyComboBox и "Instance" - 2. Используем эти данные:
/W:100 - увеличиваем ширину на 100 пикселей.
В конце всего вызываем ModifyDialogs.

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

Loopback
Большое спасибо за помощь.

Приветствую.
Решил воспользоваться плагином Tweaks и столкнулся с отсутствием реакции на действие Не срабатывает именно на команду 2920. Если заменить к примеру на 483, то все открывается без проблем.
Windows 10 x64, TC 10 x32 (в x64 не проверялось), Autorun 2.1.1

jentoso
На win7х64 ТС10х32 (autorun 2.1.1) проверил - работает с командой 2920 без проблем. Но, есть нюансы:
1. настраиваемая файловая панель должна быть активна
2. на панели должен быть активирован пользовательский набор колонок, а не стандартные (краткий, подробный, эскизы и т.п.)

Monarch-LFV
Действительно, при выполнении 2го нюанса, все работает. Надо было справку для начала посмотреть по cm_CustomColumnDlg.

Дорогой автор!
Скажите пожалуйста, а можно ли с помощью 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, зато устраняет передачу его настроек совместимости дочерним процессам. Пока тестирую этот вариант, если всё будет ок, сделаю отдельную тему на форуме, поделюсь опытом.