Конкретику, пожалуйста. Выкладываем скрипты или даём ссылки туда, где они присутствуют в полном виде.ask-rus писал(а):Скрипты промышляют.
Ultra TC Editors
Модераторы: Avada, CaptainFlint, Nik, d-view, Моторокер
Avada
Дело не в скриптах, а в том, что CE глючит, когда пытается прочесть совпадающие секции. Автор должен был предусмотреть разные варианта, в т.ч. и когда юзер ручками вводит что-то лишнее в конфиг. Вместо тормозов, как правильно было сказано, должно появляться сообщение об обнаружении совпадающ(ей,их) секци(и,й).
Дело не в скриптах, а в том, что CE глючит, когда пытается прочесть совпадающие секции. Автор должен был предусмотреть разные варианта, в т.ч. и когда юзер ручками вводит что-то лишнее в конфиг. Вместо тормозов, как правильно было сказано, должно появляться сообщение об обнаружении совпадающ(ей,их) секци(и,й).
Avada
Автору не должно быть вдомёк, почему тот или иной скрипт глючно срабатывает, да ещё и у всех по-разному. Тут достаточно наличия глюка как такового. Скриптов может быть море, и на сам редактор они никоим образом не влияют, а лишь на содержимое текстовых файлов, в частности wincmd.ini. А конкретный пример прост - ввод аналогичной секции (можно без содержимого) в файле конфигурации.
Автору не должно быть вдомёк, почему тот или иной скрипт глючно срабатывает, да ещё и у всех по-разному. Тут достаточно наличия глюка как такового. Скриптов может быть море, и на сам редактор они никоим образом не влияют, а лишь на содержимое текстовых файлов, в частности wincmd.ini. А конкретный пример прост - ввод аналогичной секции (можно без содержимого) в файле конфигурации.
Flasher
Нет уж, извини. Если дублирование секций есть результат некорректного редактирования INI-файла вручную, автор вполне может счесть себя вправе это проигнорировать, а вот если это результат работы скриптов, а не разгильдяйства юзера, цена вопроса иная...
Так будут примеры?
Нет уж, извини. Если дублирование секций есть результат некорректного редактирования INI-файла вручную, автор вполне может счесть себя вправе это проигнорировать, а вот если это результат работы скриптов, а не разгильдяйства юзера, цена вопроса иная...
Так будут примеры?
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Avada
Пример обсуждается сейчас в Автоматизации. И автор может с тем же успехом сказать - пусть чинят скрипт, чтобы он так не делал. Почему для тебя неверно занесённые скриптом, утилитой, плагином данные неравнозначны с неверным заносом данных собственноручной правкой, мне непонятно. Например, сист. плагин "менеджер плагинов" какой-то мусор вносит, в другом случае это может оказаться утилита или ещё что-то. Автор не должен ждать того момента, когда кто-то вдруг нахимичит, а сразу должен на случай таких казусов принять меры. В ТС же появляются сообщения. А вообще, ИМХО, лучше бы он игнорировал последующие повторные секции, отдавая приоритет первой.
Пример обсуждается сейчас в Автоматизации. И автор может с тем же успехом сказать - пусть чинят скрипт, чтобы он так не делал. Почему для тебя неверно занесённые скриптом, утилитой, плагином данные неравнозначны с неверным заносом данных собственноручной правкой, мне непонятно. Например, сист. плагин "менеджер плагинов" какой-то мусор вносит, в другом случае это может оказаться утилита или ещё что-то. Автор не должен ждать того момента, когда кто-то вдруг нахимичит, а сразу должен на случай таких казусов принять меры. В ТС же появляются сообщения. А вообще, ИМХО, лучше бы он игнорировал последующие повторные секции, отдавая приоритет первой.
Потому что собственноручный неверный занос означает, что юзер не по делу полез руками править INI-файл и напортачил, вместо того, чтобы воспользоваться TCCE. Результаты стороннего вмешательства вопросов у автора по неиспользованию его программы не вызовут. Чисто психологический момент.Flasher писал(а):Почему для тебя неверно занесённые скриптом, утилитой, плагином данные неравнозначны с неверным заносом данных собственноручной правкой, мне непонятно.
Хотя скрипт чинить — идея неплохая...
А насчёт игнорирования повторных секций — в принципе согласен. По аналогии с повторными ключами.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Акцентировать на реальности твоего мнения было необязательно.Avada писал(а):К тому, что если скрипт так отрабатывается, это не радует. Это мнение уже не автора (гипотетическое), а моё собственное (вполне реальное).
Я не знаю причины, из-за чего происходит дозапись лишней строки в конец файла при использовании метода OpenTextFile при значении 2 в качестве <Iomode>. Может, Batya или Volniy смогут прояснить детально этот момент.
А ты не подумал о том, что он это мог это делать в удобном инструмента сравнения, которого в TCCE нет?Avada писал(а):Потому что собственноручный неверный занос означает, что юзер не по делу полез руками править INI-файл и напортачил, вместо того, чтобы воспользоваться TCCE.
Нет, не подумал. Потому что удобного инструмента сравнения, позволяющего вот просто так случайно размножать число секций INI-файла, я не знаю. А речь шла именно об этом.Flasher писал(а):А ты не подумал о том, что он это мог это делать в удобном инструмента сравнения, которого в TCCE нет?
И давай на этом закончим. Суть дела ясна, все предложения сделаны, автору напишу. Всё.
Даже самая богатая фантазия
Не представит себе наши безобразия.
Не представит себе наши безобразия.
Удобно не размножать, а править при сравнении с резервной копией. Так как секции по разным причинам могут в файле менять своё местоположении, юзер может случайно добавить секцию, которая располагается в другом месте, а предыдущую не удалить. Такие казусы вполне реальны и допустимы.Avada писал(а):Потому что удобного инструмента сравнения, позволяющего вот просто так случайно размножать число секций INI-файла, я не знаю.
Вот все подвижки. Запросов (в т.ч. гораздо более ранних) было полно, а имеем только то, что имеем...
Последний раз редактировалось Flasher Чт июл 07, 2011 23:39, всего редактировалось 1 раз.