Ага, понял.
------------ Дoбавленo:

Dilma, я добавил менеджеров на SVN. Посмотри. Пока на них нет добавления элементов. Тут надо бы определиться, как это лучше сделать
Вот пример работы с ними.

при закрытии хиасма, на вкладке User вылетает ошибка Access violation at adress 004679F8 in module 'HiAsm.exe'. Read of address 00000218

На пятой странице. Так что -- Баян. Топики читать надо с начала

Вкладка User будет удалена в финальной версии

тогда хотя бы исправте при закрытии ошибку а то приходится через диспетчер задач завершать каждый раз))

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

Дополнений несколько:
- думаю все интерфейсы нужно разместить в отдельном юните с их полным описанием. Т.е. в комментариях указать значение каждого метода и их параметры.
- по поводу привязок итомов элементов к иконкам. Один из вариантов это перевести инициализацию элемента данными так же на менеджер. Тогда можно бы было скажем в качестве данных посылать элементу таблицу, в которой один столбик - это имена(или индексы) иконок из менеджера, другой - данные, отображаемые в элементе, а все остальные то, что выдается элементом при выборе соответствующего итема в нем. Например для ListBox будут такие св-ва, осуществляющие этот интерфейс:
эта модель применима для всех списковых и табличных элементов(а других у нас вроде и нет). Ну и кроме того она позволит в будущем легко писать DataSource для различных баз данных.

------------ Дoбавленo:

Такая модель скажем в будущем позволит написать DataSource, который выдает информацию о файловой системе и IconManager, который умеет выдавать иконки файлов. Тогда очень просто и легко можно на основе любого элемента сделать обозреватель файловой системы с именами файлов и их иконками. Только для этого нужно идентификацию иконок делать не по числу, а по строке. Или лучше в интерфейс добавить метод: GetIndexByName.
------------ Дoбавленo:

Запустил, посмотрел подробнее. Такие вопросы:
- почему без MODE_XXX не обойтись? В идеале сервер ничего о клиентах знать не должен. Т.е. хотелось бы интерфейс, который без явных заточек модно было применить к любому элементу
- без менеджера отрисовки элемент не выводит указанные для него иконки. Как тут поступать - пока не знаю, но вижу два варианта:
a) если уж одно без другого не работает, то иконки логичнее присоединять к менеджеру отрисовки, а не к самому элементу. В этом есть как минимум один минус - есть элементы, у которых можно задать иконки без реализации CustomDraw(TreeView к примеру). Т.е. может быть стоит присоединять менеджер туда, где он реально используется
b) если оставить как это сделано сейчас(и что все таки выглядит более логичным), то наверно надо дать элементу возможность самостоятельно рисовать иконки даже если нет DrawManager


В целом, если не обращать внимания на некоторые глюки отрисовки первой версии - выглядит все достаточно красиво и логично

Можно обойтись, но тогда надо отказаться от заливки фона и боковой полоски, иначе последняя будет отрисована не до конца вниз -- очень некрасиво

Этот отрисовщик сложно (если вообще возможно) портировать еще куда-то. Он использует специфику именно боксов.

Не получится только потому, что по-умолчанию не работает OnMeasureItem, и тогда высотой можно управлять только размером шрифта, что накладывает ограничение на применяемый шрифт, а это -- неприемлемо


Какие конкретно, очень интересно
Если мерцание -- но тут уж никуда не денешься

а в чем именно проблема?


ну хорошо, наверно действительно не стоит далать настолько общий интерфейс и ограничиться только двумя типами Draw менеджеров - для списков и таблиц. Но внутри них различия точно стоит обойти.


почему тут нельзя поставить условие:
?


да одно из них.
Поменял чего-то в схеме(Frame уьрал и еще что-то видимо) - мерцание пропало, но пункты, с которых была снята активность перестали обновляться... Повторить эффект еше раз не удалось, но отсюда можно сделать вывод, что убрать этот дефект все таки можно

Ну проблема в том, что пробегая пункты в отрисовки, низ желательно отрисовать только один раз после последнего пункта, а там скзывается различность в доступных параметрах -- в ListBox'e мне известен размер всего окна, а в ComboBox'e -- нет. Я уже пробовал бороться с этим в своих Ex компонентах, также как и с фликкером (уменьшить можно, но убрать полностью ???) -- нифига не получилось.


С прозрачность в ListBox'e, без отключения некоторых отрисовок, никак не получается, а значит приходилось передавать режим прозрачности, чтобы исключить ненужные отрисовки. Если общий режим отрисовки еще можно помучить, то вот прозрачность ???

посмотрел повнимательнее:
- получать размер итема вот так
не хорошо - невозможно будет вывести пункт с двумя и более строками(как в публикаторе скажем). Этот параметр как и в VCL должен определяться пользователем(там оно ItemHeight) называется
- передавать в менеджер Sender - тоже не хорошо. При таком интерфейсе невозможно будет использовать их применительно к невизуальным контролам. Выводимый текст надо передавать в качестве одного из параметров.
- если хочется снабдить DrawManager знанием о рисуемых слева от текста картинок(т.е. константой SHIFT_PICTURE), то IconManager должен всетаки вставляться не в элемент, а в него.

Нужно всетаки постараться проникнуться идеей менеджеров(да и встраиваемых объектов вообще) и понять, что они(менеджеры) абсолютно ничего не должны знать о том, кто и зачем их будет использовать. У интерфейса отрисовки должна быть только одна функция:
где
DC - контекст устройства вывода
Rect - координаты области вывода
row,col - номер строки и номер колонки выводимых данных
text - собственно данные
ItemState - состояние текущего пункта
Flags - прочие флаги.

ну не получается ни в какую обойтись существующим интерфейсом сделай флаги - FLG_LISTBOX, FLG_COMBOBOX, FLG_TRANSPARENT... еще какие-то... Хочется учесть отступ от левого края - ну добавь в интерфейс более общие прави, а не затачивайся под один конкретный случай:
DrawRect - область вывода всего пункта
DataRect - область вывода данных


В IconsManager тоже самое. Я правда не совсем понял смысловую значимость параметра Rect, который в метод отрисовки меняется по всем четырем направлениям....
------------ Дoбавленo:

Глюки с отрисовкой кстате появлялись при Transparent = True. Правда мигание зато пропадает в таком режиме...

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

В последнем релизе я унифицировал версию для боксов без флагов, передается только свойство прозрачности
Мне кажется, что мешать все менеджеры отрисовки в одну кучу, тоже не дело. Для боксов должен быть один, для ListView'a -- другой, и они должны учитывать специфику каждого контрола. А вот универсальный на все -- ну я не знаю, насколько он усложнится

nesco, а у вас Kol-ы не разные ?

А может и разные, кто ж его знает

Я знаю.
Разные.

в таком случае это уже не менеджер, а кусок элемента с названием TreeViewDrawer.