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.

[sx2008]

Zitat von Uwe Raabe:

Pack das Problem an der Wurzel...

Richtig! Beim Programmieren rächt sich schlampiges Arbeiten fast immer.
Deshalb nie murksen, sondern immer den sauberen Weg gehen!

Zitat von ConnorMcLeod:

... möchte aber z.Zt. nichts an dem geerbten Code ändern.

Betrachte es als Verbesserung deiner Fähigkeiten als Programmierer.
Refakturieren und schlechten Code verbessern sollte man häufig üben.

[ConnorMcLeod]

Hallo Leute,

auch, wenn ich völlig Eurer Meinung bin. Das geht zur Zeit nicht! Es hängt zuviel davon ab, dass es eine zeitlang noch so weiter funktioniert. Am Redesign arbeite ich parallel, und zwar radikal, aber die Umstellung ist erst in ein paar Monaten möglich. Bis dahin muss ich das Ding am Leben erhalten.

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? Gegenbeispiel: ein Hook gibt die Mglkt, von aussen kommende Messages abzufangen. Gibt es so etwas auch für die umgekehrte Richtung?

Trotzdem Danke für Eure Mühe und Zeit,
Wolfgang

[Bummi]

Die Antwort ist AFAIK einfach nein...
Ob sich Da eine Dialog drübergelegt hatte, ein Resize irgendwo stattgefunden hat, eine der Komponenten ein Paint angefordert hat ...