> В результате у Parent'а останется Control1.Hook, а контрола
> уже не будет.
Чего?? "Control1.Hook" это что за хрень? Как ты на апи окно объектно-ориентрованный хук поставишь? И нафиг тебе в самом хуке нужен объект, его установивший? Ты его просто не возьмешь никак (нет, ну есть функция которая по хендлу возвратит компонент, но мы сейчас как раз говорим что так делать ненадо). А раз ты его не будешь использовать, то какая нафиг разница есть он или нет? См [14] и медитировать над тем что там написано в GRushWndProc.

Вместо Control1.Hook подставь ObjectInstance или статический метод, имеющий отношение к Control1. А Control2 может быть чужим.

homm ©   (12.03.07 22:12) [60]
См [14]
Вижу. Ничего хорошего сказать не могу. Вместо запихивания в SetProp UpdateRect лучше сразу устанавливать на HDC, который в wParam приходит. (Случай wParam = 0 надо игнорировать)

> Вместо Control1.Hook подставь ObjectInstance или статический
> метод, имеющий отношение к Control1.
Да не имеет GRushWndProc никакого отношения к Control1. Она работает только с апишным хэндлом окна. До существования Control1 ей нет дела. Если есть апишное окно, то ошибки не может быть, т.к. оно и нужно, а если его нет то ошибки не может быть по опредилению, потому что эта функция никак не может быть вызвана.


> А Control2 может быть чужим.
Тем более до него нет дела.


> Вижу. Ничего хорошего сказать не могу. Вместо запихивания
> в SetProp UpdateRect лучше сразу устанавливать на HDC, который
> в wParam приходит. (Случай wParam = 0 надо игнорировать)
Рассмотрим 2 случая.
1) wParam == 0
Можем получить UpdateRect, но не имеем в распоряжении канвы, т.к. канва создается позже, когда дело доходит до WinControl.WM_PAINT.

2) wParam <> 0
Имеем в распоряжении канву, на которой будет выводится изображение, с которой потом можно будет легко содрать ClipRect, НО в этот момент уже вызвана BeginPaint, а значит мы уже не можем получить тот региоин (или рект) который потребовался для перерисовки.


> Случай wParam = 0 надо игнорировать
Тут я задумался, почему я не игнарирую случай wParam <> 0, ведь по идее там SetProp(PropUpdateRect) должа перекрывать реальный рект, при случае когда приходит уже буферная канва, потом взглянул в генофонд, и все встало на свои места:




Так что "Вместо запихивания в SetProp UpdateRect лучше сразу устанавливать на HDC, который в wParam приходит." не имеет никакого смысла.

Действительно, BeginPaint уже вызван.
> WMPaint(Message);
И на это не обратил внимания.
Посмотрел еще.
Тут я задумался, почему я не игнарирую случай wParam <> 0
Зря не игноришь, канва может прийти от PaintTo.

> Да не имеет GRushWndProc никакого отношения к Control1.
Ты заменил оконную процедуру, потом еще одному разработчику пришла в голову эта "гениальная" идея. Control1 = TGRushControl, Control1.Hook = GRushWndProc. Все будет работать только если порядок установки WndProc будет равен порядку восстановления.

Все будет работать только если порядок установки WndProc будет равен порядку восстановления.
Это и так понятно (только не равен а противоположен). Но я не знаю что я могу еще сделать что-бы обезапасить свой код. По идее  снимаю хук в WM_DESTROY, если все остальные будут снимать так-же, то все хуки снимутся в том порядке, в каком нужно. Есть мысль дополнительно проверять текущую WndProc на равенство GRushWndProc и ставить PrevWndProc только если так и есть. Вроде ничего страшного не случится, если не снять GRushWndProc вообше, или если его снимит нижестоящий хук (тут правда вроде как утечка памяти в связи с неснятым SetProp возникает, опять-же до уничтожения контролла (а он так и так на уничтожение собирается)).


> Зря не игноришь, канва может прийти от PaintTo.
Верно, подправлю.

В общем, такое надо делать в самом родителе.

> В общем, такое надо делать в самом родителе.

Так то оно так, но что-же мне VCL переписывать что-ли?

Свою панельку сделать. Я в свою, наверное, добавлю.

А нельзя,
1) Рисовать на битмапе, как уже сказали
2) Почем зре не перерисовывать, а только при действительной необходимости?
Я там делал в последнем компоненте, который на MouseMove реагировать был должен, (ссылки перекрашивать) ничего не мигало нигде

> ничего не мигало нигде

Это видимость в следствии не заинтерисованости Вами в надлежащем тестировании "не мигания", либо плохого зрения.

TStas ©   (18.03.07 19:24) [68]
1) Рисовать на битмапе, как уже сказали
Зачем? Это и так делает DoubleBuffered.

TStas ©   (18.03.07 19:24) [68]
ничего не мигало нигде
Видимо, csOpaque или вообще наследник TWinControl.

> В общем, покритикуйте пожалуста мою реализацию

Всё правильно, верный подход

DimaBr   (05.03.07 15:38) [32]

У DevExpress круче. Только по-моему ты нарушаешь их авторское право, выкладывая исходник, нет ?

По сабжу - я на bitmap'е рисую и не мучаюсь.