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

Выкладываю второй релиз -- multiblockfind_002.rar
Существенно увеличена скорость обработки, по причине перевода инициализации цепей поиска в секцию инициализации свойств. Добавлены комментари, операнды укорочены, длинные операнды больше не поддерживаются, добавлн выбор направления перебора цепей.
Пример внутри. Проверьте его на скорость, но только не на сто текстовых блоков, как это сделал CriDos, а максимум на двадцать. Я дольше ждал создани этого текста, чем она его парсила


Ситуация с разным количеством данных, выдаваемой одной цепью, так что в дальнейшем невозможно определить, сколько элементов какой цепи принадлежит, тк поток общий. Возможно, лучше использоват не один общий поток, а каждый вывод найденого блока, снабдивв ее индексом цепи. Это улучшить обнаружение принадлежности найденного блока, но усложнит схему. Я считаю этот вариант предпочтительней, тк он более универсальный. Но компонент пока остался на последнем алгоритме

Осталось только добавить автоматику ( в поддержку Мартынова )
thtml.rar

Сами пусть добавляют

Ты что????
Ну хотябы,
поставил на схему компонент,
выделил его мышкой,
пошептал в микрофон что нужно и...
страничку распарсило.
Так должен работать компонент для пользователя HiAsm.
А ты создал второе IC и радуешься.

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

nesco, парсинг страницы HTML - всегда узкая задача. Конечно лучше наговорить задачу в микрофон

Я ж не про задачу, а про результат
------------ Дoбавленo в 17.53:
Вот, третий релиз. Как раз с тем, о чем я говорил -- multiblockfind_003.rar

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

А свойства как, через верх задавать

А точно не будешь, или ты никогда не используешь цепочный поиск блоков

А глядя на отозвавшихся, то компонент может быть востребован и, как следствие, попасть в пакет
------------ Дoбавленo в 18.07:
У меня крутится мысль сделать его еще и древовидным (сейчас он не поддерживает ветвление, только цепь), и вот тогда все поиски блоков можно будет выкинуть из схемы, а их там может быть большая прорва

Отозвавшиеся CriDos, Roma, Login, Мартынов .
Пока смотреть нечего. Хотя, можно устроить Опрос.
------------ Дoбавленo в 18.13:

Tad, я - тоже потенциальная публика, если буду пользоваться конструктором, а сколько новичков клянчат парсеры... Десятки.
Да и Вам как, при случае IC и "паровозиками" легче парсить?

Tad, ну опрос то создавать незачем сразу видно компонент востребован будет.
nesco, с индексами компонент выглядит более управляемый ! и это здорово только вот если бы вставить эту функцию отдельным событием другими словами обьеденить компоненты

Это по чему же видно, что компонент будет востребован ?

Мартынов, не знаешь, по какому критерию определяется "будет востребован" или "не будет" ?------------ Дoбавленo в 18.55:
паровозиками.