Вверх ↑
Этот топик читают: Гость
Ответов: 9906
Рейтинг: 351
#46: 2008-04-07 17:46:00 ЛС | профиль | цитата
В твоем же примере колесо мыши на листбоксе черные дыры делает
------------ Дoбавленo:

nesco писал(а):
не отрисовывает подложку
и грузит проц на 100%
карма: 9

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#47: 2008-04-07 17:52:32 ЛС | профиль | цитата
Galkov писал(а):
В твоем же примере колесо мыши на листбоксе черные дыры делает

Странно, но у меня колесо не делает дыр...
Galkov писал(а):
и грузит проц на 100%

Да, грузит, пока по-умолчанию не включишь видимость дочерней формы.
карма: 22

0
Ответов: 9906
Рейтинг: 351
#48: 2008-04-07 18:04:11 ЛС | профиль | цитата
Или не открыть/закрыть ту же форму...
Думать дальше надо
Я имею ввиду: сначала понять происходящее, а потом сделать фиксинг
На этом уровне сложности "метод тыка" не очень адекватен - неужели не прочувствовал


------------ Дoбавленo:

Galkov писал(а):
Покажи, к примеру, свой TObj.DoDestroy из FPC

Чего молчишь-то, генерильщик патчей для FPC
карма: 9

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#49: 2008-04-07 19:19:37 ЛС | профиль | цитата
Galkov писал(а):
генерильщик патчей для FPC

Ну... я посчитал, что прозрачность нужна в FPC. А начсет TObj.DoDestroy из FPC, то я про него и не знал.
Galkov писал(а):
На этом уровне сложности "метод тыка" не очень адекватен - неужели не прочувствовал

Да потихоньку доходит.
А на патчах, я потренировался, надо же когда-то осваивать.
карма: 22

0
Ответов: 9906
Рейтинг: 351
#50: 2008-04-07 19:48:41 ЛС | профиль | цитата
Так покажешь или нет
карма: 9

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#51: 2008-04-07 23:02:00 ЛС | профиль | цитата
Ну вот


procedure TObj.DoDestroy;
begin
if fRefCount <> 0 then
begin
if not LongBool( fRefCount and 1) then
Dec( fRefCount );
end
else
Self.Destroy;
end;

карма: 22

0
Ответов: 9906
Рейтинг: 351
#52: 2008-04-07 23:16:51 ЛС | профиль | цитата
Ну ладно, вроде правильно, просто упустил я этот вопрос, а заново изгаляться с удалением компилятора, прокачкой и установкой - в лом
Когда-то долго и нудно стояло не Self.Destroy, а просто Destroy - это в FPC работает неправильно

У тебя точно kol.pas из дистрибутива, или приблизительно
карма: 9

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#53: 2008-04-08 02:37:15 ЛС | профиль | цитата
Galkov писал(а):
У тебя точно kol.pas из дистрибутива

Точно. Специально нулевой поставил, для получения патчей. Пропатчил только прозрачность, больше ничего.

DoDestroy действительно с FPC, а вот Destroy точно не с того взял

Вот настоящий, с оригиналного FPC for KOL, он отличается от Дельфячего (прошлый, как раз Дельфячий был)


{$IFDEF ASM_VERSION}
destructor TObj.Destroy;
asm
PUSH EAX
CALL Final
POP EAX
XOR EDX, EDX
CALL System.@FreeMem
//CALL System.@Dispose
end;
{$ELSE ASM_VERSION} //Pascal
destructor TObj.Destroy;
begin
Final;
{$IFDEF DEBUG_ENDSESSION}
if EndSession_Initiated then
LogFileOutput( GetStartDir + 'es_debug.txt',
'FINALLED: ' + Int2Hex( DWORD( Self ), 8 ) );
{$ENDIF}

inherited;
end;
{$ENDIF ASM_VERSION}

Похоже, кто-то его уже правил



------------ Дoбавленo:

Galkov, я вот что обнаружил, что если сделать вот так


         if (Msg.wParam <> 0) then Exit;
DoDrawDblBuffered( Self_ );
// Rslt := 0;
// Result := True;

то глюки с загрузкой процессора исчезают и все остальное работает нормально.
Прогнал все примеры и ничего подозрительного не обнаружил, все работает. Может ты чего найдешь.

Вот только не ругайся насчет "метода тыка", я просто пытался локализовать зацикливание.
карма: 22

0
Ответов: 9906
Рейтинг: 351
#54: 2008-04-08 07:58:25 ЛС | профиль | цитата
Получим onPaint два раза: один раз правильно, второй раз в самом конце рисования

По теории ......
карма: 9

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#55: 2008-04-08 11:09:22 ЛС | профиль | цитата
Galkov писал(а):
второй раз в самом конце рисования

Осталось только, его отловить. Что в данном случае надо считать концом отрисовки, вот это что ли Self_DblBufTopParent.fPaintDC = 0, но оно итак стоит с нормальным выходом перед DoDrawDblBuffered( Self_ )
Попробовать поставить лог и посмотреть количество запросов к DoDrawDblBuffered

------------ Дoбавленo:


Поставил лог и проверил. Количество обращений на простой форме (без дочерней) что до ремарки, что после ремарки одинаковое и составляет два раза. С дочерней -- до ремарки виснет, после ремарки, также два раза на форму (вне зависимостит от видимости) плюс одна отрисовка в самом начале (таймеры отключены).
карма: 22

0
Ответов: 9906
Рейтинг: 351
#56: 2008-04-08 22:23:25 ЛС | профиль | цитата
Не фига не понимаю
Придется по-взрослому писать debug-кусочки с сохранением в файл и с пристрастием изучать это безобразие

#sha
Add(MainForm,4840157,35,42)
{
Left=10
Top=10
Width=313
Height=202
Position=1
link(onKeyUp,4701914:doRefresh,[])
}
Add(PaintBox,4701914,98,63)
{
Left=85
Top=10
Width=210
Height=140
Transparent=0
link(onBeforeDraw,15989047:doEvent1,[])
}
Add(Beep,12578231,266,70)
{
Freq=0
Duration=100
}
Add(Beep,5357147,210,63)
{
Freq=300
Duration=100
}
Add(Hub,15989047,154,63)
{
link(onEvent1,5357147:doBeep,[])
link(onEvent2,12578231:doBeep,[])
}
------------ Дoбавленo:

Кстати говоря, с Global_Invalidate (InvalidateDblBufParent) - полное фуфло
Никому он нафиг не нужен, кроме лишней суеты с рисованием (и onPaint, соответственно), ничего нового не дает
карма: 9

0
Разработчик
Ответов: 26170
Рейтинг: 2127
#57: 2008-04-08 22:38:42 ЛС | профиль | цитата
Galkov писал(а):
Никому он нафиг не нужен

О, лишние запчасти появились, оригинально...
Я заметил, что и без WM_NCPAINT в WndProcBufferedDraw можно обойтись. Я так и не нашел, где он используется по назначению.
Я поотключал почти все в этом обработчике, и оно работало, странно как-то, зачем там лишнее тогда
карма: 22

0
Ответов: 9906
Рейтинг: 351
#58: 2008-04-08 22:43:08 ЛС | профиль | цитата
nesco писал(а):
О, лишние запчасти появились, оригинально...

  • Лучшее средство от перхоти - гильотина
  • Дык я большую часть жизни так работаю - скажем, после недели работы кодов становится меньше, а не больше...
  • карма: 9

    0
    Разработчик
    Ответов: 26170
    Рейтинг: 2127
    #59: 2008-04-08 22:45:45 ЛС | профиль | цитата
    Galkov писал(а):
    после недели работы кодов становится меньше, а не больше...

    Но на кой-то черт их туда воткнули Может мы просто не нарвались на то баг, где нужны эти фиксы.
    карма: 22

    0
    Ответов: 9906
    Рейтинг: 351
    #60: 2008-04-08 22:51:33 ЛС | профиль | цитата
    Про InvalidateDblBufParent - нет. Это вывод из знания, а не наоборот.
    Видимо это писалось ДО WndProcBufferedDraw, а ПОСЛЕ написания - она уже сама делает этот Invalidate
    Точнее:
    
    #pas
    ValidateRect( Self_.fHandle, nil ); // как будто этому контролу Invalidate и не делали
    if not Self_DblBufTopParent.fDblBufPainting then
    begin
    Self_.DblBufTopParent.Invalidate; //но делали вместо него этому !!!
    И судя по бипам, не только его делает "еще раз"...
    Теоретически, такой "перегрузки" от Кладова ожидать допустимо. В оригинальном Align тоже многое рисовалось по нескольку раз...
    карма: 9

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