Fonctionnement des gestionnaires d’événements

Sauf si vous programmez en Visual Basic, tous les gestionnaires d’événements pour Connection et Recordset événements doivent être implémentés, que vous traitez réellement 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 d’événements ADO par langue.

Gestionnaires d’événements associé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 quitte 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 s’est terminé correctement, 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 de 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 paramètre adStatus sur adStatusCancel n’a aucun effet si le paramètre a été défini sur adStatusCantDeny lors de l’entrée à la procédure.

Parfois, une opération peut déclencher plusieurs événements. Par exemple, l'objet Recordset a des événements associés pour les modifications de Field et les modifications de Record. Lorsque votre application modifie la valeur d'un champ , le gestionnaire d'événements WillChangeField est appelé. Si elle 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 effectué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 Field, 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é. Si, toutefois, le premier gestionnaire d’événements permet à l’événement de continuer, l’autre gestionnaire d’événements est appelé. Si elle annule ensuite l'opération, les deux événements Complets seront appelés comme cela est montré dans les exemples précédents.

Gestionnaires d’événements non appariés

Tant que l’état transmis à l’événement n’est pas adStatusCantDeny, vous pouvez désactiver les notifications pour n’importe quel événement en renvoyant adStatusUnwantedEvent dans le paramètre Status. Par exemple, lorsque votre gestionnaire d’événements Complete est appelé la première fois, vous pouvez retourner adStatusUnwantedEvent. Vous recevrez par la suite 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'elles se produisent pour cette raison particulière. En d’autres termes, vous recevrez potentiellement une notification pour chaque raison possible de déclencher l’événement.

Un gestionnaire d'événements unique Will peut être utile lorsque vous souhaitez examiner les paramètres utilisés pour une opération. Vous pouvez modifier ces paramètres d’opération ou annuler l’opération.

Vous pouvez également laisser terminer notification d’événement activée. Lorsque votre premier gestionnaire d’événements Will est appelé, retournez adStatusUnwantedEvent. Par la suite, vous ne recevrez que des événements complets .

Les gestionnaires d’événements complets peuvent être utiles pour gérer les opérations asynchrones. Chaque opération asynchrone a un événement Complete approprié.

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

Gestionnaires d’événements simples et objets multiples

La flexibilité d’un langage de programmation tel que Visual C++ vous permet d’avoir un seul gestionnaire d’événements pour traiter des événements provenant de plusieurs objets. Par exemple, vous pouvez avoir un gestionnaire d'événements Déconnecter qui traite des événements provenant de plusieurs objets Connexion. Si l’une des connexions s’est terminée, le gestionnaire d’événements Disconnect serait 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.

Note

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

Voir aussi

Résumé de la gestion d'événements ADO
Instanciation d'événements ADO par langage
paramètres d’événement
types d’événements