Synchronisation des appels

Les applications COM doivent être en mesure de traiter correctement les entrées utilisateur lors du traitement d’un ou plusieurs appels à partir de COM ou du système d’exploitation. COM fournit la synchronisation des appels pour les appartements à thread unique uniquement. Les appartements multithread (contenant des threads sans threads) ne reçoivent pas d’appels lors de l’exécution d’appels (sur le même thread). Les appartements multithreads ne peuvent pas effectuer d’appels synchronisés d’entrée. Les appels asynchrones sont convertis en appels synchrones dans des appartements multithreads. Le filtre de message n’est appelé pour aucun thread d’un appartement multithread. Pour plus d’informations sur les problèmes de thread, consultez Processus, Threads et Appartements.

Les appels COM entre les processus se répartissent en trois catégories, comme suit :

appels synchrones

La plupart des communications qui se produisent dans COM sont synchrones. Lorsque vous effectuez des appels synchrones, l’appelant attend la réponse avant de continuer et peut recevoir des messages entrants en attendant. COM entre une boucle modale pour attendre la réponse, recevoir et distribuer d’autres messages de manière contrôlée.

notifications asynchrones

Lors de l’envoi de notifications asynchrones, l’appelant n’attend pas la réponse. COM utilise les événements postMessage ou de haut niveau pour envoyer des notifications asynchrones, en fonction de la plateforme. COM définit cinq méthodes asynchrones de IAdviseSink:

• OnDataChange
• OnViewChange
• OnRename
• à l’enregistrement
• OnClose

Note

Bien que COM traite un appel asynchrone, les appels synchrones ne peuvent pas être effectués. Par exemple, l’implémentation d’une application conteneur de OnDataChange ne peut pas contenir d’appel à IPersistStorage ::Save. Ces appels sont les seuls appels asynchrones pris en charge par COM. Il n’existe aucun moyen de créer une interface personnalisée qui est asynchrone pour l’instant.

 

appels synchronisés en entrée

Lorsque vous effectuez des appels synchronisés en entrée, l’objet appelé doit terminer l’appel avant de générer le contrôle. Cela permet de s’assurer que la gestion du focus fonctionne correctement et que les données entrées par l’utilisateur sont traitées de manière appropriée. Ces appels sont effectués par COM via la fonction SendMessage, sans entrer de boucle modale. Lors du traitement d’un appel synchronisé en entrée, l’objet appelé ne doit appeler aucune fonction ou méthode (y compris les méthodes synchrones) qui peut générer un contrôle. Les méthodes suivantes sont synchronisées en entrée

• IOleWindow ::GetWindow
• IOleInPlaceActiveObject ::OnFrameWindowActivate
• IOleInPlaceActiveObject ::OnDocWindowActivate
• IOleInPlaceActiveObject ::ResizeBorder
• IOleInPlaceUIWindow ::GetBorder
• IOleInPlaceUIWindow ::RequestBorderSpace
• IOleInPlaceUIWindow ::SetBorderSpace
• IOleInPlaceFrame ::SetMenu
• IOleInPlaceFrame ::SetStatusText
• IOleInPlaceObject ::SetObjectRects

Pour réduire les problèmes qui peuvent survenir à partir du traitement asynchrone des messages, la majorité des appels de méthode COM sont synchrones. Avec la communication synchrone, il n’est pas nécessaire que le code spécial distribue et gère les messages entrants. Lorsqu’une application effectue un appel de méthode synchrone, COM entre une boucle d’attente modale qui gère les réponses requises et distribue les messages entrants aux applications capables de les traiter.

COM gère les appels de méthode en affectant un identificateur appelé ID de thread logique. Un nouveau est attribué lorsqu’un utilisateur sélectionne une commande de menu ou lorsque l’application lance une nouvelle opération COM. Les appels suivants liés à l’appel COM initial reçoivent le même ID de thread logique que l’appel initial.