Алгоритм создания TEdit.

[Alex Cones]

В общем, т.к. завершил создание кнопок по одной команде, их обработку и прочее, решил заняться следующей важной элементарной частицей IT мира - полем TEdit (для начала - одностроковым). Как-то смутно вырисовывается алгоритм его создания (имею в виду не часть вывода, а внутреннюю структуру). Это осложняется тем, что я хочу сделать TRichEdit - поддержку разных цветов и шрифтов, а далее и вставку изображений с гиперссылками.

Буду рад, если натолкнете на мысль.

Пока план, имеющийся в наличии такой:

1) Рисуется текстура "фона" :
- Либо стандартная:
- Либо любая пользовательская:
2) В строке типа String хранится вся информация о содержимом - текст + спецразметка для вставки дополнительных фич типа ссылок, другого шрифта и пр.
3) Начиная с первого символа парсится строка и на спецтекстуре (промежуточной, размером с текстуру из пункта 1.) рисуется текст (координаты первого символа зависят от текущего активного символа в поле и могут быть отрицательными) и фичи.
4) Промежуточная рисуется поверх фона.

В чем минусы подхода и что изменить?

[Stilet]

В строке типа String хранится вся информация о содержимом - текст + спецразметка для вставки дополнительных фич типа ссылок, другого шрифта и пр.

Рекомендую спецразметку по стандартам НТМL. т.е. принятые в интернете теги форматирования. Все равно ты хочешь это сделать, так почему не взять проверенный временем стандарт вместо выдумывания своего.
Насчет минусов... постарайся сделать парсинг такого один раз, а не каждый раз при отрисовке.

[Alex Cones]

Наверное потому, что это будет адский труд, портировать все спецификации HTML. Думаю, что после такого извращения dll разрастется килобайт на 300.
Или Вы имеете в виду портировать только нужные?

[BOBAH13]

Вы надеюсь понимаете что смешали две совсем разные части HTML/или какая то другая разметка и сам контрол Edit/TextBox/TextField ?

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

Логику разметки на текстуре, можно взять как уже сказали, от HTML. Но делать структуру хранения на основе String, само убийство, о скорости и подвижности (перемещения, удаления, редактирования) можно сразу забыть.

[Alex Cones]

Но делать структуру хранения на основе String, само убийство

С этим согласен, план был пятиминутный, непродуманный.

Создаете иерархию.

Т.к. классов у меня не предвидится, рекомендуете использовать динмассивы с индексами позиции?

[BOBAH13]

Сообщение от Alex Cones

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

ну тут легко заменить, к примеру

struct a { int a; int b; int c; ... }; struct aList { struct a data; structa *next; }

короче говоря, лучше не надо массивы использовать, используйте связные списки, каждый элемент содержит данные о элементе, и ссылки/адреса на предыдущий и следующий элемент. Соответственно, если предыдущий = null, то это первый элемент, если следующий = null, то это последний элемент. Так же глобально, или где у вас там в коде, хранить ссылку на первый элемент. Так у вас образуется низкоуровневый список.

[Alex Cones]

А сами элементы списка где хранить?

[Levsha100]

Стоп, как это без классов?
По моему ООП чуть ли не наиболее удачно подходит для таких штук.

[Alex Cones]

Стоп, как это без классов?

А вот так. Они сильно по размеру бьют.

Сравните фреймворк размером 26 кб или 300

[Levsha100]

Разве 200 кило при текущем уровне техники- много?