scroll

← →
race1 (2005-01-07 18:02) [0]

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

← →
race1 (2005-01-12 12:20) [1]

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

← →
Cosinus © (2005-01-12 12:24) [2]

Может проще ScrollBar прикрутить?

← →
race1 (2005-01-12 13:43) [3]

это как? можно и прикрутить, но главный вопрос - как отрисовать скрол, уже теперь любой, стандартный, не стандартный, но как?? :) мне сейчас видится одно решение - симулировать скрол, наследоваться от customcontrol"а и вперёд :|

← →
wicked © (2005-01-12 14:57) [4]

обрабатывать сообщения... довольно таки геморройно, но вполне реально рисовать там всё, что хочется...
если надо, могу поискать, какие именно сообщения...

← →
race1 (2005-01-12 17:56) [5]

>4
пожалуйста поищите. а то иначе придётся делать свой скрол, делать там две кнопки - вверх-вниз, тумб, обрабатывать перемещение тумба и т.д...

← →
wicked © (2005-01-12 20:23) [6]

идея такова - перехватываем у контрола свойство WindowProc (пишем свою) и отрабатываем сообщения, не забывая при этом отдавать их контролу... работы много, но она достаточно увлекательна - поверьте мне... ;) все сообщения хорошо описаны в мсдн... исходников, извините не дам, ибо
1. они на си++ (для билдера с тем же vcl-ем)
2. это здоровый кусок скинового движка (в стадии стабильной беты)
3. писано на фирму...

примерный список сообщений
WM_DESTROY - обработка отсоединения от контрола...
WM_NCCALCSIZE - вычисление и задание неклиентской части контрола (там, где скроллы и живут)...
WM_NCPAINT - прорисовка скроллов...
WM_PAINT - проверка, нужно ли скроллы рисовать... если да, рисуем...
WM_SIZE - не помню, вроде бы принудительная отрисовка контрола...
WM_STYLECHANGED и
WM_STYLECHANGING - не помню, какие то движения со стилями (чего-то мы подавляем стиль WS_EX_CLIENTEDGE)
WM_NCHITTEST - возвращаем, где находится мышь...
WM_NCLBUTTONDOWN и
WM_NCLBUTTONDBLCLK - отслеживем, находится ли мышь на скролле, если да, захватываем её...
WM_NCLBUTTONUP и
WM_LBUTTONUP - отпускание мыши...
WM_NCMOUSEMOVE - следим за мышью либо скроллим скролл (если нажата кнопка)...
WM_MOUSEMOVE - скроллим скролл...

А TScrollingWinControl чем не угодил?

← →
race1 (2005-01-13 10:24) [8]

>6
это всё здорово. но будет ли скрол ответчать на нажатия на кнопки вверх-вниз и на тумб сам? или это придётся делать самому (исходя из "WM_MOUSEMOVE - скроллим скролл". тогда какой смысл делать стд скрол и перехватывать события, если это получается симуляция скрола? а нельзя ли вызывать defwndproc для, например, нажатия\отпускания кнопки мыши, что бы виндовс сам отвечал за поведение скрола?

ps. скиновый двигатель тоже ;) теперь знаю у кого спросить про остальные скиновые контролы ;))

>7
это не то. нужно именно самому отрисовать скролбар. только рисование, больше ничего не нужно

> race1 (13.01.05 10:24) [8]
на клавиатуру контрол будет отвечать так, как ему нужно... мы эмулируем только мышиный интерфейс... сначала я тоже думал, что стоит только в обработчике WM_NCHITTEST говорить системе, где мышь (бегунок, стрелки, page-области), а дальше она сама разберется... ан нет, пришлось эмулировать всё, связанное с мышью.... зато при таком подходе мы можем сами задавать размеры и расположение скроллов там, где нам необходимо...

> а нельзя ли вызывать defwndproc для, например, нажатия\отпускания
> кнопки мыши, что бы виндовс сам отвечал за поведение скрола?

насколько помню, события мыши отдаются контролу не всегда, а только тогда, когдя мы их сами не обрабатываем...
и отдавать надо не в DefWindowProc, а предварительно сохраненному обработчику WindowProc... это нужно для того, чтоб могли отработать все vcl-ные механизмы...

scroll Найти похожие ветки