Fonctionnement conjoint des gestionnaires d’événements

À moins que vous ne programmiez en Visual Basic, tous les gestionnaires d'événements pour les événements Connection et Recordset doivent être mis en œuvre, que vous traitiez ou non tous les événements. La quantité de travail d’implémentation que vous devez faire dépend de votre langage de programmation. Pour plus d’informations, consultez Instanciation des événements ADO par langue.

Gestionnaires d’événements jumelés

Chaque gestionnaire d’événements Will a un gestionnaire d’événements Complete associé. Par exemple, lorsque votre application modifie la valeur d’un champ, le gestionnaire d’événements WillChangeField est appelé. Si la modification est acceptable, votre application laisse le paramètre adStatus inchangé et l’opération est effectuée. Une fois l’opération terminée, un événement FieldChangeComplete informe votre application que l’opération a terminé. S’il est terminé avec succès, adStatus contient adStatusOK ; sinon, adStatus contient adStatusErrorsOccurred et vous devez vérifier l’objet Error pour déterminer la cause de l’erreur.

Lorsque WillChangeField est appelé, vous pouvez déterminer que la modification ne doit pas être apportée. Dans ce cas, définissez adStatus sur adStatusCancel. L’opération est annulée et l’événement FieldChangeComplete reçoit une valeur adStatus d’adStatusErrorsOccurred. L’objet Error contient adErrOperationCancelled afin que votre gestionnaire FieldChangeComplete sache que l’opération a été annulée. Toutefois, vous devez vérifier la valeur du paramètre adStatus avant de le modifier, car le fait de définir adStatus sur adStatusCancel n'a aucun effet si le paramètre était défini sur adStatusCantDeny à l'entrée de la procédure.

Parfois, une opération peut déclencher plusieurs événements. Par exemple, l’objet Recordset a associé des événements pour les modifications de Field et les modifications de Record. Lorsque votre application change la valeur d’un champ, le gestionnaire d’événements WillChangeField est appelé. S’il détermine que l’opération peut continuer, le gestionnaire d’événements WillChangeRecord est également déclenché. Si ce gestionnaire permet également à l’événement de continuer, la modification est apportée et les gestionnaires d’événements FieldChangeComplete et RecordChangeComplete sont appelés. L’ordre dans lequel les gestionnaires d’événements Will pour une opération particulière sont appelés n’est pas défini. Vous devez donc éviter d’écrire du code qui dépend des gestionnaires appelants dans une séquence particulière.

Dans les cas où plusieurs événements Will sont déclenchés, l’un des événements peut annuler l’opération en attente. Par exemple, lorsque votre application modifie la valeur d’un champ, les gestionnaires d’événements WillChangeField et WillChangeRecord sont normalement appelés. Toutefois, si l’opération est annulée dans le premier gestionnaire d’événements, son gestionnaire Complete associé est immédiatement appelé avec adStatusOperationCancelled. Le deuxième gestionnaire n’est jamais appelé. Toutefois, le premier gestionnaire d’événements permet à l’événement de continuer, l’autre gestionnaire d’événements est appelé. S’il annule ensuite l’opération, les deux événements Complete sont appelés comme dans les exemples précédents.

Gestionnaires d’événements non jumelés

Tant que l’état passé à l’événement n’est pas adStatusCantDeny, vous pouvez désactiver les notifications d’événements pour n’importe quel événement en retournant adStatusUnwantedEvent dans le paramètre Status. Par exemple, lorsque votre gestionnaire d’événements Complete est appelé la première fois, vous pouvez renvoyer adStatusUnwantedEvent. Vous recevrez ensuite uniquement les événements Will. Toutefois, certains événements peuvent être déclenchés pour plusieurs raisons. Dans ce cas, l’événement aura un paramètre Reason. Lorsque vous retournez adStatusUnwantedEvent, vous cesserez de recevoir des notifications pour cet événement uniquement lorsqu’ils se produisent pour cette raison particulière. En d’autres termes, vous recevrez potentiellement une notification pour chaque raison possible que l’événement peut être déclenché.

Les gestionnaires d’événements uniques Will peuvent être utiles lorsque vous souhaitez examiner les paramètres qui seront utilisés dans une opération. Vous pouvez modifier ces paramètres d’opération ou annuler l’opération.

Vous pouvez également laisser la notification d’événement Complete activée. Lorsque votre premier gestionnaire d’événements Will est appelé, retournez adStatusUnwantedEvent. Vous recevrez ensuite uniquement les événements Complete.

Les gestionnaires d’événements uniques Complete peuvent être utiles pour la gestion des opérations asynchrones. Chaque opération asynchrone a un événement Complete approprié.

Par exemple, il peut prendre beaucoup de temps pour remplir un objet Recordset volumineux. Si votre application est correctement écrite, vous pouvez démarrer une opération Recordset.Open(...,adAsyncExecute) et continuer avec d’autres traitements. Vous serez finalement averti lorsque l’objet Recordset est rempli par un événement ExecuteComplete.

Gestionnaires d’événements uniques et objets multiples

La flexibilité d’un langage de programmation comme Visual C++ vous permet d’avoir un seul processus de traitement de gestionnaire d’événements à partir de plusieurs objets. Par exemple, vous pouvez avoir un gestionnaire d’événements Disconnect les événements de processus à partir de plusieurs objets Connection. Si l’une des connexions s’est terminée, le gestionnaire d’événements Disconnect est appelé. Vous pouvez indiquer quelle connexion a provoqué l’événement, car le paramètre d’objet du gestionnaire d’événements est défini sur l’objet Connection correspondant.

Remarque

Cette technique ne peut pas être utilisée dans Visual Basic, car ce langage ne peut mettre en corrélation qu’un seul objet à un gestionnaire d’événements.

Voir aussi

Présentation rapide du gestionnaire d’événements ADO
Instanciation des événements ADO par langage
Paramètres des événements
Types d’événements