А я не писал, что иначе. Точки не должно быть с любым объектом.Avada писал(а):Но вот почему папки тут должны обрабатываться иначе?
MultiRename. TC не умеет отличать каталоги от файлов?
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Flasher
Почему не должно? Смысл введения двух разных полей Гислер видел в своё время в основном в том, чтобы неосторожной правкой в единственном поле не убить расширения файлов. (Поэтому [A] — факультативный вариант, а не основной.) Первое поле не зависит от второго — и наоборот. И раз уж мы что-то вводим в поле для расширения, результатом должно быть новое или изменённое расширение, а не довесок к имени без точки. Если мы что-то добавляем туда при наличии расширения (или по крайней мере чего-то после последней точки), никаких дополнительных точек быть не должно. (Их, насколько вижу, и нет.) Но если пока что никакого расширения нет, как мы можем его получить иначе, чем с автоматическим созданием начальной точки? В чём тут баг?
Почему не должно? Смысл введения двух разных полей Гислер видел в своё время в основном в том, чтобы неосторожной правкой в единственном поле не убить расширения файлов. (Поэтому [A] — факультативный вариант, а не основной.) Первое поле не зависит от второго — и наоборот. И раз уж мы что-то вводим в поле для расширения, результатом должно быть новое или изменённое расширение, а не довесок к имени без точки. Если мы что-то добавляем туда при наличии расширения (или по крайней мере чего-то после последней точки), никаких дополнительных точек быть не должно. (Их, насколько вижу, и нет.) Но если пока что никакого расширения нет, как мы можем его получить иначе, чем с автоматическим созданием начальной точки? В чём тут баг?
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Avada
Не должно, потому что дописка идёт после выражения, а не в начале. Если выражение есть, и оно возвращает пустое значение, то никакой вставки точки быть не должно, т. к. подразумевается, что выбраны могут быть как объекты с расширением, так и без. [А], напомню, появилось только в TC 8, а проблема имела место быть, но добавлялось выражение не по обсуждаемой причине.
Не должно, потому что дописка идёт после выражения, а не в начале. Если выражение есть, и оно возвращает пустое значение, то никакой вставки точки быть не должно, т. к. подразумевается, что выбраны могут быть как объекты с расширением, так и без. [А], напомню, появилось только в TC 8, а проблема имела место быть, но добавлялось выражение не по обсуждаемой причине.
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Flasher
При изначальном отсутствиии расширения и вводе в пустом поле для расширения или перед [E], например, 333, должно автоматом создаваться это расширение с точкой, а при добавлении после [E] 333 этот ввод, как понимаю, должен продолжать имя? А с какой стати?
По нескольким объектам. Выбираем несколько файлов/папок, как с расширением, так и без. Вводим это самое [E]333. Объекты с расширением получают довесок к нему — 333 без всяких лишних точек. Объекты без расширения получают расширение 333 с точкой. Всё логично. В чём проблема?
(Причины появления [А] обсуждать не будем, мы сейчас про другое.)
При изначальном отсутствиии расширения и вводе в пустом поле для расширения или перед [E], например, 333, должно автоматом создаваться это расширение с точкой, а при добавлении после [E] 333 этот ввод, как понимаю, должен продолжать имя? А с какой стати?
По нескольким объектам. Выбираем несколько файлов/папок, как с расширением, так и без. Вводим это самое [E]333. Объекты с расширением получают довесок к нему — 333 без всяких лишних точек. Объекты без расширения получают расширение 333 с точкой. Всё логично. В чём проблема?
(Причины появления [А] обсуждать не будем, мы сейчас про другое.)
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Что же тут логичного? В этом и проблема. Нужно сделать конкретную дописку для всех объектов безотносительно наличия раширений, а он мне у части имён точки втельняшивает. Зачем, спрашивается?Avada писал(а):Объекты без расширения получают расширение 333 с точкой. Всё логично. В чём проблема?
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Flasher
В общем виде суть проблемы по-прежнему не понимаю. Дай конкретные примеры требуемой дописки и исходных имён нескольких объектов (где точки нужны и где нет), я проверю.
sa
Кстати, да, справке это вполне соответствует. Ожидается ли кем-то именно такое поведение — вопрос другой, но считать его багом пока не вижу оснований.
В общем виде суть проблемы по-прежнему не понимаю. Дай конкретные примеры требуемой дописки и исходных имён нескольких объектов (где точки нужны и где нет), я проверю.
sa
Кстати, да, справке это вполне соответствует. Ожидается ли кем-то именно такое поведение — вопрос другой, но считать его багом пока не вижу оснований.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
А дальше написано:sa писал(а):Может, он руководствуется справкой?
Т.е. разделение создано для имён с расширениями. А мы обсуждаем случай их отсутствия.Причина, по которой эти два поля разделены, состоит в том, чтобы предотвратить случайное удаление расширений файла
Avada
Так ты текущее поведение описал. Ты пишешь "А с какой стати?" А я отвечаю, с той, что точка возникает у части выбранных файлов без расширений после [E], а с расширением — нет, игнорируя принцип дописки к полному имени. Т.е. [N]?[E] — схема полного имени. В случае [N]?[E]_add мы должны увидеть Name.ext_add у имён с расширением и Name_add у имён без расширения. Т. е. для [E] должна учитываться ситуация отсутствия расширения. Я всегда это во всех скриптах учитываю, иначе имеем смещение логики.
А получается, нам надо тратить время на очищение второго поля, заменять в маске другим выражением, чтобы добиться, казалось бы, очевидного результата с простой допиской.
У обычного переименования, кстати, тоже есть косяк с маской.
Если мы задаём *.*_add, то всё логично, спереди в любом случае подставляется точка, т.к. она прописана. Но если мы пропишем *_add, то мало того, что _add нигде не пропишется, так ещё и расширения поудаляются.
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Flasher
Да, описывалось текущее поведение, а какое же ещё?
Разделение полей, будучи когда-то введено, с тех пор работает безотносительно к тому, есть по факту расширение или нет. Может быть, с точки зрения логики скриптов тут есть какая-то несообразность, но со стороны самого инструмента я её не вижу. Если у объекта нет расширения и значением поля для расширения что-то задаётся, то объект получает новое расширение с точкой, а не дописку к полному имени. Результат соответствует месту ввода. Для меня эта логика выглядит естественной. Для тебя, насколько понимаю, нет. Очевидно, надо либо убеждать Гислера, что он где-то неправ (хотя я не понимаю, где), либо учитывать нынешнее поведение как данность.
Да, описывалось текущее поведение, а какое же ещё?
Разделение полей, будучи когда-то введено, с тех пор работает безотносительно к тому, есть по факту расширение или нет. Может быть, с точки зрения логики скриптов тут есть какая-то несообразность, но со стороны самого инструмента я её не вижу. Если у объекта нет расширения и значением поля для расширения что-то задаётся, то объект получает новое расширение с точкой, а не дописку к полному имени. Результат соответствует месту ввода. Для меня эта логика выглядит естественной. Для тебя, насколько понимаю, нет. Очевидно, надо либо убеждать Гислера, что он где-то неправ (хотя я не понимаю, где), либо учитывать нынешнее поведение как данность.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Ни фига вы тут нагородили. Крутые слова всякие. А ведь простому юзеру лишь надо, чтоб, если он хочет получить "название"+"текст" в конце, или в начале, или в середине, то ему нафик не упирались все эти "точки". Все эти рассуждения про "справки" и "что так было задуманно"
Кому это надо?
ИМХО это есть баг, как тут и было подтверждено. И если кто с инглишем дружит - надо репортить САМОМУ.))))
Кому это надо?
ИМХО это есть баг, как тут и было подтверждено. И если кто с инглишем дружит - надо репортить САМОМУ.))))
Avada
Про текущее поведение ответ был на слова "суть проблемы по-прежнему не понимаю. Дай конкретные примеры ...".
Логика скриптов ничем от любой другой программы переименования не отличается. Она одна. Насчёт "что-то задаётся" в поле расширения я выше пояснял, что ключевой аспект здесь — наличие [E] спереди. Если это не так, то это уже другая история, и в ином случае данный довод окажется справедлив. А про убеждение я уже закинул удочку MVV, посмотрим, чем обернётся.
Про текущее поведение ответ был на слова "суть проблемы по-прежнему не понимаю. Дай конкретные примеры ...".
Логика скриптов ничем от любой другой программы переименования не отличается. Она одна. Насчёт "что-то задаётся" в поле расширения я выше пояснял, что ключевой аспект здесь — наличие [E] спереди. Если это не так, то это уже другая история, и в ином случае данный довод окажется справедлив. А про убеждение я уже закинул удочку MVV, посмотрим, чем обернётся.
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
-
CaptainFlint
- Сообщения: 6239
- Зарегистрирован: Вт дек 14, 2004 22:34
- Откуда: Москва
- Контактная информация:
JKT
Если простой юзер хочет получить "название+текст", то, как уже написали ранее, ему нужно пользоваться специально для этого добавленным шаблоном [A], а не полями, рассчитанными на работу отдельно с именем, отдельно с расширением. Если молотком плохо получается вкручивать шурупы, то это проблема не молотка, а его нецелевого применения.
Если простой юзер хочет получить "название+текст", то, как уже написали ранее, ему нужно пользоваться специально для этого добавленным шаблоном [A], а не полями, рассчитанными на работу отдельно с именем, отдельно с расширением. Если молотком плохо получается вкручивать шурупы, то это проблема не молотка, а его нецелевого применения.
Почему же, ё-моё, ты нигде не пишешь "ё"?
Я бы вот это назвал забиванием шурупов:
Как выше писал, с Shift+F6 дела ещё хуже.Flasher писал(а):А получается, нам надо тратить время на очищение второго поля, заменять в маске другим выражением, чтобы добиться, казалось бы, очевидного результата с простой допиской.
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.
Flasher
Shift+F6 — это пакетное переименование? Может быть, это кому-то и очень нужно и полезно, но я вот, например, этим диалогом практически не пользуюсь, ибо принципиальных преимуществ перед ИГП не вижу ни одного, а недостатков — массу. Это не означает, разумеется, что там не следует исправлять явные баги при их наличии и подтверждении. Но полагаю, что в любом случае обсуждение указанного диалога — не для текущей темы, где и без того фактически идёт несколько обсуждений параллельно.
Shift+F6 — это пакетное переименование? Может быть, это кому-то и очень нужно и полезно, но я вот, например, этим диалогом практически не пользуюсь, ибо принципиальных преимуществ перед ИГП не вижу ни одного, а недостатков — массу. Это не означает, разумеется, что там не следует исправлять явные баги при их наличии и подтверждении. Но полагаю, что в любом случае обсуждение указанного диалога — не для текущей темы, где и без того фактически идёт несколько обсуждений параллельно.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Avada
Преимущества были бы, если бы не косяки. Сам диалог маленький, глаза не разбегаются по куче компонентов. Зрительный фокус на маске. Подтверждение по Enter без необходимости закрывать диалог.
А насчёт темы связь косвенная — быстро решить задачу дописки, но и тут, как видишь, не судьба.
Преимущества были бы, если бы не косяки. Сам диалог маленький, глаза не разбегаются по куче компонентов. Зрительный фокус на маске. Подтверждение по Enter без необходимости закрывать диалог.
А насчёт темы связь косвенная — быстро решить задачу дописки, но и тут, как видишь, не судьба.
Автору сборки TC Image (Andrey_A) настоятельно рекомендуется не распространять на иных ресурсах любую предоставленную мной где-либо техническую информацию по автоматизации и оптимизации в работе с ТС и системой.