Interazione tra i gestori eventi

A meno che non si stia programmando in Visual Basic, tutti i gestori 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 eventi associati

Ogni gestore eventi Will ha un gestore eventi Complete associato. 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 adStatussu adStatusCancel. L'operazione viene annullata e l'evento FieldChangeComplete riceve un valore adStatus diadStatusErrorsOccurred. 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 record . Quando l'applicazione modifica il valore di un oggetto Field, viene chiamato il gestore eventi WillChangeField . Se determina che l'operazione può continuare, viene generato anche il gestore eventi WillChangeRecord . Se questo gestore consente anche la continuazione dell'evento, vengono chiamate le modifiche e vengono chiamati i gestori eventi FieldChangeComplete e RecordChangeComplete . L'ordine in cui i gestori eventi Will per una determinata operazione non vengono definiti, pertanto è consigliabile evitare di scrivere codice che dipende dai gestori chiamanti in una determinata sequenza.

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, i gestori eventi WillChangeField e WillChangeRecord vengono normalmente chiamati. Tuttavia, se l'operazione viene annullata nel primo gestore eventi, il gestore completo associato viene chiamato immediatamente con adStatusOperationCancelled. Il secondo gestore non viene mai chiamato. Se, tuttavia, il primo gestore eventi consente l'esecuzione dell'evento, verrà chiamato l'altro gestore eventi. Se quindi annulla l'operazione, entrambi gli eventi Complete verranno chiamati come negli esempi precedenti.

Gestori eventi non abbinati

Finché 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 eventi Complete viene chiamato la prima volta, è possibile restituire adStatusUnwantedEvent. Successivamente riceverai 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 smetterà di ricevere notifiche per tale evento solo quando si verificano per quel motivo specifico. In altre parole, si riceverà una notifica per ogni possibile motivo per cui l'evento potrebbe essere attivato.

I gestori eventi Single Will possono essere utili quando si desidera 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 evento Completa . Quando viene chiamato il primo gestore eventi Will, restituire adStatusUnwantedEvent. Successivamente riceverai solo gli eventi Complete .

I singoli gestori eventi 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 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 eventi singoli e più oggetti

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

Nota

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

Vedere anche

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