ListView Report заголовок для 16 тыс. столбцов

Мое почтение, джентльмены.
Использую ListView на чистом WinApi.
Отрисовать область данных для 16 тыс. столбцов через NM_CUSTOMDRAW или WM_DRAWITEM (+LVS_OWNERDRAWFIXED) не проблема (рисую только видимую часть окна при прокрутке).
Проблема отрисовать заголовок для 16 тыс. столбцов.
В сабклассе для заголовка ListView рисую весь заголовок в CDDS_PREPAINT или по элементам в CDDS_ITEMPREPAINT
НО! только до общей ширины всех столбцов в 32767 пикселей.
Есть подозрение, что координаты ограниченны 16 битным значением, хотя Header_GetItemRect() записывает в RECT значения координат в LONG (32 бита). И используя этот же RECT в DrawText(HDC Заголовка, text, size, &rc, DT_SINGLELINE | DT_VCENTER) - получаем отсутствие текста при выходе какой либо координаты за 32767 пикселей.
Не работают и другие штатные события (HDN_ITEMCLICKW, HDN_ENDTRACK, HDN_ENDDRAG..).

Причем ListView_GetSubItemRect() в WM_DRAWITEM выводит RECT с минусовым/плюсовыми координатами (в зависимости от прокрутки), а Header_GetItemRect() в CDDS_PREPAINT всегда плюсовые (без учета прокрутки). Возможно поэтому отрисовать можно любое количество данных, но вот проблема с заголовком для этих данных.

Как штатный заголовок можно отрисовать в пределах видимой части ListView при прокрутке на 16 тыс. столбцов?
Хочется штатный, потому как руками делать изменение ширины столбцов, их перетаскивание и др. функционал заголовка - это писать свой GridView.

0

bedvit, не надо работать со всей шириной области данных (т.е. не надо пиксельную ширину рендерить по содержимому всех 16тыс столбцов, и/или гориз.координату столбца считать на основе ширины всех предыдущих столбцов).
Горизонтальный скролл пусть скроллит не по пикселам - а кратно ширине столбца. Т.е. скролл "листает" столбцы целиком, работая с индексами, а не с шириной. В итоге - в видимой области слева всегда будет цельный столбец, справа - может оказаться частично видимый.
Соответственно, координаты рисуемых пикселов/строк/объектов будут рассчитываться для/внутри непосредственно видимой области - а не для потенциально всей ширины 16тыс столбцов.

Попробую переписать, ибо выше вышло сумбурно.
В общем, первый=левый видимый столбец всегда располагается с нулевой горизонтальной координаты. Никакие горизонтальные пиксельные координаты при гориз.скролле не пересчитываются / не используются - меняется лишь номер самого левого видимого столбца. А рисуется/перерисовывается (после скролла) всё затем начиная с нулевой гориз.координаты - но с содержанием (и шириной) соответствующих (начиная с первого левого видимого) столбцов.
Т.е. число столбцов у ListView - не задаётся изначально/однократно, а может быть динамическим (после каждого гориз.скролла - в видимую область может попадать разное число столбцов). Ну или можно посчитать, при некоторой мин.ширине столбцов, сколько влезет при развёртывании окна на весь экран - и задать это как макс.возможное число столбцов (в реале же - будет рисоваться гораздо меньше).
Если столбцы разной ширины - то после каждого гор.скролла (или при первой отрисовке) меняем стобцам ширину на ту, которая соответствует содержимому текущих видимых столбцов.
Вспоминать ВинАПИ (сообщения и т.д.) мне лень - поэтому ХЗ что там в итоге останется полезного от функционала ListView, м.б. проще будет таблицу (сетку, заголовки) в этой ситуации рисовать самому.

0

VTsaregorodtsev, сейчас я примерно так и отрисовываю. Штатный заголовок в ListViee - это дочернее окно к ListViev. И если нулевая координата перемещается для окна данных, то для заголовка нет, нулевая координата - всегда начало. Header_GetItemRect() возвращаещает координаты от начала окна, и гдето они преобразуются в 16 бит, раз есть такое ограничение (33 тыс. пикселей). Мое предположение. Здесь как по мне и проблема.

32 тыс пикселей, к примеру при загрузке из Excel, это 500 столбцов при размере столбца "по умолчанию" 64 пикселя. А при комфортной ширине столбца, раза в три больше - это 150-200 столбцов, что кажется не так и много.

0

Возможно вам поможет Виртуальный ListView
https://rsdn.org/article/controls/virtlist.xml

0

bedvit, мне лет 15 назад понадобилось миллионы строк отображать на MFC, и я не сумел выдрессировать местный решётк

Написал свой на основе CStatic, скорость устроила, удобство хромало. Затем я познакомился с Qt и оттуда забрал идею модели данные-представление.

Не поленился переделать в таком стиле, стало удобно.

Мне кажется, встроенный контрол просто не был расчитан на такие объёмы

Правда, тысячи столбцов я не пробовал на нём

0

Замабувараев, его и используем (LVS_OWNERDATA). Это дает возможность самому владеть и управлять данными, но, к сожалению, на заголовок никак не влияет (заголовок это дочернее окно со своими данными).
Алексей1153, Qt использую на Python, в общем идея у них хорошая, согласен. Но в данном случает хотел справится чистым WinApi.
В общем проблему решил следующим образом. Виртуальный список, плюс родной функционал заголовка до 32767 пикселей, далее рисую сам.
Из минусов - нужно самому пилить перетаскивание полей, изменения размера, всю отрисовку по колонкам.
Зато подпилил изменение данных заголовка, добавление, удаление, всплывающую подсказку.
Вот так получилось, см. рис.

Миниатюры

 

0

Видео как работает.
Пожалуй, из особенностей можно еще добавить, что количество строк ограничено 100 000 000, а количество столбцов, точно не знаю, для Excel C API - 65 536 (особенности передачи массива), для СОМ загружал 1 000 000 - работает, больше не пробовал.

0