Fonctions asynchrones définies par l’utilisateur
S’applique à: Excel 2013 | Office 2013 | Visual Studio
Microsoft Excel 2013 pouvez appeler des fonctions définies par l’utilisateur de manière asynchrone. L’appel asynchrone de fonctions peut améliorer les performances en autorisant l’exécution de plusieurs calculs en même temps. Lorsque vous exécutez des fonctions définies par l’utilisateur sur un cluster de calcul, le fait d’appeler les fonctions de manière asynchrone permet de pouvoir utiliser plusieurs ordinateurs pour effectuer les calculs.
Quand utiliser des fonctions asynchrones définies par l’utilisateur
Certaines fonctions définies par l’utilisateur doivent attendre des ressources externes. Pendant qu’ils attendent, le thread de calcul Excel est bloqué. Dans Excel 2013, les fonctions définies par l’utilisateur peuvent s’exécuter de manière asynchrone. Cela permet au thread de calcul d’exécuter d’autres calculs pendant que la fonction définie par l’utilisateur attend.
Dans Excel 2007, les programmeurs pouvaient exécuter plusieurs fonctions définies par l’utilisateur en même temps en augmentant le nombre de threads utilisés dans les recalculs de plusieurs threads. Cette méthode présente des inconvénients principalement parce que le nombre de threads est un paramètre limité à une application et ne peut pas être contrôlé au niveau d’une seule fonction ou d’un complément.
Les programmeurs doivent utiliser des appels de fonction définis par l’utilisateur asynchrones lorsque la fonction doit attendre des ressources externes. Par exemple, une fonction qui envoie une requête SOAP sur Internet doit attendre que le réseau envoie la requête, que le serveur distant termine la requête et que le réseau retourne le résultat. Dans ce cas, il n’y a pas de calcul significatif et Excel peut continuer avec d’autres calculs.
Les programmeurs peuvent également utiliser des fonctions asynchrones définies par l’utilisateur lorsqu’une fonction envoie des requêtes à un cluster de calcul. Dans ce cas, il n’y a pas que la latence du réseau à attendre, mais le cluster peut exécuter des appels distincts sur des serveurs distincts. En n’attendant pas la fin de chaque appel, les appels peuvent se chevaucher pour améliorer les performances. Dans certains cas, cette amélioration est significative.
Remarque
Les fonctions définies par l’utilisateur ne peuvent pas être inscrites en tant qu’asynchrones et sécurisées pour le cluster.
Écriture d’une fonction asynchrone définie par l’utilisateur
Les fonctions asynchrones définies par l’utilisateur doivent effectuer le suivi d’un handle et utiliser ce handle pour informer Excel que l’appel de fonction est terminé. Une fonction asynchrone définie par l’utilisateur est divisée en deux parties. Le premier élément est le point d’entrée UDF standard, qui lancera une deuxième opération asynchrone distincte. Les rappels dans Excel doivent être effectués pendant le point d’entrée UDF. La première partie de lancement de la fonction retourne ensuite le contrôle de son thread de calcul à Excel, qui poursuit le calcul. Une fois la deuxième opération asynchrone terminée, elle doit rappeler Excel et fournir son résultat à Excel.
Remarque
Tous les arguments passés dans la fonction définie par l’utilisateur nécessaires à la partie asynchrone de la fonction doivent être copiés en profondeur, car Excel libère ces arguments lorsque le point d’entrée de la fonction définie par l’utilisateur est retourné.
Excel fournit un ensemble d’événements qu’un complément XLL peut utiliser pour gérer le cycle de vie des appels UDF asynchrones. Ces événements indiquent qu’Excel a terminé les calculs ou que le calcul a été annulé.
Déclaration d’une fonction asynchrone
Vous devez déclarer les fonctions asynchrones définies par l’utilisateur comme asynchrones lorsqu’elles sont inscrites. Pour ce faire, ajoutez un paramètre qui pointe vers une structure XLOPER12, représentée par « X » dans la chaîne de type d’inscription, n’importe où dans la liste des paramètres UDF. Excel utilise ce paramètre pour passer le handle d’appel asynchrone. Le complément XLL doit transmettre le handle d’appel asynchrone et le résultat de la fonction à Excel lorsque le résultat est prêt. En outre, le type de retour de la fonction définie par l’utilisateur doit être void, désigné par «> » comme premier caractère de la chaîne de type. Le type de retour est void, car la partie synchrone de la fonction définie par l’utilisateur ne retourne pas de valeur à Excel. Au lieu de cela, le complément XLL retourne une valeur de façon asynchrone via un rappel.
Vous pouvez déclarer des fonctions asynchrones comme thread-safe, puis la partie synchrone de la fonction définie par l’utilisateur est utilisée dans un recalcul multithread.
L’exemple de code suivant montre une fonction asynchrone définie par l’utilisateur inscrite à l’aide de «> QX » comme chaîne de type d’inscription :
void MyAsyncUDF(LPXLOPER12 arg1, LPXLOPER12 pxAsyncHandle)
{
…
}
Retour de valeurs
Lorsque le résultat de l’appel asynchrone est prêt, le complément XLL retourne le résultat à Excel en effectuant un rappel de type xlAsyncReturn.
xlAsyncReturn est le seul rappel que vous pouvez utiliser sur des threads sans calcul pendant le recalcul. Par conséquent, la partie asynchrone d’une fonction définie par l’utilisateur asynchrone ne doit pas effectuer d’autres rappels.
Traitement des événements
À compter d’Excel 2010, les XLL peuvent recevoir des événements conçus pour gérer le cycle de vie des fonctions asynchrones. Pour plus d’informations, consultez Gestion des événements.