Interazione tra i gestori eventi

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

Gestori eventi associati

A ogni gestore dell'evento Will è associato un gestore eventi Complete. Ad esempio, quando l'applicazione modifica il valore di un campo, viene chiamato il gestore dell'evento 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 è stato completato 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 procedura.

In alcuni casi un'operazione può generare più di un evento. Ad esempio, l'oggetto Recordset include eventi associati per le modifiche di campo e le modifiche dei record. Quando l'applicazione modifica il valore di un campo, viene chiamato il gestore dell'evento WillChangeField. Se determina che l'operazione può continuare, viene generato anche il gestore dell'evento WillChangeRecord. Se questo gestore consente anche la continuazione dell'evento, la modifica viene apportata e vengono chiamati i gestori eventi FieldChangeComplete e RecordChangeComplete. L'ordine in cui vengono chiamati i gestori eventi Will per una determinata operazione non è definito, pertanto è consigliabile evitare di scrivere codice che dipende dalla chiamata dei gestori 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 campo, in genere vengono chiamati entrambi i gestori eventi WillChangeField e WillChangeRecord. Tuttavia, se l'operazione viene annullata nel primo gestore eventi, il gestore complete associato viene chiamato immediatamente con adStatusOperationCancelled. Il secondo gestore non viene mai chiamato. Se, tuttavia, il primo gestore eventi consente all'evento di procedere, verrà chiamato l'altro gestore eventi. Se quindi annulla l'operazione, entrambi gli eventi Complete verranno chiamati come negli esempi precedenti.

Gestori eventi non associato

Se lo stato passato all'evento non è adStatusCantDeny, è possibile disattivare le notifiche degli eventi per qualsiasi evento restituisce adStatusUnwantedEvent nel parametro Status. Ad esempio, quando il gestore eventi Complete viene chiamato la prima volta, è possibile restituire adStatusUnwantedEvent. Successivamente si riceveranno solo gli 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 interromperà la ricezione di notifiche per tale evento solo quando si verificano per quel particolare motivo. In altre parole, si riceverà potenzialmente una notifica per ogni possibile motivo per cui l'evento potrebbe essere attivato.

I gestori eventi a singola will possono essere utili quando si vogliono esaminare i parametri che verranno usati in un'operazione. È possibile modificare i parametri dell'operazione o annullare l'operazione.

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

I gestori eventi Single Complete possono essere utili per la gestione delle operazioni asincrone. Ogni operazione asincrona ha 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 Recordset.Open(...,adAsyncExecute) un'operazione e continuare con altre elaborazioni. Alla fine si riceverà una notifica quando l'oggetto Recordset viene popolato da un evento ExecuteComplete.

Gestori eventi singoli e più oggetti

La flessibilità di un linguaggio di programmazione come Microsoft Visual C++® consente di avere un gestore eventi che elabora gli eventi da più oggetti. Ad esempio, è possibile avere un gestore eventi Disconnect per elaborare gli eventi da diversi oggetti Connection. Se una delle connessioni è terminata, viene chiamato il gestore dell'evento Disconnect. È possibile stabilire quale connessione ha causato l'evento perché il parametro dell'oggetto gestore eventi sarebbe stato impostato sull'oggetto Connection corrispondente.

Nota

Questa tecnica non può essere usata in Visual Basic perché tale linguaggio può correlare un solo oggetto a un gestore eventi.

Vedere anche

Riepilogo del gestore eventi ADO
Creazione di istanze di eventi ADO per linguaggio
Parametri dell'evento
Tipi di eventi