Dialog, WM_PAINT und WS_CLIPCHILDREN

Question

Hallo zusammen... mal sehen ob das jemand erklären kann.

Wir haben einen Dialog gebaut. Der hat einen Hintergrund, den wir zeichnen im WM_PAINT. Ausserdem hat der Dialog natürlich Knöpfe und sonstwas drauf... jetzt passiert uns manchmal, dass dieser Dialog sich überhaupt nicht zeichnet (er war einfach ein grauer Fleck auf dem Bildschirm). Die Frage war natürlich, woher das kam... also haben wir Spy++ mitlaufen lassen. Dann haben wir gesehen, dass, wenn die Maus über einem Button steht (was per Zufall ab und zu halt der Fall war beim erstellen des Dialogs), dass dann alles austickt und er fast endlos WM_PAINT bekommt.

Wir haben damit dann etwas rumgespielt und mal das WS_CLIPCHILDREN gesetzt im Dialog. Und siehe da... weg war das Problem (wir wissen noch nicht ganz genau, ob das für uns einen Nachteil hat beim zeichnen des Hintergrundes hinter dem Child-Fenster, aber wir glauben im Moment mal, dass es kein Nachteil ist).

Die Frage ist jetzt nur, woher diese Austickerei kommt... wenn der Parent das Child überzeichnet. Dann hätte das zur Folge, dass das Child sich neu zeichnet. Gut... (und wir reden hier von einem Standard-Button, an dem haben wir gar nichts gemacht). Wieso löst jetzt aber dieses Kind-zeichnen ein erneutes Zeichnen des Parents aus?? Und wieso löst sich das Problem ab und zu in Luft auf, wenn man wie wild den Fokus auf das Fenster, neben das Fenster auf das Fenster etc. setzt ... und plötzlich verschwindet das verhalten... keine Ahnung was wir auslösen... aber so richtig ist uns das nicht klar wie Windows hier funktioniert...

Weiss das jemand was hier passiert??

Rudolf

Answer 1

Hallo Rudolf,

"

The system sends an internal WM_PAINT message only once. After the internal message is returned from GetMessage or PeekMessage, or is sent to a window by UpdateWindow, the system does not post or send any more WM_PAINT messages until the window is invalidated.

An application must call BeginPaintand EndPaint in response to WM_PAINT messages, or pass the message to the DefWindowProc function to validate the window. DefWindowProc validates the update region; it can send the WM_ERASEBKGND message if the window background needs to be erased.

In addition, an application must check for necessary internal painting by looking at its internal data structures for each WM_PAINT message, because a WM_PAINT message may have been caused by a non-NULL update.

"

Gruss,

Ionut

---

Ionut Duma, MICROSOFT   Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip„Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

Answer 2

Ja genau... wir zeichnen. Also müsste die Sache in Ordnung sein... aber, ist's nicht. Kann ich irgendwie am Ende oder während der WM_PAINT Verarbeitung rausbekommen, ob das Fenster nun vollständig "gültig" ist? Aus irgend einem Grund wird ja scheinbar das WM_PAINT erneut aufgerufen... nur, wenn ich doch Begin/EndPaint aufrufe, ging ich bisher davon aus, dass dies damit erledigt ist...

Oder ganz allgemein -> kann ich rausfinden, wieso ein WM_PAINT ausgelöst wurde? ... gut zwar ... *hmm* ... nun, egal, ist nicht so ein wichtiges Problem im Moment, wär nur interessant... leider habe ich im Moment wenig Zeit dafür...