А если сделать отдельное событие, типа onGetCellParams и верхние точки для параметров и цвета шрифта, цвета фона (или метод doSetCellParams, который в MT-потоке получит все эти параметры по событию)? Событие должно, вероятно, быть в компонентах MST_DrawManager и MST_SetColors. Можно добавить свойство - вызывать ли событие один раз для всей таблицы, для каждой строки, для каждой ячейки.

Редактировалось 1 раз(а), последний 2019-05-22 10:43:01

Что-то такое уже пытался сделать sla8a, вот только не знаю, доделал ли он это дело до конца? Тут сложность возникает в том, что для каждой ячейки надо держать отдельный список параметров, те создавать тип record и хранить его для каждой ячейки в отдельном списке типов, а потом еще обвязку надо делать для управления этим списком. Я уже пытался сделать что-то типа XGrid, даже имея готовый код под Delphi, такой гемор оказался, что я плюнул, правда давно это было.

Редактировалось 2 раз(а), последний 2019-05-22 13:14:42

Вероятно, да, но можно пойти другим путем: выдавать событие при каждой перерисовке, не сохраняя значений, а используя их только в данной перерисовке. Тогда обработчик события сам решает откуда он берет и где ему хранить эти значения.
Другими словами: если наша программа - это редактор типа Word, где пользователь сам раскрашивает каждую ячейку, тогда указанные им значения "надо где-то хранить". А если таблица раскрашивается в зависимости от содержимого ячейки, например, "пометить красным строку, в которой столбец "Долг" больше 0", тогда необходимые параметры уже "хранятся" в самой строке. Только надо обеспечить удобный доступ к "текущей" строке таблицы на момент её рисования.

Пытался, но не достиг нужного результата (не хватает опыта и знаний). Вот к чему-то подобно склоняюсь и я.
Приблизительно так:
1. Свойство true/false о необходимости пользовательский отрисовке.
2. Событие в которое выдаётся MT-поток данных если свойство True при отрисовке.
В МТ-потоке: canva, тип (фон, заголовок, ячейка), x индекс ячейки, y индекс ячейки, х, у, width, height, text.

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

Вот этим точно не нужно "раздувать" код элемента. Главное иметь возможность нарисовать в ячейке, а где хранить эти параметры о каждой ячейке (или как описал Netspirit случай выше только для определённых ячеек) уже не проблема MTStrTbl.

Редактировалось 3 раз(а), последний 2019-05-24 11:31:19

Ну и как это предполагается реализовать? Возьмем маленький пример -- есть таблица, есть внешний список параметров ячеек с указанием адреса каждой ячейки (по сути, прообраз базы данных), удалили или добавили строку в таблицу (это я еще про столбец промолчу), что будем делать с внешним списком параметров, тк произошло физическое смещение адресов ячеек?
Видимо, до сих пор никто понять не может, что класс ListViewer не заточен под управление каждой ячейкой. И наращивание ячеечного функционала превращается в полнейший гемор.

Редактировалось 2 раз(а), последний 2019-05-24 12:38:33

Это сложно. Для начала можно более простой вариант - когда параметры отрисовки "хранятся" в самой строке таблицы. То-есть, вычисляются в момент отрисовки на основе данных в строке.
Можно, как предлагал sla8a, дать пользователю самому полностью рисовать ячейку. А можно проще - дать возможность устанавливать предопределенные параметры: цвет фона, цвет границы, цвет/название/стиль/размер шрифта. В первом случае, правда, будет возможность рисовать всякие градиентные фоны, картинки, возможно, даже иконки в ячейках.

Редактировалось 2 раз(а), последний 2019-05-24 12:48:45

Те предполагается что-то типа Rich? Но вот в данном случае, распарсивание текста каждой ячеки отнимет уйму времени у отрисовщика. Ладно несколько строк, а если их сотни и столбцов десятки. Как это скажется на быстродействии?

Редактировалось 1 раз(а), последний 2019-05-24 12:42:41

А тут можно оптимизировать. Высота строки и количество строк известны? Можно определить какие строки в данный момент видимые (например, по положению полос прокрутки)? Тогда событие пользовательской отрисовки вызывается только для видимых в данный момент строк.

Редактировалось 2 раз(а), последний 2019-05-24 12:47:01

Netspirit, я пойму еще, если это реализовано на верхнем уровне, те на уровне библиотеки, но вот пытаться прикрутить это дело на нижнем уровне, не имея библиотечных методов управления тем же шрифтом или цветом в каждой ячейки, КМК, затея авантюрная.

--- Добавлено в 2019-05-24 12:53:43


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

Редактировалось 2 раз(а), последний 2019-05-24 12:54:11

Я просто сейчас не в курсе как конкретно в коде это реализовано. Вся отрисовка ведется в ThiMTStrTbl._OnLVCustomDraw? Это событие приходит для всех строк или только видимых?

ЕМНИП, то только для видимых. Вроде я сейчас глянул MSDN, то есть возможность управлять цветом и шрифтом ячейки нотификационными командами, насчет фона ничего толково не написано. Короче, надо разбираться серьезно. Но все это не реализовано на уровне библиотеки, а отдано на откуп пользователям.

--- Добавлено в 2019-05-24 13:56:49

Вот вроде это дело как реализовывается на C для каждой ячеки

Но если clrText и clrTextBk мы можем подменить, то как это сделать для шрифта, если мы не можем сохранить предыдущий, тк не имеем доступа к его дескриптору, не передается он в _OnLVCustomDraw. Короче, пока не совсем понятно, как это правильно реализовать

Редактировалось 4 раз(а), последний 2019-05-24 14:15:51

Так и есть.

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

Так это ж, вроде, оно и есть: lplvcd->clrTextBk = GetBkColorForSubItem.
Есть ещё отдельное сообщение для установки фоновой картинки. То-есть, имеем полный набор: цвет текста и фона, стиль и размер шрифта.

Если конкретную ячейку не хотим рисовать сами, то в CDDS_ITEMPREPAINT для неё вернуть CDRF_DODEFAULT - система отрисует.
Если вернуть CDRF_SKIPDEFAULT - можноо вообще всю ячейку нарисовать самому, например, свои границы в обычной/выделенной ячейке.

По поводу сохранения свойств ячейки. Поскольку все строки таблицы хранятся в ней же - не думаю что очень сложно с каждой строкой или ячейкой хранить любые дополнительные данные. Просто предусмотреть их очистку при удалении строки.

Редактировалось 8 раз(а), последний 2019-05-24 15:14:27

Так и реализовано же вроде так. А вот для шрифта надо CDRF_NEWFONT вроде, сожрет ли изменение шрифта по CDRF_SKIPDEFAULT. Короче, проверять надо.
А вот с форматом строки параметров что-нибудь можете предложить интересного? Я думаю, что можно попробовать реализовать что-то подобное MultiBlockFind, но с параметрами. Как-то так

Редактировалось 2 раз(а), последний 2019-05-24 15:16:56

А где эта строка будет хранится?