Interazione tra i gestori eventi

A meno che non si stia programmando in Visual Basic, tutti i gestori degli eventi per gli eventi Connection e Recordset devono essere implementati, indipendentemente dal fatto che tutti gli eventi vengano effettivamente elaborati. La quantità di lavoro di implementazione da eseguire dipende dal linguaggio di programmazione. Per altre informazioni, vedere Creazione di istanze di eventi ADO per linguaggio.

Gestori degli eventi abbinati

Ad ogni gestore eventi Will è associato un gestore eventi Complete. Ad esempio, quando l'applicazione modifica il valore di un campo, viene chiamato il gestore eventi WillChangeField. Se la modifica è accettabile, l'applicazione lascia invariato il parametro adStatus e viene eseguita l'operazione. Al termine dell'operazione, un evento FieldChangeComplete notifica all'applicazione che l'operazione è stata completata. Se l'operazione è stata completata correttamente, adStatus contiene adStatusOK. In caso contrario, adStatus contiene adStatusErrorsOccurred ed è necessario controllare l'oggetto Error per determinare la causa dell'errore.

Quando viene chiamato WillChangeField, è possibile determinare che la modifica non deve essere apportata. In tal caso, impostare adStatus su adStatusCancel. L'operazione viene annullata e l'evento FieldChangeComplete riceve un valore adStatus di adStatusErrorsOccurred. L'oggetto Error contiene adErrOperationCancelled in modo che il gestore FieldChangeComplete sappia che l'operazione è stata annullata. Tuttavia, è necessario controllare il valore del parametro adStatus prima di modificarlo, perché l'impostazione di adStatus su adStatusCancel non ha alcun effetto se il parametro è stato impostato su adStatusCantDeny nella voce della routine.

In alcuni casi un'operazione può generare più di un evento. Ad esempio, l'oggetto Recordset ha eventi associati per le modifiche di Field e le modifiche di Record. Quando l'applicazione modifica il valore di un Campo, viene chiamato il gestore eventi WillChangeField. Se determina che l'operazione può continuare, viene generato anche il gestore eventi WillChangeRecord. Se anche questo gestore consente la continuazione dell'evento, la modifica viene eseguita e vengono chiamati i gestori degli eventi FieldChangeComplete e RecordChangeComplete. L'ordine in cui vengono chiamati i gestori degli eventi Will per un'operazione specifica non è definito, pertanto è consigliabile evitare di scrivere codice che dipende dai gestori chiamanti in una sequenza specifica.

Nei casi in cui vengono generati più eventi Will, uno degli eventi potrebbe annullare l'operazione in sospeso. Ad esempio, quando l'applicazione modifica il valore di un oggetto Field, normalmente vengono chiamati i gestori degli eventi WillChangeField e WillChangeRecord. Tuttavia, se l'operazione viene annullata nel primo gestore degli eventi, il gestore Complete associato viene chiamato immediatamente con adStatusOperationCancelled. Il secondo gestore non viene mai chiamato. Se, tuttavia, il primo gestore degli eventi consente l'esecuzione dell'evento, verrà chiamato l'altro gestore degli eventi. Se quindi annulla l'operazione, entrambi gli eventi Complete verranno chiamati come negli esempi precedenti.

Gestori degli eventi non abbinati

Fino a quando lo stato passato all'evento non è adStatusCantDeny, puoi disattivare le notifiche degli eventi per qualsiasi evento restituendo adStatusUnwantedEvent nel parametro Status. Ad esempio, quando il gestore degli eventi Complete viene chiamato la prima volta, è possibile restituire adStatusUnwantedEvent. Successivamente si riceveranno solo eventi Will. Tuttavia, alcuni eventi possono essere attivati per più di un motivo. In tal caso, l'evento avrà un parametro Reason. Quando si restituisce adStatusUnwantedEvent, si smetterà di ricevere notifiche per tale evento solo quando si verifica per quel motivo specifico. In altre parole, si riceverà una notifica per ogni possibile motivo per cui l'evento potrebbe essere attivato.

I singoli gestori degli eventi Will possono essere utili quando si vuole esaminare i parametri che verranno usati in un'operazione. È possibile modificare tali parametri dell'operazione o annullare l'operazione.

In alternativa, lasciare abilitata la notifica dell'evento Complete. Quando viene chiamato il primo gestore degli eventi Will, restituire adStatusUnwantedEvent. Successivamente si riceveranno solo eventi Complete.

I singoli gestori degli eventi Complete possono essere utili per la gestione delle operazioni asincrone. Ogni operazione asincrona prevede un evento Complete appropriato.

Ad esempio, il popolamento di un oggetto Recordset di grandi dimensioni può richiedere molto tempo. Se l'applicazione è scritta in modo appropriato, è possibile avviare un'operazione Recordset.Open(...,adAsyncExecute) e continuare con altre elaborazioni. Alla fine si riceverà una notifica quando l'oggetto Recordset viene popolato da un evento ExecuteComplete.

Gestori degli eventi singoli e oggetti multipli

La flessibilità di un linguaggio di programmazione come Visual C++ consente di disporre di un solo gestore eventi che elabora gli eventi da più oggetti. Ad esempio, è possibile avere un unico gestore degli eventi Disconnect che elabora gli eventi da diversi oggetti Connection. Se una delle connessioni è terminata, verrà chiamato il gestore degli eventi Disconnect. È possibile indicare quale connessione ha causato l'evento perché il parametro dell'oggetto gestore degli eventi verrebbe impostato sull'oggetto Connection corrispondente.

Nota

Non è possibile usare questa tecnica in Visual Basic, perché tale linguaggio può correlare un solo oggetto a un gestore degli eventi.

Vedi anche

Riepilogo dei gestori eventi ADO
Creazione di istanze evento ADO per linguaggio
Parametri evento
Tipi di eventi