Где эти точки находятся - из sha понять можно
Skip - сверху
CurentPos,CurentStr - снизу

Тем, что всегда есть желание иметь набор базовых приметивов типа pos, copy, replace, insert, delete и т.д. - совершенно тупых и кондовых. А далее основываясь на них(непосредственно или с изменением кода) можно надстраивать ф-ции типа GetTok, PosEx и т.д. Менять на каждый чих интерфейс базовых ф-ций - не дело.

На чих - согласен, НЕ ДЕЛО

Но какой же это чих.
Если у нас как ни задача, так вместо Replace парсер приходится писать...
Больно уж для тупых задач он оказался предназначенным.
И прием введения back-а с параметром - достаточно типовой вроде.

Вот я пытался этот же мультик сделать на штатных элементах.
Мало не показалось.
И элемента Replace там не было.
Вот и задача вроде для него - а не умеет.

Шибко обидно было...

именно так. Любые расширения должны идти в ReplaceEx

Ну мне кажется, что "Любые расширения дающие интерфейсную несовместимость должны идти в ReplaceEx"

Говорю же - незаметит никто. Пока на вкладку <Точки> не забредет

Galkov, идем в Share.pas и видим:

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

Про элемент - так просто же допонительная точка, неиспользование которой ничего для пользователя не меняет...

вот именно. При нынешней технологии генерации кода в стандартном пакете говорить о быстродействие отдельных функций смысла вообще никакого нет. Я же всетаки надюсь, что нормальный кодогенератор будет сделан и лучше избежать лишних накладок с переносом.

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