Fenêtre en couches recevant toujours le message WM_PAINT après l'appel UpdateLayeredWindow

Question

J'ai quelques fenêtres en couches dans mon application qui utilisent UpdateLayeredWindow() pour gérer leur représentation visuelle. Selon le MSDN article on layered windows, "lorsque vous utilisez UpdateLayeredWindow() l'application n'a pas besoin de répondre à WM_PAINT ou d'autres messages de peinture." Ils partageaient certains des mêmes gestionnaires de messages que les fenêtres non-calques, donc je me suis dit que je reviendrais juste en début de WM_PAINT si la cible est une fenêtre en couches.

Bien sûr, cela a causé un problème majeur: si l'une des fenêtres en couches a fait obtenir un message WM_PAINT, la file d'attente d'entrée se retrouverait inondé par un flot ininterrompu de messages WM_PAINT. Ce résultat final est logique, puisque la fenêtre ne sera jamais validée et donc elle continuera à penser qu'elle doit peindre (je ne devrais pas revenir du gestionnaire sans valider ou BeginPaint() ing, etc.), mais ce que ne fait pas est logique, c'est pourquoi il a reçu le message en premier lieu, car il n'a aucun effet sur une fenêtre qui utilisait UpdateLayeredWindow().

Cela ne se produirait même pas de façon fiable - juste de temps en temps, et pas chaque fois que les pixels de la fenêtre avaient besoin d'être redessinés. Sanity a été restauré en retombant à DefWindowProc() lorsqu'une fenêtre en couches a reçu un message WM_PAINT, mais j'ai l'impression qu'il se passe quelque chose que je ne comprends pas. Et vu que ce problème se manifestait rarement, je crains que cela puisse cacher un problème encore plus subtil. Est-ce que le comportement attendu pour une fenêtre utilisant UpdateLayeredWindow() reçoit toujours le message occasionnel WM_PAINT? Est-ce important, tant que je le manipule correctement?

Informations supplémentaires, si nécessaire: la fenêtre appelle UpdateLayeredWindow() immédiatement après avoir été créée, puis elle est laissée à elle-même (elle ne l'appelle plus car elle ne change pas). En utilisant C++ et Win32 API, pas de MFC.

Answer 1

J'avais déjà rencontré des problèmes similaires, même si ma mémoire est peut-être un peu rouillée maintenant.

Tout d'abord, conservez DefWindowProc. Lorsque les docs disent que vous n'avez pas à répondre, je considère que cela signifie ignorer complètement le message, plutôt que d'empêcher le traitement par défaut. J'ai personnellement vécu cela de deux différentes causes. L'une était une fenêtre qui envoyait des messages WM_PAINT (mal! Méfiez-vous!). L'autre (IIRC) résultait de certains appels RedrawWindow. Dans les deux cas, j'ai craqué le problème d'un code mal écrit, hors de mon contrôle, et je n'ai jamais eu de problème à passer simplement à DefWindowProc.

J'espère que vous aurez la même expérience!

Bonne chance. J'ai trouvé que les fenêtres superposées étaient mal documentées et pleines de mises en garde et de pièges intéressants, mais très agréables une fois que vous avez eu tous les problèmes.