Zitat von
marabu:
Ein Repaint() gefolgt von einem Application.ProcessMessages - das muss schon sein, da sonst das auf WM_PAINT basierende UpdateWindow() nicht funktioniert - sollte den gewünschten Erfolg bringen, wenn (1) die Komponente von TWinControl abgeleitet wurde und (2) Windows keinen Einspruch erhebt.
Nein, da habe ich andere Erfahrungen gemacht.
Zitat von
MSDN:
The UpdateWindow function updates the client area of the specified window by sending a WM_PAINT message to the window if the window's update region is not empty. The function sends a WM_PAINT message directly to the window procedure of the specified window, bypassing the application queue. If the update region is empty, no message is sent.
Somit ist Application.ProcessMessages hinfällig. Auch habe ich die Erfahrung gemacht, dass mit der Rückkehr von UpdateWindow() ohne Fehler das Fenster auch fertig gezeichnet wurde. Daher ist das Aufrufen von Application.ProcessMessages zu dem Zeitpunkt eh zu spät.
Wie ich das rausgefunden habe? Ich habe in meiner Anwendung eine Lupe selbst implementiert. Wenn ich Aktionen an einem grafischen Objekt gemacht habe (z.B. verschoben), so habe ich alle solche Aktionen mit Invalidate(Rect) begleitet, damit das grafische SubSystem meiner App das System und die App nicht ausbremst (bei bis zu 10.000 Objekte auch dringend nötig). Im Paint Handler wird das ClipRect des TCanvas honoriert, was die Systemlast auch immens mindert. Ok, das zu Einleitung. Ich hatte den Fehler festgestellt, dass beim verschieben der Objekte die Lupe immer ein verpätetes Bild darstellte. Dies war das Problem des Invalidate, welches in höherer Ebene gefolgt wurde von einem BitBlt() für die Lupe. Nach dem Einfügen von einem UpdateWindow(
Handle) vor dem BitBlt() ist das Bild nun immer hunderprozentig korrekt und somit war sichergestellt, dass mit der Rückkehr von UpdateWindow() die Canvas schon aktuell ist. Auch auf den lahmsten Kisten läuft es, also liegt es nicht am schnellen Rechner.