Задача:
Cbuilder6 Найти и заменить в тексте файла указанную подстроку на подстроку


1. На форме есть стандартный RichEdit::RichFile.
2. Глобальные переменные подстроки  поиска и замены - AnsiString FindStr, ReplaceStr;
3. Читаю файл (или его кусок - исходя из размера) в RichFile->Lines->LoadFrom File
4. в функции локальная переменная int pos;
5. заменяю:

вот тут и не работает - до замены дело не доходит, в цикл не входит ни разу, несмотря на то, что совпадение есть точно! Т.е не работает .Pos

В описании Pos параметр должен быть const AnsiString, но я прямо указать его не могу, т.к. подстроки поиска и замены переменные, вводятся юзером. 
Если и заменить Pos - то чем?

С уважением,
Herzog 


Модератор: не забываем пользоваться кнопочкой "Код"

Это сообщение отредактировал(а) bsa - 10.11.2009, 12:24

pos = RichFile->Text.Pos(FindStr) - это присвоить pos, значение RichFile->Text.Pos(FindStr). Ты уверен, что тебе именно это нужно? Может тебе нужен оператор сравнения (==)?

Да, уверен.

У меня длинный текстовый файл, в котором нужно найти множество подстрок, аналогичных введенной юзером и запомненной в FindStr и заменить на им же введенную ReplaceStr. 
Для этого мне нужно находить положение очередного совпадения по индексу. 

Собственно можно было бы провернуть все это в текстовом редакторе, но часть замен может быть - на неотображаемые символы (LineFeed, CarrigeReturn, Tab...)

С уважением,
Herzog  


Это сообщение отредактировал(а) Herzog - 10.11.2009, 13:26

Herzog, а если переделать алгоритм? Я бы проходил по строкам RichEdit'а и в каждой из них искал бы нужную подстроку. По-моему, так будет более логично.  

В цикл входить должно, а вот замена работать не будет. RichFile->Text - это проперть, и что бы ее заменить в нее надо записать. Ты же меняешь часть КОПИИ строки, а не саму строку

У меня строк в RichEdit'е как таковых нет.
Файл представлет собой протокол обмена компи с внешней микроконтроллерной схемой. Просто груда печатных символов - результат протоколирования работы микроконтроллера за долгий промежуток времени.
Для компи этот объем слитный, т.к. приходится экономить на скорости передачи лишних символов, а вот для поиска ошибок отладки мне нужно представить его в читаемом виде - вставить перевод строки, выделить повторяющиеся куски... и т.д.

Програмка в которой у меня сейчас затык - вспомогательная для отладки и не очень хочется тратить время на написание процедуры сравнения и замены поиндексно двух AnsiString - тем более, что есть стандартная функция.
Только не работает почему-то.

C уважением,
Herzog

Добавлено через 7 минут и 25 секунд

RichEdit глобален для функции сравнения. 
Проверил - могу без проблем менять его в рамках функции, где провожу замену.

Но дело не в этом - не захожу в цикл, т.к. значение pos = 0 Т.е. не находится очевидное, гарантированное вхождение подстроки.
Пред самим циклом я ставлю печать как и RichFile->Text, так и FindStr. Они есть и вхождение тоже должно быть.

С уважением,
Herzog 

 

непосредственно кто опрашивает данную систему - твой софт или сторонний. Если твой - то гораздо удобнее сразу записывать информацию в файл, ибо к тебе приходит по любому стандартный пакет из байт. Не составляет труда из этого буфера выудить необходимую информацию и поместить ее в хранилище данных. А парсить то куда все валом падает не есть айс.

Не важно это...

Да, мой софт и на микроконтроллере и в связной программе приема рзультата протоколирования.
Я принимаю данные, разбираю их, сортирую  и сбрасываю обработанный результат на диск. 

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

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

С уважением,
Herzog 

А придется - нету у стандартного AnsiString'а таких глюков. Pos все замечательно ищет. Так что ищи ошибку у себя. Например в FindStr что то не то. В частности - нет ли там каких непечатаемых символов? Вообще использовать RichText для промежуточного хранения данных не самая лучшая идея - он внутри себя все хранит в RTF формате, и при чтении и записи проперти Text делает перевод в/из RTF. Так что результат чтения из Text может не совпасть с тем, что в нее писали.
Да ради бога, меняй. Но результата от RichFile->Text.Delete( pos, FindStr.Length() ); не будет, RichFile->Text останется неизменным

Меня сейчас не волнуют его личные форматы хранения - перед while( .pos) я ставил ShowMessage( RichFile->Text ) и убеждался что он преобразовался до стринга в нормальном и предсказуемом для меня виде. И FindStr тоже печатал для контроля - все ОК.

Почему вот не работает Pos? Видимо только с constat стрингами. Хотя это уже чисто спортивный вопрос, т.к. буксовать на ровном месте мне уже поднадоело и времени нет разбираться - я, видимо, напишу свою процедуру сравнения.

А что до RichEdit - попробовал. Он изменяется, но пусть Вас это не беспокоит - считаете его вне зоны видимости, можете продолжать считать так и дальше.

С уважением,
Herzog 

Это сообщение отредактировал(а) Herzog - 10.11.2009, 14:41

А зря - он вполне может изуродовать вашу строку как бог черепаху   
Еще мне не понятно - почему именно RichEdit? Чем не угодил обычный TMemo - он точно строки не обрабатывает внутри себя


Вы пытались отладчиком пройти по циклу while? Вы пытались отладчиком посмотреть содержимое RichFile->Text и FindStr? Печатать их для контроля через ShowMessage совершенно недостаточно - ShowMessage может вам не показать непечатаемые символы, которые есть в одной строке но нету в другой.

Он работает с ЛЮБЫМИ стрингами.

Валяйте пишите. Видимо это новый стиль написания программ - не умею пользоваться чем то - напишу свое.

А, т.е. в while вы все таки зашли? Или это ваши домыслы? Можно пример кода?
Вы вообще читали, что я вам писал? Причем здесь 'зона видимости'? Я писал, что вызов RichFile->Text.Delete не изменит RichFile->Text. Не верите - к терапевту.

Как уже было сказано, функции Delete() и Insert() не модифицируют строку, а возвращают значение (так написано в справке, но в книжке Архангельского с точностью до наоборот) поэтому:

Спасибо, Вы написали ответ, когда я уже и сам - по Вашей подсказке - нашел ошибку.

Нет, я не использовал отладчик. Просто вывел на печать посимвольно в hex формате каждый байт RichFile->Text:
 
и увидел rtf-овскую фигню. Каждый байт моих данных отображался в виде двухбайтного числа расширенной кодировки, не считая служебного блока кодов установки стилей и шрифтов в начале файла (точнее - моей пседвостринговской строки). 
Разумеется, сравнивая их с "чистым" стрингом, я не находил совпадений.
Showmessage() ничего не показал, т.к. преобразовывал rtf обратно в стринговский вид.

Что касается проверки доступности Rich'а - в цикл еще не попал (а сейчас и подавно не буду, поскольку придется поменять кое-что), а перед циклом загонял туда другое значение и все работало.

Самое главное не в том, что я разобрался в отладочной программе - похожие, только более серьезные ошибки с Rich'ами подждали меня в моей сервисной программе связи.


Спасибо, xvr, за пинок в нужном направлении.
Спасибо всем, кто был внимателенен ко мне и хотел помочь.

P.S. К Rich'ам я привык, давно, еще когда писал программу для жены - тесты по французскому языку. Там везде диакритические значки (крышечки и хвостики над и под буквами), не передаваемые в других окнах, кроме Rich'а. 
Привык....

До свидания,
Herzog  

Это сообщение отредактировал(а) Herzog - 10.11.2009, 15:51

С этим разберусь - дойдет ход.
Сейчас хотелось бы чисто шкурный вопрос - не подскажите, где достать электронную версию Архангельского, но не ввиде картинки сканированного текста (таких у меня два варианта уже есть). Чтобы можно было ввести поиск по словам.
Иначе пользоваться крайне неудобно.

С уважением,
Herzog 

Это сообщение отредактировал(а) Herzog - 10.11.2009, 16:22

Небольшой совет - форматирование строк лога с устройства лучше делать прямо на лету, ДО помещения их в RichEdit (или любой другой Edit)

Добавлено через 3 минуты и 40 секунд
Кстати, еще один совет: вот это
лучше делать так
т.к. чтение и запись RichFile->Text это ОЧЕНЬ медленная операция, особенно при больших объемах текста в RichEdit