Considérations sur Windows CPI-C
Les appels CPI-C (Common Programming Interface for Communications) et les extensions Windows suivants sont d’une importance particulière. Vous devez les examiner avant d’utiliser Host Integration Server.
Notes
Les noms des appels sont des pseudonymes. Les noms de fonction C réels apparaissent entre parenthèses après le pseudonyme. Par exemple, Set_Processing_Mode est le pseudonyme d’un appel. Le nom réel de la fonction est cmspm.
Set_Processing_Mode( cmspm)
Spécifie pour la conversation si les appels suivants sont retournés lorsque l’opération qu’ils demandent est terminée (blocage) ou immédiatement après le lancement de l’opération (non bloquant). Un programme est averti de la fin des appels non bloquants lorsqu’il émet des Wait_For_Conversation ou via un message Windows envoyé à un WndProc identifié par hwndNotify dans Specify_Windows_Handle. Lorsque le mode de traitement est défini pour une conversation, il s’applique à tous les appels suivants sur la conversation jusqu’à ce que le mode soit à nouveau défini.
Specify_Windows_Handle( xchwnd)
Définit le handle de fenêtre auquel un message est envoyé à la fin d’une opération en mode non bloquant.
Wait_For_Conversation( cmwait)
Attend la fin d’une opération lancée lorsque la caractéristique de conversation en mode de traitement a été définie sur CM_NON_BLOCKING et que CM_OPERATION_INCOMPLETE a été retourné dans le paramètre return_code . Utilisez Wait_For_Conversation lors de l’exécution d’un thread d’arrière-plan ou d’une application monothread pour Microsoft Windows. Cela se produit probablement lors du portage du code à partir d’anciennes versions de Host Integration Server et de SNA Server.
Important
Une application peut définir le mode de traitement en appelant Set_Processing_Mode. Si le handle de fenêtre est défini sur NULL ou si cet appel n’est jamais émis, l’application doit appeler Wait_For_Conversation pour être avertie lorsque l’opération en suspens se termine.
Lorsqu’une opération asynchrone est terminée, la fenêtre d’applications hwndNotify reçoit le message retourné par RegisterWindowMessage avec « WinAsyncCPIC » comme chaîne d’entrée. La valeur wParam contient le code de retour de conversation de l’opération qui se termine. Ses valeurs dépendent de l’opération qui a été émise à l’origine. L’argument lParam contient le CM_PTR à l’identificateur de conversation spécifié dans l’appel de fonction d’origine.
WinCPICCleanup
Arrête et annule l’inscription d’une application à partir d’une implémentation Windows CPI-C.
Important
Cette fonction doit être appelée par une application lorsqu’elle a terminé pour annuler l’inscription de l’application à partir de l’implémentation Windows CPI-C.
WinCPICExtractEvent
Fournit une méthode permettant à une application de déterminer le handle d’événement utilisé pour une conversation CPI-C.
WinCPICIsBlocking
Détermine si une tâche s’exécute en attendant la fin d’un appel bloquant précédent. Il a été utilisé lors de la version 3 de Windows. x est allé dans un PeekMessageLoop tout en autorisant Windows à continuer. Bien qu’un appel émis sur une fonction de blocage apparaisse pour une application comme s’il se bloque, la bibliothèque de liens dynamiques (DLL) Windows CPI-C doit abandonner le processeur pour permettre à d’autres applications de s’exécuter. Cela signifie qu’il est possible que l’application qui a émis l’appel bloquant soit de nouveau entrée, en fonction des messages qu’elle reçoit. Dans cette instance, WinCPICIsBlocking peut être utilisé pour déterminer si la tâche d’application a été réinscrite en attendant la fin d’un appel bloquant en cours.
Cette extension est destinée à fournir de l’aide à une application écrite pour utiliser la CM_BLOCKING caractéristique de la fonction Specify_Processing_Mode Windows. WinCPICIsBlocking a le même objectif qu’InSendMessage dans l’API Windows.
Applications plus anciennes qui étaient initialement destinées à Windows version 3. x et qui prennent en charge plusieurs conversations doivent spécifier CM_NONBLOCKING dans Specify_Processing_Mode afin qu’ils puissent prendre en charge plusieurs opérations en attente simultanément. Les applications sont toujours limitées à une seule opération en suspens par conversation dans tous les environnements.
Notes
Windows CPI-C interdit plusieurs appels bloquants en cours par thread.
WinCPICSetBlockingHook
Permet à une implémentation Windows CPI-C de bloquer les appels de fonction CPI-C au moyen d’une nouvelle fonction. Les appels bloquants s’appliquent uniquement si vous n’utilisez pas d’appels asynchrones. Si une fonction doit bloquer, l’appel de blocage est appelé à plusieurs reprises jusqu’à ce que la demande d’origine se termine. Cela permet à Windows de continuer à s’exécuter pendant que l’application d’origine attend le retour de l’appel. Notez qu’à l’intérieur de l’appel bloquant, l’application peut être réinscrite. WinCPICSetBlockingHook a été utilisé par Windows version 3. x applications qui sont passées dans un PeekMessageLoop pour effectuer des appels bloquants sans bloquer le reste du système.
Notes
Par défaut, Windows Server n’entre pas dans un PeekMessageLoop. Au lieu de cela, ils bloquent un événement en attente de la fin de l’appel. La seule fois où vous avez besoin d’utiliser WinCPICSetBlockingHook pour Windows est lorsqu’une application à thread unique pour Windows partage le code source commun. Dans ce cas, vous devez explicitement effectuer cet appel. Comparez cet appel avec WinCPICIsBlocking et WinCPICUnhookBlockingHook.
WinCPICSetEvent
Associe un handle d’événement Win32 à une saisie semi-verbale.
WinCPICStartup
Permet à une application de spécifier la version de Windows CPI-C requise et de récupérer les détails de l’implémentation CPI-C spécifique.
Important
Une application doit appeler cette fonction pour s’inscrire auprès d’une implémentation Windows CPI-C avant d’émettre d’autres appels Windows CPI-C.
WinCPICUnhookBlockingHook
Supprime tout crochet de blocage précédent qui a été installé et réinstalle le mécanisme de blocage par défaut.