Вверх ↑
Этот топик читают: Гость
Этот топик был перемещен из раздела "Поддержка"
Ответов: 5
Рейтинг: 0
#1: 2020-07-24 21:31:04 ЛС | профиль | цитата
Уважаемые специалисты, объясните пожалуйста, почему по ходу создания программы перестали отображаться правильно дочерние формы? Сами формы видны, а компоненты на них нет - просто белый фон. Если щелкать мышкой по форме, то некоторые расположенные на ней компоненты отображаются контуром пунктирной линией, не прорисовывая сам компонент. Что это может быть? Составляю программу на Windows7, при отключенном интернете и отключенном антивирусе. Когда я пишу программы на Дельфи7 - такого не происходит, все дочернии формы отображаются.
Заранее благодарю за ответ.
карма: 0
Kalven
0
vip
#1.1контекстная реклама от партнеров
Ответов: 8548
Рейтинг: 790
#2: 2020-07-26 09:44:54 ЛС | профиль | цитата
Kalven, как ни старался, добиться такого эффекта не удалось
(Правда в коды элементов не лез и не обновлялся.)
карма: 18

0
Ответов: 9904
Рейтинг: 351
#3: 2020-07-26 10:14:12 ЛС | профиль | цитата
Выстрел наугад: замени "штатный" KOL на "правильный"

Обещать ничего невозможно, поскольку понять содержимое стартового поста - также невозможно же.
Только угадывать...

Информация для фантазеров

Штатный KOL эмулирует прозрачности (типовое у нас, это Label.Transparent=true) буферизацией отрисовки контролов (персональная обработка WM_PAINT) -- устанавливает TControl.DoubleBuffered=true.
Т.е., вместо прозрачной Label - рисуется текст в контексте буферной картинки парента. А тот, аналогичным образом - в контексте буферной картинки своего парента. И так - до упора. Когда эта буферная картинка выкидывается просто на экран (в смысле - отрисовывается в контексте визуального контрола).
Проблема в том, что этот "упор" в штатном KOL определяется неправильно. По правильному - это просто форма. А в штатном -- у него и owner, тоже parent. Типа, начинает рисовать контролы дочерней формы в буфере главной формы....
Именно таким вот образом -- у нас когда-то на дочерних формах всякая хрень и получалась.
Очень давно это было, деталей уже не помню.

Обращаю внимание, что слово штатный -- я писал уже без кавычек.
Потому-что и сегодня официальный KOL содержит этот глюк (насколько мне известно).
Это так, для мечтателей... Типа вот: супер новый FPC, очень официальный KOL -- и будет полная икебана!
Фигушки вам. Попробуйте сначала Кладова убедить исправить этот глюк (без введения новых), а потом мечтайте
У меня не получилось.

Редактировалось 10 раз(а), последний 2020-07-26 14:41:23
карма: 9

0
Ответов: 1617
Рейтинг: 116
#4: 2020-07-26 12:10:53 ЛС | профиль | цитата
Вполне возможно, что была попытка сделать полупрозрачные окна.
Но это не факт.
карма: 4

0
Ответов: 109
Рейтинг: 5
#5: 2020-07-26 13:05:05 ЛС | профиль | цитата
Сталкивался с таким и не раз. Единственное, что помогало - компиляция в FPC.
карма: 0

0
Ответов: 142
Рейтинг: 4
#6: 2020-07-26 14:52:35 ЛС | профиль | цитата
Возможно у вас проблемы с драйверами видеокарты
карма: 1
Мастер сам устанавливает закон
0
Ответов: 4234
Рейтинг: 661
#7: 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?

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

0
Ответов: 9904
Рейтинг: 351
#8: 2020-07-26 20:47:03 ЛС | профиль | цитата
Netspirit писал(а):
То-есть, фикс заключается в том чтобы в процедуре обработки WM_PAINT вовремя остановиться в переборе parent-ов "вверх" - при достижении своей формы?

Во-первых, это было очень-очень давно. И всех подробностей кодов я не помню. Поэтому многие твои вопросы останутся без ответа.
Уж извини, тут надо брать и лопатить коды. И "двумя деньками" тут не обойдешься.

Во-вторых, в случае "нашего" KOL -- ДА. Этого фикса нам хватило. Был еще фикс с неправильным Z-order-ом, но это ерунда... Исправляется быстро, работает надежно, на другие коды влияния не имеет никакого.
И вообще, этот фикс nesco (если мне не изменяет память) сделал в первую очередь.

В современном официальном KOL все гораздо страшнее -- система рисования переделана полностью... Там очень много заморочек с регионами, и прочей лабудой. И поэтому DoubleBuffered не всегда доходит до формы.
Сообразить глючный пример для предъявы - не просто уже.
Но можно, и я это делал. Давненько, поэтому не проси у меня этот пример - у меня с тех пор пара компов накрылось уже...
И даже находил место, где вовремя остановиться в переборе parent-ов "вверх".
Помогало. Почти полностью.
Но не до конца. При каких-то хитрых манипуляциях (типа - все свернул/восстановил) глюки в рисованиях таки проявлялись.
У нас - до конца, а там - нет.
Не все досмотрел, видимо. На этом я и сдался... Типа: не боевая задача, а так - факультатив.
карма: 9

0
8
Сообщение
...
Прикрепленные файлы
(файлы не залиты)