Cómo funcionan conjuntamente los controladores de eventos

A menos que esté programando en Visual Basic, deben implementarse todos los controladores de eventos para los eventos Connection y Recordset, independientemente de si realmente procesa todos los eventos. La cantidad de trabajo de implementación que debe hacer depende del lenguaje de programación. Para más información, consulte Creación de instancias de eventos de ADO según el idioma.

Controladores de eventos emparejados

Cada controlador de eventos Will tiene asociado un controlador de eventos Complete. Por ejemplo, cuando la aplicación cambia el valor de un campo, se llama al controlador de eventos WillChangeField. Si el cambio es aceptable, la aplicación deja el parámetro adStatus sin cambios y se realiza la operación. Cuando se completa la operación, un evento FieldChangeComplete notifica a la aplicación que la operación ha finalizado. Si se completó correctamente, adStatus contiene adStatusOK, de lo contrario, adStatus contiene adStatusErrorsOccurred y debe comprobar el objeto Error para determinar la causa del error.

Cuando se llama a WillChangeField, es posible que determine que no se debe hacer el cambio. En ese caso, establezca adStatus en adStatusCancel. La operación se cancela y el evento FieldChangeComplete recibe un valor adStatus de adStatusErrorsOccurred. El objeto Error contiene adErrOperationCancelled para que el controlador FieldChangeComplete sepa que se canceló la operación. Sin embargo, debe comprobar el valor del parámetro adStatus antes de cambiarlo, ya que establecer adStatus en adStatusCancel no tiene ningún efecto si el parámetro se estableció en adStatusCantDeny en la entrada en el procedimiento.

A veces, una operación puede generar más de un evento. Por ejemplo, el objeto Recordset tiene eventos emparejados para cambios de Field y cambios de Record. Cuando la aplicación cambia el valor de un Field, se llama al controlador de eventos WillChangeField. Si determina que la operación puede continuar, también se genera el controlador de eventos WillChangeRecord. Si este controlador también permite que el evento continúe, se hace el cambio y se llama a los controladores de eventos FieldChangeComplete y RecordChangeComplete. No está definido el orden en que se llama a los controladores de eventos Will para una operación determinada, por lo que debe evitar escribir código que dependa de los controladores de llamada en una secuencia determinada.

En los casos en los que se generan varios eventos Will, uno de los eventos podría cancelar la operación pendiente. Por ejemplo, cuando la aplicación cambia el valor de un Field, normalmente se llamaría a los controladores de eventos WillChangeField y WillChangeRecord. Sin embargo, si la operación se cancela en el primer controlador de eventos, se llama inmediatamente a su controlador Complete asociado a adStatusOperationCancelled. Nunca se llama al segundo controlador. Sin embargo, si el primer controlador de eventos permite que el evento continúe, se llamará al otro controlador de eventos. Si después este cancela la operación, se llamará a ambos eventos Complete como en los ejemplos anteriores.

Controladores de eventos no emparejados

Siempre que el estado enviado al evento no sea adStatusCantDeny, puede desactivar las notificaciones de eventos para cualquier evento mediante la devolución de adStatusUnwantedEvent en el parámetro Status. Por ejemplo, cuando se llama al controlador de eventos Complete la primera vez, se puede devolver adStatusUnwantedEvent. Posteriormente recibirá solo eventos Will. Sin embargo, algunos eventos se pueden desencadenar por más de un motivo. En ese caso, el evento tendrá un parámetro Reason. Cuando devuelva adStatusUnwantedEvent, dejará de recibir notificaciones de ese evento solo cuando se produzcan por ese motivo concreto. En otras palabras, recibirá una notificación por cada posible motivo por el que se podría desencadenar el evento.

Los controladores de eventos Will únicos pueden ser útiles cuando quiera examinar los parámetros que se usarán en una operación. Puede modificar esos parámetros de operación o cancelar la operación.

Como alternativa, deje habilitada la notificación de eventos Completa. Al llamar al primer controlador de eventos Will, devuelva adStatusUnwantedEvent. Posteriormente recibirá solo eventos Complete.

Los controladores de eventos Complete únicos pueden ser útiles para administrar operaciones asincrónicas. Cada operación asincrónica tiene un evento Complete adecuado.

Por ejemplo, puede tardar mucho tiempo en rellenar un objeto Recordset grande. Si la aplicación se escribe correctamente, puede iniciar una operación Recordset.Open(...,adAsyncExecute) y continuar con otro procesamiento. Finalmente se le notificará cuando un evento ExecuteComplete rellene el objeto Recordset.

Controladores de eventos únicos y varios objetos

La flexibilidad de un lenguaje de programación como Visual C++ permite hacer que un controlador de eventos procese eventos de varios objetos. Por ejemplo, podría hacer que un controlador de eventos Disconnect procese eventos de varios objetos Connection. Si una de las conexiones finaliza, se llamaría al controlador de eventos Disconnect. Se podría saber qué conexión provocó el evento, porque el parámetro del objeto del controlador de eventos se establecería en el objeto Connection correspondiente.

Nota:

Esta técnica no se puede usar en Visual Basic porque ese lenguaje solo puede correlacionar un objeto con un controlador de eventos.

Consulte también

Conexión ADO y los eventos de conjunto de registros
Creación de instancias de eventos de ADO según el lenguaje
Parámetros de eventos
Tipos de eventos