Cómo funcionan juntos los controladores de eventos

A menos que esté programando en Visual Basic, todos los controladores de eventos para Connection y Conjunto de registros deben implementarse, independientemente de si realmente procesa todos los eventos. La cantidad de trabajo de implementación que tiene que hacer depende del lenguaje de programación. Para obtener más información, vea Creación de instancias de eventos de ADO por lenguaje.

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. Una vez completada 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 revisar el objeto Error para determinar la causa del error.

Cuando se llama a WillChangeField, puede determinar que no se debe realizar el cambio. En ese caso, establezca adStatus en adStatusCancel. La operación se cancela y el evento FieldChangeComplete recibe un valor de adStatus de adStatusErrorsOccurred. El objeto de 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 al escribir en el procedimiento.

A veces, una operación puede generar más de un evento. Por ejemplo, el objeto Recordset tiene eventos pareados para cambios en el campo y cambios en el registro. Cuando su 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 realiza el cambio y se llama a los controladores de eventos FieldChangeComplete y RecordChangeComplete. Para una operación determinada, el orden en que se llaman los controladores de eventos Will no está definido, por lo que se debe evitar escribir código que dependa de llamarlos en una secuencia específica.

En casos en los que se generan varios eventos Will, uno de los eventos podría cancelar la operación pendiente. Por ejemplo, cuando tu aplicación cambia el valor de un Field, normalmente se llamarían ambos 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 de complete asociado con 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 cancela la operación, se llamarán ambos eventos Complete, tal como en los ejemplos anteriores.

Controladores de eventos no emparejados

Siempre que el estado pasado al evento no sea adStatusCantDeny, puede desactivar las notificaciones para cualquier evento devolviendo adStatusUnwantedEvent en el parámetro Status. Por ejemplo, cuando el controlador de eventos Complete se llama la primera vez, 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, solo dejará de recibir notificaciones para ese evento cuando se produzcan por ese motivo concreto. En otras palabras, recibirá una notificación por cada posible razón por la que se pueda desencadenar el evento.

El único controlador de eventos puede ser útil 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 notificación de eventos Complete. Cuando se llama al primer controlador de eventos Will, devuelva adStatusUnwantedEvent. Posteriormente, recibirá solo eventos complete.

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

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

Controladores de eventos individuales y múltiples objetos

La flexibilidad de un lenguaje de programación como Visual C++ le permite tener un controlador de eventos procesa eventos de varios objetos. Por ejemplo, podría tener un controlador de eventos de Desconexión que procese eventos de varios objetos de Conexión. Si una de las conexiones finalizó, se llamaría al controlador de eventos Desconectar. Podría indicar qué conexión provocó el evento porque el parámetro de 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

Resumen del Controlador de Eventos de ADO
creación de instancias de eventos de ADO por language
Parámetros de evento
Tipos de eventos