À propos de l’échange dynamique de données

Windows fournit plusieurs méthodes pour transférer des données entre applications. Une méthode consiste à utiliser le protocole DDE (Dynamic Data Exchange). Le protocole DDE est un ensemble de messages et d’instructions. Il envoie des messages entre les applications qui partagent des données et utilise la mémoire partagée pour échanger des données entre les applications. Les applications peuvent utiliser le protocole DDE pour les transferts de données à usage unique et pour les échanges continus dans lesquels les applications s’envoient des mises à jour les unes aux autres à mesure que de nouvelles données sont disponibles.

Windows prend également en charge la bibliothèque de gestion DDEML (Dynamic Data Exchange Management Library). DDEML est une bibliothèque de liens dynamiques (DLL) que les applications peuvent utiliser pour partager des données. Le DDEML fournit des fonctions et des messages qui simplifient la tâche d’ajout de la fonctionnalité DDE à une application. Au lieu d’envoyer, publier et traiter des messages DDE directement, une application utilise les fonctions DDEML pour gérer les conversations DDE. (Une conversation DDE est l’interaction entre les applications clientes et serveurs.)

Le DDEML fournit également une fonctionnalité de gestion des chaînes et des données que les applications DDE partagent. Au lieu d’utiliser des atomes et des pointeurs vers des objets de mémoire partagée, les applications DDE créent et échangent des handles de chaîne, qui identifient les chaînes, et des handles de données, qui identifient les objets mémoire. Le DDEML permet également à une application serveur d’inscrire les noms de service qu’elle prend en charge. Les noms sont diffusés vers d’autres applications du système, qui peuvent utiliser les noms pour se connecter au serveur. En outre, le DDEML garantit la compatibilité entre les applications DDE en les forçant à implémenter le protocole DDE de manière cohérente.

Les applications existantes qui utilisent le protocole DDE basé sur les messages sont entièrement compatibles avec celles qui utilisent le DDEML. Autrement dit, une application qui utilise le DDE basé sur les messages peut établir des conversations et effectuer des transactions avec des applications qui utilisent le DDEML. En raison des nombreux avantages de la DDEML, les nouvelles applications doivent l’utiliser plutôt que les messages DDE. Pour utiliser les éléments API de DDEML, vous devez inclure le fichier d’en-tête DDEML dans vos fichiers sources, établir un lien avec la bibliothèque DDEML et vérifier que la bibliothèque de liens dynamiques DDEML se trouve dans le chemin de recherche du système.

Les rubriques suivantes sont traitées dans cette section.

• Protocole d’échange de données dynamiques
• Utilisations pour Windows Dynamic Data Exchange
• Échange dynamique de données du point de vue de l’utilisateur
• Concepts d’échange de données dynamiques
  • Client, serveur et conversation
  • Noms d’applications, de rubriques et d’éléments
  • Rubrique système
  • Liaisons de données permanentes
  • Atoms et objets de mémoire partagée
• Vue d’ensemble des messages d’échange de données dynamiques
• Flux de messages d’échange de données dynamiques
• Fonctions d’empaquetage de paramètres
• Échange de données dynamiques et emprunt d’identité

Protocole d’échange de données dynamiques

Étant donné que Windows a une architecture basée sur les messages, la transmission de messages est la méthode la plus appropriée pour transférer automatiquement des informations entre les applications. Toutefois, les messages ne contiennent que deux paramètres (wParam et lParam) pour transmettre des données. Par conséquent, ces paramètres doivent faire référence indirectement à d’autres éléments de données lorsque plus de quelques mots d’informations passent entre des applications. Le protocole DDE définit exactement comment les applications doivent utiliser les paramètres wParam et lParam pour passer des morceaux de données plus volumineux au moyen d’atomes globaux et de handles de mémoire partagée. Le protocole DDE a des règles spécifiques pour l’allocation et la suppression d’atomes globaux et d’objets de mémoire partagée.

Un atome global est une référence à une chaîne de caractères. Dans le protocole DDE, les atomes identifient les applications qui échangent des données, la nature des données échangées et les éléments de données eux-mêmes. Pour plus d’informations sur les atomes, consultez À propos des atomes.

Utilisations pour Windows Dynamic Data Exchange

DDE est le plus approprié pour les échanges de données qui ne nécessitent pas d’interaction continue de l’utilisateur. En règle générale, une application fournit une méthode permettant à l’utilisateur d’établir le lien entre les applications qui échangent des données. Toutefois, une fois ce lien établi, les applications échangent des données sans autre intervention de l’utilisateur.

DDE peut être utilisé pour implémenter un large éventail de fonctionnalités d’application, par exemple :

• Liaison à des données en temps réel, telles que les mises à jour boursières, les instruments scientifiques ou le contrôle des processus.
• Création de documents composés, tels qu’un document de traitement de texte qui inclut un graphique produit par une application graphique. À l’aide de DDE, le graphique change lorsque les données sources sont modifiées, tandis que le reste du document reste le même.
• Exécution de requêtes de données entre applications, telles qu’une feuille de calcul interrogeant une base de données pour les comptes impayés.

Échange dynamique de données du point de vue de l’utilisateur

L’exemple suivant illustre la façon dont deux applications DDE peuvent coopérer, comme le montre le point de vue de l’utilisateur.

Un utilisateur de feuille de calcul souhaite utiliser Microsoft Excel pour suivre le cours d’une action particulière à la Bourse de New York. L’utilisateur dispose d’une application appelée Quote qui à son tour a accès aux données NYSE. La conversation DDE entre Excel et Quote se déroule comme suit :

• L’utilisateur lance la conversation en fournissant le nom de l’application (Devis) qui fournira les données et le sujet d’intérêt particulier (NYSE). La conversation DDE obtenue est utilisée pour demander des cotations sur des actions spécifiques.
• Excel diffuse les noms des applications et des rubriques à toutes les applications DDE en cours d’exécution dans le système. Quote répond, établissant une conversation avec Excel sur le sujet NYSE.
• L’utilisateur peut ensuite créer une formule de feuille de calcul dans une cellule qui demande que la feuille de calcul soit automatiquement mise à jour chaque fois qu’un cours particulier change. Par exemple, l’utilisateur peut demander une mise à jour automatique chaque fois qu’un changement se produit dans le prix de vente de l’action ZAXX en spécifiant la formule Excel suivante : ='Quote'|' NYSE'! ZAXX
• L’utilisateur peut mettre fin à la mise à jour automatique de la cotation boursière ZAXX à tout moment. D’autres liens de données qui ont été établis séparément (par exemple, pour les cotations d’autres actions) resteront toujours actifs dans le cadre de la même conversation du NYSE.
• L’utilisateur peut également mettre fin à l’intégralité de la conversation entre Excel et Quote sur le sujet NYSE, afin qu’aucun lien de données spécifique sur ce sujet ne puisse être établi sans lancer une nouvelle conversation.

Concepts d’échange de données dynamiques

Les sections suivantes expliquent les concepts et la terminologie importants qui sont essentiels à la compréhension de l’échange dynamique de données.

• Client, serveur et conversation
• Noms d’applications, de rubriques et d’éléments
• Rubrique système
• Liaisons de données permanentes
• Atoms et objets de mémoire partagée

Client, serveur et conversation

Deux applications participant à DDE sont dites engagées dans une conversation DDE. L’application qui lance la conversation est l’application cliente DDE ; l’application qui répond au client est l’application serveur DDE. Une application peut participer à plusieurs conversations en même temps, agissant en tant que client dans certains et en tant que serveur dans d’autres.

Une conversation DDE a lieu entre deux fenêtres, une pour chacune des applications participantes. Une fenêtre peut être la fenêtre main de l’application , une fenêtre associée à un document spécifique, comme dans une application MDI (Multi-Document Interface) ou une fenêtre masquée (invisible) dont le seul but est de traiter les messages DDE.

Étant donné qu’une conversation DDE est identifiée par la paire de handles vers les fenêtres engagées dans la conversation, aucune fenêtre ne doit être engagée dans plusieurs conversations avec une autre fenêtre. L’application cliente ou l’application serveur doit fournir une fenêtre différente pour chacune de ses conversations avec un serveur ou une application cliente particulière.

Une application peut s’assurer qu’une paire de fenêtres client et serveur n’est jamais impliquée dans plusieurs conversations en créant une fenêtre masquée pour chaque conversation. Le seul objectif de cette fenêtre est de traiter les messages DDE.

Noms d’applications, de rubriques et d’éléments

Le protocole DDE identifie les unités de données passées entre le client et le serveur avec une hiérarchie à trois niveaux de noms d’application, de rubrique et d’élément.

Chaque conversation DDE est définie de manière unique par le nom et la rubrique de l’application. Au début d’une conversation DDE, le client et le serveur déterminent le nom et la rubrique de l’application. Le nom de l’application est généralement le nom de l’application serveur. Par exemple, quand Excel agit en tant que serveur dans une conversation, le nom de l’application est Excel.

La rubrique DDE est une classification générale des données dans laquelle plusieurs éléments de données peuvent être « discutés » (échangés) pendant la conversation. Pour les applications qui fonctionnent sur des documents basés sur des fichiers, la rubrique est généralement un nom de fichier. Pour les autres applications, la rubrique est un nom spécifique à l’application.

Étant donné que les handles de fenêtre client et serveur identifient ensemble une conversation DDE, le nom de l’application et la rubrique qui définissent une conversation ne peuvent pas être modifiés au cours de la conversation.

Un élément de données DDE est des informations relatives à la rubrique de conversation échangée entre les applications. Les valeurs de l’élément de données peuvent être passées du serveur au client ou du client au serveur. Les données peuvent être transmises avec n’importe quel format de Presse-papiers standard ou avec un format de Presse-papiers inscrit. Un format spécial inscrit nommé Link identifie un élément dans une conversation DDE. Pour plus d’informations sur les formats du Presse-papiers, consultez Presse-papiers.

Rubrique système

Les applications doivent prendre en charge la rubrique système à tout moment. Cette rubrique fournit un contexte pour les informations qui peuvent être d’intérêt général pour une autre application.

Les valeurs des éléments de données doivent être affichées au format CF_TEXT Presse-papiers. Les éléments individuels des valeurs d’élément d’une rubrique système doivent être délimités par des caractères de tabulation. Le tableau suivant suggère certains éléments pour la rubrique système.

Liaisons de données permanentes

Une fois qu’une conversation DDE a commencé, le client peut établir une ou plusieurs liaisons de données permanentes avec le serveur. Une liaison de données est un mécanisme de communication par lequel le serveur avertit le client chaque fois que la valeur d’un élément de données spécifié change. La liaison de données est permanente dans le sens où ce processus de notification se poursuit jusqu’à ce que la liaison de données ou la conversation DDE elle-même soit terminée.

Il existe deux types de liaisons de données DDE permanentes : chaudes et chaudes. Dans une liaison de données à chaud, le serveur informe le client que la valeur de l’élément de données a changé, mais le serveur n’envoie pas la valeur de données au client tant que le client ne la demande pas. Dans une liaison de données à chaud, le serveur envoie immédiatement la valeur de données modifiée au client.

Les applications qui prennent en charge les liaisons de données chaudes ou chaudes fournissent généralement une commande Copier ou Coller un lien dans leur menu Modifier pour permettre à l’utilisateur d’établir des liens entre les applications.

Atoms et objets de mémoire partagée

Certains arguments des messages DDE sont des atomes globaux ou des objets de mémoire partagée. Les applications utilisant ces arguments doivent suivre des règles explicites sur le moment où les allouer et les supprimer. Dans tous les cas, l’expéditeur du message doit supprimer tout objet atom ou mémoire partagée que le récepteur prévu ne recevra pas en raison d’une condition d’erreur, telle que l’échec de la fonction PostMessage .

DDE utilise des objets de mémoire partagée à trois fins :

• Pour transporter une valeur d’élément de données à échanger. Il s’agit d’un élément référencé par le paramètre hData dans les messages WM_DDE_DATA et WM_DDE_POKE .
• Pour porter des options dans un message. Il s’agit d’un élément référencé par le paramètre hOptions dans un message WM_DDE_ADVISE .
• Pour porter une chaîne d’exécution de commande. Il s’agit d’un élément référencé par le paramètre hCommands dans le message WM_DDE_EXECUTE et son message WM_DDE_ACK correspondant.

Une application qui reçoit un objet de mémoire partagée DDE doit le traiter en lecture seule. L’application ne doit pas utiliser l’objet comme zone de lecture-écriture mutuelle pour l’échange libre de données.

Comme avec un atome DDE, une application doit libérer un objet de mémoire partagée pour gérer efficacement la mémoire. L’application doit également verrouiller et déverrouiller les objets mémoire.

Vue d’ensemble des messages d’échange de données dynamiques

Étant donné que DDE est un protocole basé sur les messages, il n’utilise aucune fonction ni bibliothèque. Toutes les transactions DDE sont effectuées en passant certains messages DDE définis entre les fenêtres client et serveur.

Il y a neuf messages DDE ; Les constantes symboliques de ces messages sont définies dans le fichier d’en-tête DDE. Certaines structures pour les différents messages DDE sont également définies dans ce fichier d’en-tête.

Le tableau suivant récapitule les messages DDE.

Une application appelle SendMessage pour émettre le message WM_DDE_INITIATE ou un message WM_DDE_ACK envoyé en réponse à WM_DDE_INITIATE. Tous les autres messages sont envoyés par PostMessage. Le premier paramètre de ces appels est un handle de la fenêtre de réception ; le deuxième paramètre contient le message à envoyer ; le troisième paramètre identifie la fenêtre d’envoi ; et le quatrième paramètre contient les arguments spécifiques au message.

Flux de messages d’échange de données dynamiques

Une conversation DDE classique se compose des événements suivants :

1. L’application cliente lance la conversation et l’application serveur répond.

2. Les applications échangent des données par l’une ou l’autre des méthodes suivantes :

   • • L’application serveur envoie des données au client à la demande du client.
     • L’application cliente envoie des données non sollicitées à l’application serveur.
     • L’application cliente demande à l’application serveur d’avertir le client chaque fois qu’un élément de données change (lien de données chaud).
     • L’application cliente demande à l’application serveur d’envoyer des données chaque fois que les données changent (lien de données à chaud).
     • L’application serveur exécute une commande à la demande du client.

3. L’application cliente ou serveur met fin à la conversation.

Une fenêtre d’application qui traite les demandes d’un client ou d’un serveur doit les traiter strictement dans l’ordre dans lequel elles sont reçues.

Un client peut établir des conversations avec plusieurs serveurs ; un serveur peut avoir des conversations avec plusieurs clients. Lors de la gestion des messages provenant de plusieurs sources, un client ou un serveur doit traiter les messages d’une conversation de manière synchrone, mais il n’a pas besoin de traiter tous les messages de manière synchrone. En d’autres termes, il peut passer d’une conversation à une autre en fonction des besoins.

Si une application ne peut pas traiter une requête entrante parce qu’elle attend une réponse DDE, elle doit éviter l’interblocage en publiant un message WM_DDE_ACK avec le membre fBusy de la structure DDEACK défini sur 1. Une application peut également envoyer un message WM_DDE_ACK occupé si, pour une raison quelconque, elle ne peut pas traiter une demande entrante dans un délai raisonnable.

Une application doit être en mesure de gérer l’échec d’un client ou d’un serveur à répondre à un message dans un délai donné. Étant donné que l’intervalle de délai d’attente peut varier en fonction de la nature de l’application et de la configuration du système de l’utilisateur (y compris s’il est connecté à un réseau), l’application doit permettre à l’utilisateur de spécifier l’intervalle.

Fonctions d’empaquetage de paramètres

Le paramètre lParam de nombreux messages DDE contient deux éléments de données. Par exemple, le lParam du message WM_DDE_DATA contient un handle de données et un atome. Les applications doivent utiliser la fonction PackDDElParam pour emballer le handle et l’atome dans un paramètre lParam , et la fonction UnpackDDElParam pour supprimer les valeurs. Les applications DDE doivent utiliser PackDDElParam et UnpackDDElParam pour tous les messages publiés pendant une conversation DDE.

Les applications peuvent également utiliser les fonctions ReuseDDElParam et FreeDDElParam . ReuseDDElParam permet à une application DDE de réutiliser un paramètre lParam packed, ce qui permet de réduire le nombre de réaffectations de mémoire que l’application doit effectuer pendant une conversation. Une application peut utiliser FreeDDElParam pour libérer la mémoire associée à un handle de données reçu pendant une conversation DDE.

Échange de données dynamiques et emprunt d’identité

Pour permettre à un serveur d’emprunter l’identité d’un client, le client appelle la fonction DdeSetQualityOfService . La structure SECURITY_IMPERSONATION_LEVEL est utilisée pour contrôler le niveau d’emprunt d’identité que le serveur peut effectuer.

Un serveur DDE peut emprunter l’identité d’un client DDE en appelant la fonction ImpersonateDdeClientWindow . Un serveur DDEML doit utiliser la fonction DdeImpersonateClient .