La fenêtre de déplacement et de redimensionnement interfère avec MsgWaitForMultipleObjects

Question

J'ai une application qui boucle des messages en utilisant MsgWaitForMultipleObjects pour attraper des événements supplémentaires tout en pompant des messages ui. Il semble que dès qu'une fenêtre est déplacée ou redimensionnée, DefWindowProc lance sa propre boucle de message jusqu'à ce que la souris soit libérée. Cette situation empêche la boucle externe d'intercepter les messages supplémentaires entre-temps.

Je détesterais multi-thread l'application juste à cause de cela. Y a-t-il un autre moyen de le résoudre?

Answer 1

Plusieurs emplacements supplémentaires de l'API Windows entrent dans leur propre boucle de messages. Si vous avez besoin de continuer à gérer vos messages pendant ces périodes, vous aurez besoin d'un fil séparé.

Answer 2

MsgWaitForMultipleObjects a très peu d'utilisations dans un programme multi-thread traditionnel. Il a une certaine utilisation dans Games - où les éléments de frame non client traditionnels sont omis et les API comme "MessageBox" et "DoDragDrop" sont évitées ...

Habituellement, il trouve sa meilleure utilisation dans les threads "UI worker" qui ne le font pas. héberge les fenêtres visibles, mais utilise la file d'attente des messages comme système de messagerie inter-thread et doit également attendre les poignées du noyau.

Dans votre cas, la création d'un deuxième thread ne semble pas évitable. Ironiquement, PostThreadMessage + MsgWaitForMultipleObjects sera probablement le moyen le plus simple de mettre en place un mécanisme de communication fiable entre le thread graphique et votre thread de travail "ui".