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 souhaitez utiliser la publication de messages à l’aide de handles Windows pour la saisie semi-automatique des verbes asynchrones.

Syntaxe

  
HANDLE WINAPI WinAsyncAPPC(   
HANDLE hWnd,  
Long lpVcb  
);  

Paramètres

hWnd
Handle de fenêtre qui sera utilisé pour la publication de messages pour 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 demande 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 est retournée avec une valeur réussie, cela n’indique pas que l’appel APPC retourne finalement 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.

Notes

Pour obtenir un exemple d’utilisation de ce verbe dans les programmes transactionnels (TPS), consultez l’exemple TP d’envoi et de réception (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ées sont les suivants :

  • ALLOCATE

  • CONFIRMER

  • CONFIRMÉ

  • DEALLOCATE

  • RINCER

  • PREPARE_TO_RECEIVE

  • RECEIVE_ALLOCATE

  • RECEIVE_AND_WAIT

  • REQUEST_TO_SEND

  • SEND_CONVERSATION

  • SEND_DATA

  • SEND_ERROR

  • TP_ENDED

  • TP_STARTED

    Les verbes APPC utilisés dans les conversations mappées qui peuvent être bloquées sont les suivants :

  • MC_ALLOCATE

  • MC_CONFIRM

  • MC_CONFIRMED

  • MC_DEALLOCATE

  • MC_FLUSH

  • MC_PREPARE_TO_RECEIVE

  • MC_RECEIVE_AND_WAIT

  • MC_REQUEST_TO_SEND

  • MC_SEND_CONVERSATION

  • MC_SEND_DATA

  • MC_SEND_ERROR

    Lorsque vous utilisez les versions synchrones ou asynchrones d’un verbe, une application ne peut avoir qu’une seule fonction en cours en cours sur une conversation à la fois. Une tentative d’initialisation d’une deuxième fonction entraîne le code d’erreur AP_CONV_BUSY.

    Les exceptions au paragraphe précédent sont les suivantes :

  • RECEIVE_AND_POST

  • MC_RECEIVE_AND_POST

  • RECEIVE_AND_WAIT

  • MC_RECEIVE_AND_WAIT

    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, si une version asynchrone de l’un de ces verbes est 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)

  • GET_ATTRIBUTES ou MC_GET_ATTRIBUTES

  • GET_TYPE

  • REQUEST_TO_SEND ou MC_REQUEST_TO_SEND

  • SEND_ERROR ou MC_SEND_ERROR

  • TEST_RTS ou MC_TEST_RTS

  • TP_ENDED

    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érencement 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 au TP connexe selon les besoins. Toutes les opérations en attente retournent avec AP_CANCELED comme code de retour.

    Si la fonction est retournée avec succès, un message WinAsyncAPPC est publié sur l’application une fois l’opération terminée ou la conversation est annulée.