Newsgroup: it.comp.appl.access
Titolo: Ordine di eventi valutati non corretto

Questo comportamento anomalo mi si verifica in diversi casi ed è piuttosto
irritante.
1° caso:
maschera con una combo, una casella di riepilogo e un pulsante di uscita.
la casella di riepilogo si basa su una query con criterio sul valore scelto
nella combo. Su dopo aggiornamento della combo, eseguo un requery sulla
casella di riepilogo.
Il pulsante, ha una semplice docmd.close.
Se io seleziono un valore nella combo, faccio invio, poi clicco sul
pulsante, è tutto ok.
Se invece seleziono il valore già presente nella combo, evidenziandolo,
quindi faccio CANC, e senza fare un tab o invio clicco sul pulsante, lui
esce dalla maschera e quindi mi apre la finestrella di richiesta parametri
per query, chiedendomi il valore del controllo combo.
Evidentemente viene eseguito prima l'evento clic del pulsante e solo dopo
l'evento dopo aggiornamento della casella di riepilogo. A quel punto però la
combo non esiste più, perchè la maschera è chiusa, e quindi mi chiede
fastidiosamente il parametro mancante.
2° caso:
maschera con una casella di testo e pulsante.
Su evento lostfocus della casella ho scritto del codice che esegue dei
controlli sul valore inserito. Il pulsante invece esegue del codice che
andrebbe eseguito solo se i controlli sul lost focus sono stati superati con
successo.
Anche qui, se dopo aver selezionato la casella di testo, senza fare tab o
invio, clicco direttamente sul pulsante, mi esegue prima il codice del
pulsante, quindi quello del lostfocus.
Entrambi i casi palesano che l'ordine degli eventi valutati non è quello
strettamente cronologico e crea non pochi problemi.
Commenti? Risoluzioni?
Grazie
Antonio

 ha scritto nel messaggio
news:E89%8.18389$s74.5...@twister1.libero.it...

Volevo sapere se per caso hai provato a richiamare dal pulsante le relative
funzioni prima dell' azione docmd.close
Ovvero se per esempio la funzione in merito alla combo è   Private Sub
cbo_AfterUpdate()
=======================================
Private sub cmdclose_click()
cbo_afterupdate
cmd.close
end sub
Saluti
Mak

 pulsante, quindi quello del lostfocus.
anche qui l'evento potrebbe essere change?
ciao
aò io c'ho provato...
MAssimiliano

 end sub
Ci ho provato adesso. Continua a fare la stessa cosa.
Ho provato a mettere un msgbox nella cbo_afterupdate per "rallentare"
l'esecuzione del clic.
In questo caso mi da due volte il msgbox (una perchč chiamo la cbo dal clic,
l'altra perchč a quel punto, prima di chiudere la maschera "sente" l'update
e me lo riesegue.
Ma non risolvo il problema cosě...
Antonio

 aò io c'ho provato...
Ehe ehh e
Antonio

 ha scritto nel messaggio
news:E89%8.18389$s74.5...@twister1.libero.it...

Non entro in merito circa l'ordine degli eventi valutati da Access: vengono
valutati così e non credo che detto ordine possa essere cambiato: penso che
l'unica cosa da fare sia evitare gli effetti non graditi.
Per il primo caso, se la casella combinata si chiama MiaCombo e la casella
di riepilogo si chiama Elenco, a fronte dell'evento "Su clic" del pulsante
di comando genererei il seguente codice VBA:
Me!MiaCombo.SetFocus
If Me!MiaCombo.Text = "" Then
    Me!Elenco.RowSource = ""
End If
DoCmd.Close
Ho provato la soluzione e a me funziona.
Con la stessa logica, per il secondo caso, inizierei la routine che hai
generato a fronte dell'evento "Su clic" del pulsante di comando ripetendo
TUTTE le verifiche che già hai scritto al livello dei vari lostfocus: solo
allora andrei ad eseguire la parte di codice che hai già scritto.
Forse sono soluzioni un po' sporche, però penso siano efficaci.
--
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 Forse sono soluzioni un po' sporche, però penso siano efficaci.
E' proprio così infatti.
Mah...
Antonio

 Antonio


 aggiornare" e "Dopo aggiornamento" solo se relativo ad un gruppo di
opzioni.
Quindi è proprio previsto che faccia così?
Antonio

 ha scritto nel messaggio
news:Xs819.13902$lu5.3...@twister1.libero.it...

Anche se non è tanto logico, sembrerebbe di si.
