Newsgroup: it.comp.appl.access
Titolo: Casella di testo con evento afterupdate, pulsante con evento click... stesso comando...

Ho una mascera con dentro una casella di testo ed un pulsante "Salva".
Vorrei che all'utente venisse data la possibilità di ottenere lo
stesso effetto (salvare la stringa inserita) sia con la pressione
dell'invio dopo aver scritto nella casella di testo, sia facendo click
sul pulsante salva.
Per ottenere questo ho fatto si che l'evento "dopo aggiornamento" della
casella di testo e l'evento "click" del pulsante mi richiamino la
stessa funzione...
Ora, il problema è che, scrivendo sulla casella di testo e poi
clicckando sul pulsante, l'evento afterupdate della casella di testo si
avvia anche se non è stato premuto invio... (e di conseguenza
l'operazione di salvataggio viene effettuata due volte
consecutivamente, prima per via dell'afterupdate e poi per il click)
come fare a impedire tutto questo?
Grazie, Daniele.
P.S.
Ho provato a sostituire l'evento afterupdate della casella di testo con
un evento "su INVIO" ma... non funziona... Forse perchè, attualmetnte,
sono alle prese con un altro problema (ho aperto una discussione
apposita per questo), ho già un INVIO che si propaga dalla maschera
precedente (che mi apre la maschera che vi ho descritto) e questo mi fa
partire l'evento "su INVIO" della mia casella di testo subito
all'apertura della maschera... pero' pensavo di aver risolto la cosa
gestendo il caso -per ora- controllando se la casella di testo è
vuota... Questo lo gesisce correttamente, ma quando premo INVIO perchè
davvero mi interessa salvare, l'evento "su INVIO" non parte affatto e
la procedura di salvataggio di conseguenza... mah????
Potete aiutarmi a capire e risolvere il problema per favore?


No si capisce molto se la tua form e' associata o non associata.
L'afterupdate scatta *sempre*, se si modifica il dato, e quindi non ha 
senso fare la stessa cosa che fai in salva.
Inoltre *normalmente* il salva si fa sul record e non sul singolo 
controllo. RiInoltre se e' un *After* update vuol dire che un qualche 
aggiornamento e' gia' stato fatto! E quindi al massimo siamo in presenza 
di un *risalva* ;<)
-- 
ac
y-1=x

Alessandro Cara ha scritto:

Ok, mi spiego meglio...
La procedura che io chiamo per salvare la stringa l'ho scritta io ad
hoc per manipolare determinate tabelle del mio database e fa uso di
RunSQL (con INSERT o UPDATE a seconda di altre cose che, per brevità
non sto qui a spiegare).
Il punto è che, non sai mai quali sono i gusti degli utenti che
utilizzano la tua applicazione... ci sono quelli che sono abituati a
premere invio dopo aver digitato del testo e si aspettano che questo
dia luogo al salvataggio e ci sono quelli che si aspettano di trovarsi
davanti un pulsante "Salva" per rendere effettiva la modifica... (e
magari ci saranno anche altri modi per ottenere lo stesso risultato -
salvare qualcosa - ma, al momento non mi sono venuti in mente...)
Ora ho pensato: "facciamo felici sia quelli abituati ad operare in un
modo che gli altri e prevediamo entrambi i casi".
Per fare questo, ovviamente, ho dovuto impostare un evento sia sulla
casella di testo (afteruppdate) che prevedere un apposito bottone (che
ho chiamato io "salva"... non ho usato procedure guidate di Access...
cerco di non farlo mai, mi piace scrivermelo il più possibile da solo
il codice se posso) anch'esso con un evento associato (click)...
Per il resto la storia già l'ho raccontata: il mio problema è: come
faccio a far "convivere" le due cose (visto che lo scrivere nella
casella di testo e poi clicckare sul pulsante fa partire lo stesso
prima l'evento definito sulla casella di testo e poi quello del
pulsante)?
Spero di aver fornito tutte le spiegazioni necessarie per farmi aiutare
nella risoluzione di questo problema...
Ciao, Daniele.

 nella risoluzione di questo problema...
Ti ripeto che se fai un aggiornamento automatico dopo una after update 
il salva non serve e questo sia che l'afterupdate sia effettivo (dovuto 
ad associazioe dei controlli) che controllato da userFunction. Pensa un 
attimo alla sequenza degli eventi.
Inoltre, una situazione del genere o simile, mi e' capitato di gestirla. 
In questo caso quello che faccio e' interrogare la proprieta' dirty o in 
uscita dal form o in uscita dal record corrente e chiedo se si vogliono 
consolidare le eventuali modifiche ma tutto cio' sull'evento di 
"beforeUpdate" e non di after. Poiche' questo talvolta puo' risultare 
scocciante ho sempre un indicatore (a livello della intera applicazione) 
che segnala se si vuole o meno la emissione dei messaggi di conferma a 
fronte di qualsiasi aggiornamento.
-- 
ac
y-1=x

Daniele ha scritto:



Lascia sulla maschera il pulsante SALVA ma togligli il codice VBA. Quando
l'utente lo clicca il cursore esce dalla textbox e viene eseguito il
codice Afterupdate della textbox, quello del pulsante è un doppione.
Se i dati non erano stati modificati l'Afterupdate della textbox non si
verifica, quindi non salva niente perchè non ce n'è bisogno.
Ciao.
-Marco-
-- 
namor at inwind punto it
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it