Romul81
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору AZJIO Опробовал вашу софтину. На самом деле, я обычно применяю более быстрые и продвинутые инструменты для изменения текстовых данных. Напр. TextPipe, PowerGREP, или самописные скрипты под Node.js. Конечно, целевая аудитория для вашей программы несколько другая. Это что-то типа однокнопочного инструмента для непритязательных юзеров, которым по-быстрому надо что-то найти и заменить. В этой связи, если позволите, хотел бы выразить пару пожеланий / рекомендаций. Для начала те моменты, которые можно считать багами. 1. Здесь уже говорилось о ситуации с созданием TextReplace.ini в папке *\AppData\Roaming\TextReplace. Вы ответили, что это происходит тогда, когда программа не имеет прав записи в папку, из которой запускается. По факту это не так. При первом запуске (из папки, где эта запись, очевидно, возможна), создаётся два файла ini - в самой папке и в AppData. Пробовал оба экзешника и запускал в т.ч. с повышенными привилегиями - результат всегда один. 2. Вытекает из первого. После первого запуска, если произвести настройки, они нигде не сохраняются. Вообще. При втором запуске - всё по дефолту, включая язык и положение окна. Если же, в течение этого второго запуска опять произвести настройку, то они сохраняются в ini, который находится в папке программы. При последующих запусках эти настройки уже подхватываются. А *\AppData\Roaming\TextReplace\TextReplace.ini продолжает жить своей одинокой жизнью. 3. Не большая проблема, но дефолтная минимальная ширина окна недостаточна для того, чтоб отобразить все элементы интерфейса безбажно. В частности поле Add/Добавить подъезжает под кнопку "выводить найдено/ не найдено". Хинт для Add/Добавить как бы перекрывает часть этой кнопки. Это "перекрытие" пропадает если провести поверх указателем мыши. В русском варианте, как бы там ни было, слово Добавить всё равно не помещается в отведённом для него поле, без "подъезда" под упомянутую кнопку. У меня, кстати, дисплей/шрифты не скейлятся. Поэтому это влиять не может. 4. Кнопка "перезапуск" на самом деле убивает программу, но не перезапускает её. 5. Иногда (не всегда) при возвращении из модального суб-окна (настройки, опции, и т.д.), фокус не возвращается в основное окно программы. Более того, оно (окно) уходит на задний план (к примеру, за окно другой запущенной программы). Далее, по неочевидным моментам. 1. Было бы логично, если бы при активированном режиме "регулярные выражения", кнопка "поиск/замена многострочного текста" была бы деактивирована. Потому что регулярные выражения сами по себе имеют функционал для для того, чтоб хандлить такой текст. Но это, конечно, всё относительно. Я не тестил этот режим и не в курсе, как он отрабатывает те или иные специфические ситуации. 2. В окно настроек просится кнопка "отмена". Хотя, с точки зрения функционала она не нужна, чисто психологически, комфортнее нажать "отмена", чем "ОК", если зашёл, чтобы просто посмотреть. Но эта кнопка несёт за собой неочевидные моменты. Например, если какие-то настройки были изменены. Программа в этом случае сразу же применяет новые настройки. В этом случае, кнопка "отмена" должна приводить настройки в первоначальное состояние (на момент открытия окна настроек). 3. Момент с кодировкой. Сценарий. Кодовая страница в системе 1252. Настройка для кодировки - Auto. Обрабатывается ANSI-файл. Поиск - \d{4} замена - ГГГГ . Т.е. в замене русские буквы. На данный момент результат в обрабатываемом файле - ????. Это нормально, т.к. соотв. кодовая страница не поддерживает русские юникод-символы. Но, может быть, для этого сценария, когда обрабатываемый файл идентифицируется как ANSI, строку замен тоже интерпретировать, как ANSI? Таким образом, обрабатываемый файл бы не портился - ГГГГ преобразовалось бы в ÃÃÃÃ. И если такой ANSI-файл открыть потом в редакторе и интерпретировать как 1251, то мы бы получили искомое ГГГГ. Проблема не надуманная. Например, в HTML-файлах кодировка может задаваться тегами. И при отличии этой кодировки от системной, замены в текущем варианте будут портить файл (для не-ASCII - символов). Если же будет производиться конвертация строки замены в системную кодировку, в рузельтирующем файле окажется корректный результат (если в нём задана ANSI-кодировка). Из дополнительных пожеланий. 1. Есть такой проект - Regex toolkit. Я не пробовал, но по скриншоту видно, что там есть некоторые интересные штуки. Например, справка по регэкспам. У Вас, помнится, тоже были наработки на эту тему. Было бы неплохо прикрутить что-то этакое 2. Совсем уж экзотическое пожелание. Не из-за того, что не нужно (скорее, наоборот, нужно всем), а из-за сложности реализации. Прикрутить подсветку для регулярных выражений, которая бы задействовалась при активировании соотв. режима. Я понимаю, что эта фича есть даже далеко не в каждом серьёзном редакторе. Она всегда была в продуктах JGSoft. В Sublime Text появилась лишь недавно. В Notepad++ до сих пор нет. Поэтому, шансов на то, что вам удастся её прикрутить, немного. Тем более, для AutoIt такой UDF сходу найти не удалось. Но можно попробовать обойти. Есть такой проект под JS - Regex Colorizer. Его код написан давно, поэтому, он вполне может быть совместим с виндовым JScript (ES3). Там, правда, ещё есть стили, которые тоже нужно как-то хандлить, но, думаю, решаемо. Как бы там ни было, получить HTML вполне реально, используя этот код и, к примеру, ChakraCore UDF. Следующая задача - отобразить этот HTML в поле (понятное дело нужен будет GuiRichEdit). Готового решения тоже не удалось найти, но есть такая тема. В общем, эта идея на поразмыслить З.Ы. Ну и, пользуясь случаем, хотел бы Вам выразить огромную благодарность за Ваш вклад в дело становления AutoIt! Русское сообщество училось в т.ч. и на ваших примерах и статьях, пользовалось вашими сборками Notepad++. Огромное количество юзеров пользуются вашими скомпилированными скриптами, даже не догадываясь о их происхождении )) В общем, вы оставили, действительно, большое наследие! Спасибо! |