WinAsyncAPPC
La fonction WinAsyncAPPC fournit un point d’entrée asynchrone pour tous les verbes APPC. Utilisez cette fonction au lieu des versions bloquantes des verbes si vous exécutez votre application et que vous souhaitez utiliser la publication de messages à l’aide de handles Windows pour la saisie semi-automatique asynchrone des verbes.
Syntaxe
HANDLE WINAPI WinAsyncAPPC(
HANDLE hWnd,
Long lpVcb
);
Paramètres
hWnd
Handle de fenêtre qui sera utilisé pour la publication de messages afin de notifier une application lorsqu’un verbe APPC se termine.
lpVcb
Pointeur vers le bloc de contrôle de verbe.
Valeur renvoyée
La valeur de retour spécifie si la requête asynchrone a réussi. Si la fonction a réussi, la valeur de retour est un handle de tâche asynchrone. Si la fonction n’a pas réussi, un zéro est retourné.
Lorsque cette fonction retourne avec une valeur réussie, cela n’indique pas que l’appel APPC sera finalement retourné avec succès. Il indique uniquement qu’il était possible pour la bibliothèque APPC de tenter l’appel APPC de manière asynchrone à l’aide de la publication de messages pour la notification.
Remarques
Pour obtenir un exemple d’utilisation de ce verbe dans les programmes transactionnels ( TPs), consultez l’exemple d’envoi et de réception de TP (SENDRECV. C situé dans le dossier APPC) inclus dans le Kit de développement logiciel (SDK).
Les verbes APPC utilisés dans les conversations de base qui peuvent être bloqués sont les suivants :
-
Les verbes APPC utilisés dans les conversations mappées qui peuvent être bloquées sont les suivants :
-
Lorsque vous utilisez les versions synchrones ou asynchrones d’un verbe, une application ne peut avoir qu’une seule fonction en cours sur une conversation à la fois. Une tentative de lancement d’une deuxième fonction entraîne le code d’erreur AP_CONV_BUSY.
Les exceptions au paragraphe précédent sont les suivantes :
-
Pour permettre l’utilisation complète de la prise en charge asynchrone, les verbes RECEIVE_AND_WAIT et MC_RECEIVE_AND_WAIT émis de manière asynchrone ont été modifiés pour agir comme les verbes RECEIVE_AND_POST et MC_RECEIVE_AND_POST . Plus précisément, bien qu’une version asynchrone de l’un de ces verbes soit en suspens, les verbes suivants peuvent être émis sur la même conversation :
LIBÉRER (AP_ABEND_PROG, AP_ABEND_SVC ou AP_ABEND_TIMER)
-
Cela permet à une application, en particulier à un émulateur 5250, d’utiliser un RECEIVE_AND_WAIT asynchrone ou un MC_RECEIVE_AND_WAIT pour recevoir des données. Bien que le RECEIVE_AND_POST, MC_RECEIVE_AND_POST, RECEIVE_AND_WAIT ou MC_RECEIVE_AND_WAIT soit exceptionnel, il peut toujours utiliser SEND_ERROR ou MC_SEND_ERROR et REQUEST_TO_SEND ou MC_REQUEST_TO_SEND. Il est recommandé d’utiliser cette fonctionnalité pour une prise en charge asynchrone complète.
Une fois l’opération asynchrone terminée, la fenêtre de l’application hWnd reçoit le message retourné par RegisterWindowMessage avec « WinAsyncAPPC » comme chaîne d’entrée. L’argument wParam contient le handle de tâche asynchrone retourné par l’appel de fonction d’origine. L’argument lParam contient le pointeur VCB d’origine et peut être déréférencé pour déterminer le code de retour final.
Dans le cadre de la définition Windows APPC, WinAPPCCancelAsyncRequest permet à une application d’annuler toute action APPC asynchrone ; mais met fin à la conversation ou tp associée selon le cas. Toutes les opérations en attente retournent avec AP_CANCELED comme code de retour.
Si la fonction retourne correctement, un message WinAsyncAPPC est publié dans l’application lorsque l’opération se termine ou que la conversation est annulée.