------------ Дoбавленo:
nesco писал(а):
не отрисовывает подложку
Ответов: 9906
Рейтинг: 351
|
|||
В твоем же примере колесо мыши на листбоксе черные дыры делает
------------ Дoбавленo: nesco писал(а): не отрисовывает подложку |
|||
карма: 9 |
|
Разработчик
Ответов: 26170
Рейтинг: 2127
|
|||
Galkov писал(а): В твоем же примере колесо мыши на листбоксе черные дыры делаетСтранно, но у меня колесо не делает дыр... Galkov писал(а): и грузит проц на 100%Да, грузит, пока по-умолчанию не включишь видимость дочерней формы. |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Или не открыть/закрыть ту же форму...
Думать дальше надо Я имею ввиду: сначала понять происходящее, а потом сделать фиксинг На этом уровне сложности "метод тыка" не очень адекватен - неужели не прочувствовал ------------ Дoбавленo: Galkov писал(а): Покажи, к примеру, свой TObj.DoDestroy из FPCЧего молчишь-то, генерильщик патчей для FPC |
|||
карма: 9 |
|
Разработчик
Ответов: 26170
Рейтинг: 2127
|
|||
Galkov писал(а): генерильщик патчей для FPCНу... я посчитал, что прозрачность нужна в FPC. А начсет TObj.DoDestroy из FPC, то я про него и не знал. Galkov писал(а): На этом уровне сложности "метод тыка" не очень адекватен - неужели не прочувствовалДа потихоньку доходит. А на патчах, я потренировался, надо же когда-то осваивать. |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Так покажешь или нет
|
|||
карма: 9 |
|
Разработчик
Ответов: 26170
Рейтинг: 2127
|
|||
Ну вот
|
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Ну ладно, вроде правильно, просто упустил я этот вопрос, а заново изгаляться с удалением компилятора, прокачкой и установкой - в лом
Когда-то долго и нудно стояло не Self.Destroy, а просто Destroy - это в FPC работает неправильно У тебя точно kol.pas из дистрибутива, или приблизительно |
|||
карма: 9 |
|
Разработчик
Ответов: 26170
Рейтинг: 2127
|
|||
Galkov писал(а): У тебя точно kol.pas из дистрибутиваТочно. Специально нулевой поставил, для получения патчей. Пропатчил только прозрачность, больше ничего. DoDestroy действительно с FPC, а вот Destroy точно не с того взял Вот настоящий, с оригиналного FPC for KOL, он отличается от Дельфячего (прошлый, как раз Дельфячий был)
Похоже, кто-то его уже правил ------------ Дoбавленo: Galkov, я вот что обнаружил, что если сделать вот так
то глюки с загрузкой процессора исчезают и все остальное работает нормально. Прогнал все примеры и ничего подозрительного не обнаружил, все работает. Может ты чего найдешь. Вот только не ругайся насчет "метода тыка", я просто пытался локализовать зацикливание. |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Получим onPaint два раза: один раз правильно, второй раз в самом конце рисования
По теории ...... |
|||
карма: 9 |
|
Разработчик
Ответов: 26170
Рейтинг: 2127
|
|||
Galkov писал(а): второй раз в самом конце рисованияОсталось только, его отловить. Что в данном случае надо считать концом отрисовки, вот это что ли Self_DblBufTopParent.fPaintDC = 0, но оно итак стоит с нормальным выходом перед DoDrawDblBuffered( Self_ ) Попробовать поставить лог и посмотреть количество запросов к DoDrawDblBuffered ------------ Дoбавленo: Поставил лог и проверил. Количество обращений на простой форме (без дочерней) что до ремарки, что после ремарки одинаковое и составляет два раза. С дочерней -- до ремарки виснет, после ремарки, также два раза на форму (вне зависимостит от видимости) плюс одна отрисовка в самом начале (таймеры отключены). |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Не фига не понимаю
Придется по-взрослому писать debug-кусочки с сохранением в файл и с пристрастием изучать это безобразие
Кстати говоря, с Global_Invalidate (InvalidateDblBufParent) - полное фуфло Никому он нафиг не нужен, кроме лишней суеты с рисованием (и onPaint, соответственно), ничего нового не дает |
|||
карма: 9 |
|
Разработчик
Ответов: 26170
Рейтинг: 2127
|
|||
Galkov писал(а): Никому он нафиг не нуженО, лишние запчасти появились, оригинально... Я заметил, что и без WM_NCPAINT в WndProcBufferedDraw можно обойтись. Я так и не нашел, где он используется по назначению. Я поотключал почти все в этом обработчике, и оно работало, странно как-то, зачем там лишнее тогда |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
nesco писал(а): О, лишние запчасти появились, оригинально... |
|||
карма: 9 |
|
Разработчик
Ответов: 26170
Рейтинг: 2127
|
|||
Galkov писал(а): после недели работы кодов становится меньше, а не больше...Но на кой-то черт их туда воткнули Может мы просто не нарвались на то баг, где нужны эти фиксы. |
|||
карма: 22 |
|
Ответов: 9906
Рейтинг: 351
|
|||
Про InvalidateDblBufParent - нет. Это вывод из знания, а не наоборот.
Видимо это писалось ДО WndProcBufferedDraw, а ПОСЛЕ написания - она уже сама делает этот Invalidate Точнее:
Теоретически, такой "перегрузки" от Кладова ожидать допустимо. В оригинальном Align тоже многое рисовалось по нескольку раз... |
|||
карма: 9 |
|