Total Commander

Ну а кто мешает создавать скрипт так: Подумаешь, не скрипт, все равно ведь ТК покажет сообщение об ошибке с содержимым комментария по F3.
Также ты можешь добавлять спереди символ <, чтобы значок был другой, а еще в конец коммента - <<путь_к_иконке_и_индекс - любой файл скрипта поддерживает это. Например: Или даже так: Тогда смотреть комментарий можно по ентеру.

В первом коде ты, по-моему, написал не то, что хотел, но я тебя все равно понял. Здорово. То, что доктор прописал. А вот с иконкой чегой-то не клеится. Может, завтра продолжу эксперименты, а то что-то глаза слипаются. Иконка и запуск по Энтеру - по-хорошему пижонство, F3 вполне достаточно. Спасибо.

Добавлено
Но свежую голову посмотрел.
Иконка прописывается. По Энтеру комментарий хорошо виден. Но:
1. Нажимать Энтер на каком-то скрипте (если я не уверен, что помню, что он делает) сцуко опасно. Ну как сотрет все содержимое ВП или вообще "формат це". В этом смысле F3 гораздо безопаснее.
2. Смущают и вводят в заблуждение кнопки Yes No Cancel.
3. По F3 много лишнего:

<ifok {Комментарий: Для отправки в министерство} {}<<shell32.dll,1

Пока разглядишь сам комментарий, проще на бумажке написать.

Резюме: спасибо, но мне больше по душе предыдущий вариант. Еще раз призываю рассмотреть мое предложение.

MVV писал(а):но ведь у тебя никогда не возникало мысли поставить пробел перед закрывающей кавычкой? Почему тут возникает?

Что-то у меня самомнение разыгралось в прошлом посте, теперь нашел, откуда взялся пробел

Readme.txt писал(а):Пример команды удаления в текущей папке ссылок на файлы размером менее 1 КБ, измененные более 14 дней назад:
<for %f . * { <ifcond { !script && (size < 1024 && date < datenow - 14*24*60) @ %f } { <del "%f" } }

Потестировал новую версию.
1. Все команды, кроме ifcond, нормально работают, если переменная цикла заключена в кавычки, независимо от числа пробелов после нее. Зачем нужно такое исключение?
2. Имена файлов лучше ставить в кавычки, а не в скобки. Почему - см. выше пример силы привычки.
3. Не совсем понятна троичная логика в командах ifcond, ifexist. Если это сделано для исключения ошибок - возможно стоит выводить окошко с предупреждением и предложением остановить выполнение.
4. Командой add пользоваться как-то даже страшно. Она не проверяет существование физического файла. Она может заменить папку файлом без запроса. Хотя обработка ошибок есть, но действия выполняются даже при наличии ошибок в скрипте.
Например, команда <add folder_name C:\folder\filename.ext без всяких предупреждений легко и непринужденно превращает папку folder_name в ссылку на файл. Содержимое папки, естественно, теряется. Команда put, кстати, в этом тоже небезгрешна. Хотя все это просто ссылки, но все равно придется потерять время на их восстановление.
Если интересно, можно поиграться с командами типа "<add name *", "<add name .", "<add name ," и т.д.
5. Может, все-таки стоит сделать собственные информационные поля? Тогда многое упростится, а заодно можно завести поле для комментария.

Сделал я удаление пробелов в конце условия ifcond. Теперь, если кому-то вздумается поставить пробел в конце расширения файла, хрен обработаешь:) хотя, способ есть - написать <ifcond "valid @ 123.456 \" - т.е. обратный слэш после пробелов - проверял, работает и на файлах.

Троичная - в смысле, Да, Нет и Отмена? Ну, эт на случай, если вдруг не надо выполнять ни одну из команд. Кстати, если в условии ifcond ошибка (или виртуальный файл не найден), тоже ничего не выполняется.

Да, знаю, что команда <add заменяет втихаря. При необходимости можно написать скрипт, который будет ее вызывать после проверки отсутствия файла: И вызывать \>add вместо команды >add. Ну а с put сложнее. Тут предполагается, что пользователь знает, что куда добавляет.

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

А комментарии я все равно не знаю, как хранить

Так же, как скрипты - в базе. Я и подталкиваю тебя к тому, что комментарий должен быть тем же скриптом, только имеющим одну функцию - по F3 выдавать текст без "оформления".

Да эт понятно, что в базе. Но мне, например, будет противно видеть рядом с файлом еще какой-то файл с таким же именем, но начинающийся с >, чисто ради комментария. Да и при выделении кучи файлов для копирования будет куча-мала.

И потом, если коммент будет храниться в отдельном файле, забодаешься этот файл искать в папке с кучей файлов.

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

Ты же мастак скрипты писать! Напиши скрипт, который будет где-нибудь держать INI со строками вида <virtual_path>=<description> и запускай его как внешнее приложение, передавая путь к виртуальному файлу - а он будет показывать сообщение с комментарием. Тут писать-то почти что нечего, вызывать GetPrivateProfileString, передать ей путь к INI, имя блока (любую заранее определенную константу) и полученный в параметре путь к виртуальному файлу - и она вернет значение параметра, имя которого совпадает с путем к файлу (при желании можешь символы равенства как-то маскировать). Т.о., твой скрипт, который либо применяет коммент, либо показывает, и внутренний, вызывающий его извне с путем к файлу. Можешь написать один скрипт, который будет показывать editable поле комментария - типа, и создать, и посмотреть, и изменить сразу в одном.

MVV писал(а):А комментарии я все равно не знаю, как хранить

А почему бы не сделать потоки как в NTFS?

Ты же мастак скрипты писать!

Спасибо, конечно, но скрипты PowerPro - это несколько другое...

вызывать GetPrivateProfileString

А вот это PowerPro точно не может...

А вообще-то я уже говорил, что, возможно, решусь написать некий пакет скриптов для управления Virtual Panel'ью: не только комментарии, но, главным образом - пути источника (физической) и приемника (виртуальной).

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

Мысль насчет потоков, конечно, чем-то хороша - можно хранить это все в обычных файлах состояния с такой же легкостью, как и обычные файлы, но... раз это потоки, отображать в панели их не нужно (да и не удастся - двоеточие точно не тот символ, который следует использовать в именах, хотя ТК показывает и файлы с двоеточиями в именах - но тогда автор TWinKey точно решит, что мы психи). Значит, все равно придется использовать командную строку для доступа к объектам - просто нажать F3, увы, не удастся. А раз удобнее не станет - то способ с потоками ничем не отличается от просто новой папки в корне виртуальной панели, папки в которой дублируют папки самой панели, но ссылки на файлы хранят описания, а не пути к файлам. Т.е., если папку назвать \$descr, то для файла %1 просто проверяешь, есть ли файл \$descr\%1 - и если есть, показываешь его содержимое. И потоки не нужны.

Вахмурка писал(а):А вот это PowerPro точно не может...

А кто-то, помнится, говорил, что PPro - супер-пупер система, что остальное на ее фоне УГ... А она даже такой простой вещи сделать не может... Значит, бери путь из шапки панели, аппенди имя файла под курсором - и получишь путь. А далее для этого пути показывай коммент.

А кто-то, помнится, говорил, что PPro - супер-пупер система, что остальное на ее фоне УГ

"Эт-то вы... на м-меня намекаете?" ((С) Е. Лукашин, "Ирония судьбы")
Если я такое и говорил, то пьян был почище того же Лукашина.
GetPrivateProfileString ведь используется для чтения из инишника, так? Это она может. Только ума не приложу, зачем...

Только ума не приложу, зачем...

Ну, вроде как простейшая база описаний - инишник, где названия параметров являются виртуальными путями, а значения - описаниями. И тебе не нужно огород городить, ты сразу получаешь от системы нужную строку.

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


Кстати, что с помощью cm_SrcCustomViewXX наборы колонок переключаются за милую душу! Т.е., просто биндишь хоткей на cm_SrcCustomView3, скажем, и у тебя настроенный на определенную задачу набор включается без проблем!

1. Сам PowerPro это делать умеет, открывая файлы и читая из них с помощью плагина file. Но есть и плагин ini, специально заточенный под работу именно с файлами структурынапример, bar-файлами Тотала.
Твоя идея ясна, возможно, я ее и реализую.

2. Повторюсь - лет пять назад я был настолько очарован PowerPro, что мог такое сморозить. Но очень сильно сомневаюсь. Все ж таки программа - не девушка, чтобы без памяти в нее влюбляться. Так что найдешь - кинь сцылу.

3. Это понятно. Я просто отдаю предпочтение кнопкам перед горячими клавишами (то есть я скорее "мышатник", чем "клавишник").

Дык я тоже иногда люблю мышу погонять - чем мне и не нравится новое меню висты и семерки - в нем запаришься искать, клацать и скроллить, а в старом можно было по памяти моментом запускать нужные программы, запоминая траекторию))


VirtualPanel 1.0.0.420 (изменения по сравнению с 1.0.0.416):
* лишние пробелы после имени файла в условии команды ifcond игнорируются
* исправлен экспорт в кодировке ANSI командой export (файл писался в Юникоде, но без маркера)

Если у кого хватит ума использовать имена или расширения, заканчивающиеся пробелом - выше был дан совет, как такие имена пихать в ifcond.

Жду новых багрепортов.