Qu'est ce qu'une pompe de message?

une boucle de message est un petit morceau de code qui existe dans n'importe quel programme Windows natif. Il ressemble grossièrement à ceci:

MSG msg;
while (GetMessage(&msg, NULL, 0, 0))
{ 
   TranslateMessage(&msg); 
   DispatchMessage(&msg); 
} 

L'API getMessage () Win32 récupère un message depuis Windows. Votre programme passe habituellement 99,9% de son temps là-bas, attendant que Windows lui dise que quelque chose d'intéressant s'est produit. TranslateMessage() est une fonction d'aide qui traduit les messages du clavier. DispatchMessage () assure que la procédure window est appelée avec message.

chaque GUI activé.net programme a une boucle de message, il est lancé par Application.Exécuter.)(

La pertinence d'une boucle de message d'Office est lié à COM. Les programmes de bureau sont des programmes COM-enabled, c'est comme ça que Microsoft.Bureau.Interop classes fonctionne. COM s'occupe du filetage pour le compte d'un coclass COM, il s'assure que les appels faits sur une interface COM sont toujours faits à partir du fil correct. La plupart des classes COM ont une clé de registre Registre qui déclare leur modèle Threading, de loin les plus communs (y compris le bureau) utilisent "Appartement". Ce qui signifie que la seule façon sûre d'appeler une méthode d'interface est de faire l'appel à partir du même thread qui a créé l'objet de classe. Ou pour le dire autrement: de loin la plupart des classes COM ne sont pas thread-safe.

chaque fil activé par COM appartient à un appartement COM. Il y a deux types, Appartements filetés simples (STA) et un appartement filetés multiples (MTA). Un appartement threaded COM class doit être créé sur un filetage STA. Vous pouvez voir cela de retour dans les programmes .NET, le point d'entrée du fil UI d'un Windows Forms ou programme WPF a l'attribut [STAThread]. Le modèle d'appartement pour les autres fils est défini par le fil.Méthode SetApartmentState ().

de Grandes parties de Windows plomberie ne fonctionnera pas correctement si le thread d'INTERFACE utilisateur n'est pas STA. Notamment Drag+Drop, le presse-papiers, les dialogues Windows comme OpenFileDialog, les commandes comme WebBrowser, Applications D'automatisation de L'UI comme les lecteurs d'écran. Et de nombreux serveurs COM, comme Office.

une exigence dure pour un thread STA est qu'il ne doit jamais bloquer et doit pomper une boucle de message. La boucle de message est importante parce que C'est ce que COM utilise pour mobiliser un appel de méthode d'interface d'un thread à un autre. Bien que .NET facilite la sélection des appels (contrôle.BeginInvoke ou Dispatcher.BeginInvoke par exemple), c'est en fait une chose très délicate à faire. Le fil qui s'exécute l'appel doit être dans un état connu. Vous ne pouvez pas simplement interrompre arbitrairement un fil et le forcer à faire un appel de méthode, ce qui causerait d'horribles problèmes de rentrée. Un thread doit être" idle", pas occupé à exécuter n'importe quel code qui est en train de muter l'état du programme.

peut-être Pouvez-vous voir où cela mène: oui, quand un programme exécute la boucle de message, il est inactif. Le marshaling réel a lieu à travers une fenêtre cachée que COM crée, il utilise PostMessage pour avoir la procédure de fenêtre de cette fenêtre exécute le code. Sur le fil STA. La boucle de message assure le fonctionnement de ce code.

la "pompe à message" est un élément central de tout programme Windows qui est responsable de l'envoi des messages de fenêtrage aux différentes parties de l'application. C'est le cœur de la programmation de Win32 UI. En raison de son ubiquité, de nombreuses applications utilisent la pompe à messages pour passer des messages entre différents modules, ce qui explique pourquoi les applications de bureau se casseront si elles sont exécutées sans aucune interface utilisateur.

Wikipedia a une description de base .

John parle de la façon dont le système de fenêtres (et d'autres systèmes de fenêtres - x Fenêtre , Mac OS original....) implémenter des interfaces utilisateur asynchrones en utilisant des événements via un système de messages.

derrière les coulisses pour chaque application il y a un système de messagerie où chaque fenêtre peut envoyer des événements à d'autres fenêtres ou écouteurs d'événements -- ceci est mis en œuvre en ajoutant un message à la file d'attente de messages. Il y a une boucle principale qui fonctionne toujours regarder cette file d'attente de messages et ensuite envoyer les messages (ou les événements) aux auditeurs.

l'article de Wikipedia boucle de Message dans Microsoft Windows montre le code d'exemple d'un programme de Base Windows -- et comme vous pouvez le voir au niveau le plus basique un programme Windows est juste la"pompe de message".

donc, pour tout rassembler. La raison pour laquelle un programme windows conçu pour soutenir un UI ne peut pas agir comme un le service est parce qu'il a besoin de la boucle de message en cours d'exécution tout le temps pour activer le soutien D'UI. Si vous l'implémentez comme un service tel que décrit, il ne sera pas en mesure de traiter la gestion asynchrone interne de l'événement.

In COM , a message pump serialise and de-serialise messages sent between apartments. Un appartement est un mini processus dans lequel les composants COM peuvent être exécutés. Les appartements sont disponibles en mode fileté simple et fileté libre. Appartements filetés simples sont principalement un système hérité pour les applications de com composants qui ne prennent pas en charge multi-filetage. Ils étaient généralement utilisés avec Visual BASIC (car cela ne supportait pas le code multi-threadé) et les applications héritées.

je suppose que l'exigence de la pompe à message pour mot provient soit de L'API COM ou des parties de l'application n'étant pas thread safe. Gardez à l'esprit que les modèles .NET filetage et de collecte des ordures ne fonctionnent pas bien avec COM de la boîte. COM a un mécanisme de collecte des ordures très simpliste et un modèle de filetage qui vous oblige à faire les choses à la manière COM. En utilisant la norme Office PIAs exige toujours que vous fermiez explicitement les références D'objet COM, donc vous devez garder une trace de chaque poignée COM créé. Les ÉFVP vont aussi créer des choses dans les coulisses si vous n'êtes pas prudent.

. L'intégration sur le net-COM est un sujet à part entière, et il y a même des livres écrits sur le sujet. Même en utilisant Comapis pour Office à partir d'une application interactive de bureau, vous devez sauter à travers les cerceaux et vous assurer que les références sont explicitement publiées.

Office peut être considéré comme fil-unsafe, donc vous aurez besoin d'une instance séparée de Word, Excel ou d'autres Office applications pour chaque fil. Il vous faudrait engager les frais généraux de départ ou entretenir un pool de fils. Un pool de threads devrait être méticuleusement testé pour s'assurer que toutes les références COM ont été correctement publiées. Même en démarrant et en fermant des instances, vous devez vous assurer que toutes les références sont publiées correctement. Si vous ne marquez pas vos " i "et ne croisez pas vos" t " ici, un grand nombre d'objets COM morts et même des instances entières de mot en cours d'exécution seront divulgués.

Wikipedia suggère que cela signifie le programme main Event Loop .

je pense que ce Canal 9 discussion a une belle succincte explication:

ce processus de communication par fenêtre est rendu possible par la pompe à Message Windows. Pensez à la pompe à Message comme une entité qui permet la coopération entre les fenêtres d'application et le bureau.