Вверх ↑
Ответов: 4621
Рейтинг: 746
#1: 2020-07-26 20:10:15 ЛС | профиль | цитата
Galkov писал(а):
Проблема в том, что этот "упор" в штатном KOL определяется неправильно. По правильному - это просто форма.
То-есть, фикс заключается в том чтобы в процедуре обработки WM_PAINT вовремя остановиться в переборе parent-ов "вверх" - при достижении своей формы?

Galkov писал(а):
Когда эта буферная картинка выкидывается просто на экран (в смысле - отрисовывается в контексте визуального контрола)
Я пока не в курсе этих кодов, но можно ли это реализовать как-то так (может оно так и сделано). Когда контрол получает сообщение WM_ERASEBACKGROUND, он должен нарисовать свой фон. Непрозрачные контролы в этом месте делают заливку. Прозрачные - просто должны ничего не рисовать, а написать голый текст без фона уже позже во время последующего WM_PAINT.
Вот только под этим контролом находятся другие элементы, например, его форма, в уже готовом нарисованном состоянии. Например, если компонент перерисовывается по причине установки нового текста окна, то в регионе контрола в этот момент находится часть рисунка формы и предыдущий текст контрола. Теперь если в момент WM_PAINT контрол начнет писать текст в этом прямоугольнике (не залив ранее фоновым цветом), этот текст просто наложится поверх предыдущего, что неприемлемо.
Для решения этой задачи во время WM_ERASEBACKGROUND он должен перебрать все контролы, которые с ним пересекаются, и перерисовать их. Начиная с самого нижнего по Z, то-есть, формы. Получили требование перерисоваться - 1) заставляем форму перерисоваться под нами 2) заставляем перерисоваться все контролы, которые лежат под нами и пересекаются с нами 3) пишем свой текст 4) заставляем перерисоваться контролы, лежащие над нами.
А может даже в WM_PAINT определяем пересекающие компоненты и перерисовываем сначала нижние, затем себя, затем верхние.
Может ли такой подход быть правильным? Насколько он похож на то, что реализовано в KOL?
карма: 26

0
Редактировалось 1 раз(а), последний 2020-07-26 20:14:51