Pour WM_PAINT le code de fenêtrage en DefWndProc définit juste un drapeau, puis vérifie que le drapeau uniquement si la file d'attente est vide, la prochaine fois que GetMessage est appelé. Certains messages de la souris sont également coalisés (les plus anciens sont supprimés lorsque les plus récents arrivent). La vraie réponse dépend du comportement que vous voulez vraiment atteindre.
Si vous essayez d'éviter réentrée il suffit de cocher un drapeau pour une sortie rapide
, quelque chose comme:
////bool processing = false; // class/window instance variable
...
void HandleCustomMessage()
{
////if (processing)
////{
//// return;
////}
////processing = true;
DoSomething();
////processing = false;
}
Si vous voulez une file d'attente de priorité réelle, il existe de nombreuses implémentations PQ. Ajoutez l'élément de données au PQ, puis publiez un message personnalisé (toujours le même ID). Le gestionnaire de message personnalisé demande ensuite au PQ l'élément le plus prioritaire.
Une autre option est d'intercepter la boucle
GetMessage, utilisez un appel à
PeekMessage pour voir s'il y a quelque chose à faire, puis appelez
GetMessage si un message est disponible, ou consultez votre PQ autrement. Vous n'avez pas besoin d'un message personnalisé avec cette approche.
Je ne sais pas, je comprends l'approche du drapeau. Les files d'attente de l'interface utilisateur sont à un seul thread, de sorte que vous n'obtiendrez jamais la condition (ou si vous évitez d'être réentrant dans plusieurs files d'attente, je ne vois pas en quoi cela est important pour la hiérarchisation). L'utilisation d'un message personnalisé + un PQ séparé est une bonne idée, bien que la priorisation ne fonctionne pas avec d'autres messages "non personnalisés". Je me demandais s'il y avait un mécanisme interne pour cela? – sold
Oups, à moitié endormi et oublié le fil de l'interface utilisateur unique - étonnant à quelle vitesse vous oubliez quand vous n'avez pas affaire à ce genre de choses tous les jours. – devstuff