Paint Message abfangen/Herkunft finden

[ConnorMcLeod]

Hallo Kollegen,

vielen Dank erstmal im Nachhinein für all die interessante Lektüre, die ich hier schon finden durfte in den letzten Jahren.

Jetzt habe ich ein (denke ich) Riesenproblem und frage mal so in die Runde:

Wie kann ich herausfinden welche Komponente dafür verantwortlich ist, dass ein WM_PAINT ausgeführt wird?

Habe hier fremden Code und es passiert ein unerwünschtes Zeichnen der Form. Eigentlich ist alles fertiggezeichnet und es wird eine Usereingabe erwartet, aber auf einmal passiert besagtes WM_PAINT.

Der Callstack sagt nur, in welcher Hierarchiefolge das Paint ausgeführt wird, aber nicht von wo die Message herkommt.
Im Messagehandler dito.

Meine Vermutung ist, dass eine der vielen Komponenten auf der Form ein Refresh oder Invalidate o.Ä. veranlasst ... aber welche?

Kann man auch einen Hook für rausgehende Messages machen, die von Delphi an Windows gesendet werden?

Danke für alle Ideen!!
lg Wolfgang
D2010, Win7 Ultimate

PS: AFAIK gibt es keinen Timer.

[Uwe Raabe]

Das WM_PAINT wird von Windows ausgelöst, wenn es der Meinung ist, daß sich das Control neu zeichnen sollte. Das kann z.B. sein, wenn ein darüberliegendes Fenster wieder gelöscht oder verschoben wird. Das Invalidate bzw. Refresh gibt dem Control nur die Möglichkeit, Windows zu so einem WM_PAINT-Ereignis aufzufordern.

Grundsätzlich sollte ein Control jederzeit in der Lage sein, einen Paint-Befehl zu befolgen. Dein "Riesenproblem" ist meiner Meinung nach also nicht, daß das WM_PAINT auftritt, sondern daß der Code damit nicht klar kommt.

[ConnorMcLeod]

Servus Uwe,

danke für die flotte Antwort; Du hast Recht, daß Windows selbst die Message sendet, wenn es der Meinung ist ... etc.

In diesem Fall wird mein Fenster erzeugt und gezeigt und damit Ende. Kein anderes Fenster darüber gezeichnet o.Ä. Das Ganze passiert auch innerhalb von Sekundenbruchteilen und ist auf einem superschnellen Rechner vllt gar nicht zu sehen. (Für alle, die sich jetzt denken *Na, und?* sei gesagt, dass beim Zeichnen sehr viel abgefragt wird und das nicht nur Performance kostet, sondern auch logische Fehler produziert).

Es kommt einfach eine zweite WM_PAINT Message daher.
d.h. das Fenster wird gezeichnet, dann nocheinmal. Beim zweitenmal wird es falsch gezeichnet, weil die Logik, die z.B. die Farben berechnet, nicht dafür ausgelegt ist, dass die Berechnung zweimal hintereinander erfolgt (wie gesagt ... nicht mein Code ).

So, als ob irgendeine andere Komponente noch ein Refresh bzw Repaint hinterherschickt. Das würde nach meinem Verständnis Windows ebenfalls dazu veranlassen, die WM_PAINT an meine Applikation zu schicken.

Lt. Callstack ist es beim zweiten Mal auch ein etwas anderer Aufruf.

Hm. Meine nächste Idee ist, der Reihe nach alle Kompos von der Form zu löschen, solange, bis das Phänomen verschwindet.

Deine Argumente haben mich jetzt dazu bewogen, genau zu prüfen, was der Fokus zwischen den beiden WM_PAINTs macht; kann sein, dass der hin- und herspringt.

Danke und lg, Wolfgang

[Bummi]

das was Du "painten" möchtest sollte IMHO unabhängig vom Aufruf sein, also gegf. Offscreen malen und im Paint das Resultat darstellen.

[ConnorMcLeod]

Servus Thomas,

stimmt, so würde ich das in diesem Fall wahrscheinlich auch machen, möchte aber z.Zt. nichts an dem geerbten Code ändern.

Ich weiss, wer malt und ich weiss, wie gemalt wird; ich weiss aber leider nicht, warum gemalt wird ...

Danke trotzdem und lg,
Wolfgang

[Uwe Raabe]

Selbst wenn du jetzt herausfindest, was das Paint auslöst, hilft dir das nicht viel weiter. Es gibt die unterschiedlichsten Auslöser für ein Paint-Ereignis auf die du überhaupt keinen Einfluss hast. Pack das Problem an der Wurzel und mach die Paint-Methode so, daß sie immer und überall funktioniert. Nur so meine Meinung...

[Luckie]

Zitat von ConnorMcLeod:

Beim zweitenmal wird es falsch gezeichnet, weil die Logik, die z.B. die Farben berechnet, nicht dafür ausgelegt ist, dass die Berechnung zweimal hintereinander erfolgt (wie gesagt ... nicht mein Code ).

Dann ist entweder dein Konzept falsch oder du benutzt den Code falsch. Wenn du den Code nicht ändern willst, warum auch immer, musst du wohl dein Konzept ändern.

[alfold]

Zitat von ConnorMcLeod:

...Habe hier fremden Code und es passiert ein unerwünschtes Zeichnen der Form. Eigentlich ist alles fertiggezeichnet und es wird eine Usereingabe erwartet, aber auf einmal passiert besagtes WM_PAINT...

sieht ja so aus als wenn es keine standard Komponente ist! oder wie soll man das verstehen? Eine Form für Usereingaben, da kann ja im allg nicht besonderes als code sein!!??

Zitat von ConnorMcLeod:

..Es kommt einfach eine zweite WM_PAINT Message daher.
d.h. das Fenster wird gezeichnet, dann nocheinmal. Beim zweitenmal wird es falsch gezeichnet, weil die Logik, die z.B. die Farben berechnet, nicht dafür ausgelegt ist, dass die Berechnung zweimal hintereinander erfolgt (wie gesagt ... nicht mein Code )...

Kann es sein das da evtl noch ein 'Applikation.Processmessage' drin ist?

Zitat von ConnorMcLeod:

Ich weiss, wer malt und ich weiss, wie gemalt wird; ich weiss aber leider nicht, warum gemalt wird ...

Gemahlt wird aber nur mit Images oder halt mit graphic Komponenten. Standard Komponenten machen das selbst! Darum wundere ich mich über diese Aussage.

Zitat von ConnorMcLeod:

..Ich habe gefragt, wie schaffe ich *X* und bekomme als Antwort: mach lieber *Y*. Das ist zwar nett gemeint, aber keine wirkliche Hilfe.

Seit der Umstellung (von D7) auf D2010 ist Einiges anders und ein Tail davon beeinflusst scheinbar dieses Verhalten.

Meine Frage: wie kann ich feststellen, von welchem Code das Windows dazu veranlasst wird, ein WM_PAINT zu senden?

in dem Du mal ein Haltpunkt setzt und dann step by step durch gehst und Dir den Code richtig anschaust!

Ansonsten kann ich Dir nur empfehlen mal 2Bilder an Deinem ersten Post ranzuhängen damit wir sehen was Du meinst! Noch besser ist natürlich der Code für das sogenannte EingabeFenster um das es ja hier geht! Oder treten diese Fehler in Deinem ganzen Projekt auf!?

alfold

[ConnorMcLeod]

Danke für Euer Mitgefühl
Ich sehe, dass ich zuwenig Info gegeben habe...

Es handelt sich um ein MDIChild, in dem Labels, DBEdits und DBGrids sind. Alles abgeleitete Versionen mit zusätzlicher firmeneigener Funktionalität. Um das DbGrid geht es und hier passieren kranke Dinge, die leider dzt unumgänglich sind. Und die u.A. pro Zelle(!) die DB um einen Status befragen, der die Farbe beeinflusst. Bitte nicht lachen, mit ist bereits schlecht, ok?

Ein Buffer-Bitmap scheidet hiermit leider aus, weil im Grid auch gescrollt wird.

Die Idee mit ProcessMessages ist gut, das seh ich mir an. Weil ich ProcessMessages um jeden Preis vermeide, habe ich nicht daran gedacht.

Gesteppt habe ich schon, danke für den Tip, sowas mach ich meistens als Erstes.

Die Gesamtheit der Antworten hat mir eine Richtung gezeigt, ich schätze, dass der Datensatzzeiger im Hintergrund auf Unsinn verändert wird und das Grid nochmal zeichnen möchte.

Danke nochmal und lg,
Wolfgang

[alfold]

Vielleicht? hilft hier schon die Komponente/Form DoubleBuffered := True zu setzen?
Das nochmalige zeichen kann zb auch durch ein Changeereignis passieren!
alfold