Partager via

Présentation des problèmes de threading

  • Article

Cette rubrique décrit les scénarios courants de threading pour les implémentations clients de l’automatisation de l’interface utilisateur Microsoft et explique comment éviter les problèmes qui peuvent survenir si un client utilise incorrectement le threading.

Cette rubrique contient les sections suivantes :

Automatisation de l’interface utilisateur et le Thread UI

En raison de la manière dont l’automatisation de l’interface utilisateur utilise les messages Windows, des conflits peuvent survenir lorsqu’une application cliente tente d’interagir avec sa propre interface utilisateur sur le thread UI. Ces conflits peuvent entraîner des performances très lentes, voire provoquer l’arrêt de la réponse de l’application.

Si votre application cliente est destinée à interagir avec tous les éléments sur le bureau, y compris sa propre interface utilisateur, vous devez effectuer tous les appels d’automatisation de l’interface utilisateur depuis un thread distinct. Cela inclut la localisation des éléments, par exemple, en utilisant IUIAutomationTreeWalker ou la méthode IUIAutomationElement::FindAll et en utilisant des modèles de contrôle. Ce thread ne doit posséder aucune fenêtre et doit être un thread du modèle multithread cloisonné (MTA) de COM (un thread qui initialise COM en appelant CoInitializeEx avec l’indicateur COINIT_MULTITHREADED).

Il est sûr de faire des appels d’automatisation de l’interface utilisateur dans un gestionnaire d’événements d’automatisation de l’interface utilisateur, car le gestionnaire d’événements est toujours appelé sur un thread non-UI. Cependant, lors de l’abonnement à des événements pouvant provenir de l’interface utilisateur de votre application cliente, vous devez effectuer l’appel à IUIAutomation::AddAutomationEventHandler, ou une méthode apparentée, sur un thread non-UI (qui devrait également être un thread MTA). Supprimez les gestionnaires d’événements situés sur un même thread.

Un client d’automatisation de l’interface utilisateur ne doit pas utiliser plusieurs threads pour ajouter ou supprimer des gestionnaires d’événements. Un comportement inattendu peut se produire si un gestionnaire d’événements est ajouté ou supprimé pendant qu’un autre est ajouté ou supprimé dans le même processus client.

Modèle de threading pour les gestionnaires d’événements

Un client d’automatisation de l’interface utilisateur doit utiliser le modèle de threading COM MTA pour les threads qui implémentent des gestionnaires d’événements. L’utilisation du modèle d’appartement à thread unique (STA) peut causer des problèmes tels qu’empêcher les clients de supprimer les gestionnaires d’événements du thread.

Affinité d’appartement COM sur Windows 64 bits

Selon la spécification COM, la durée de vie d’un objet distant est régie par la durée de vie de l’appartement où la fonction CoCreateInstance est appelée pour créer l’objet. Lorsque l’appartement d’origine se ferme, l’objet distant est également libéré.

Pour les clients d’automatisation de l’interface utilisateur, ce comportement COM peut signifier que la durée de vie de l’élément d’aide 32/64 distant (créé par UIAutomationCore.dll) utilisé par un élément 32 bits est régie par la durée de vie de l’appartement du thread qui a créé l’élément. Si le client d’automatisation de l’interface utilisateur transmet l’élément à un autre thread, l’élément peut devenir invalidé lorsque l’appartement d’origine se ferme. Le client d’automatisation de l’interface utilisateur doit gérer ces problèmes de manière élégante en capturant les erreurs lors de l’utilisation des éléments d’automatisation transmis.

Le même problème peut survenir avec un client d’automatisation de l’interface utilisateur 32 bits ayant des éléments 64 bits.

Doc conceptuel :

Obtention d'éléments UI Automation

S’abonner aux événements d’automatisation de l’interface utilisateur

Vue d'ensemble des événements UI Automation

Autres ressources :

Descriptions et fonctionnements des modèles de threading OLE