Domanda *difficile* (credo) : chiamare routine - evento in modo parametrico
radicale.002
/chiacchiere inuti - start
Credo, stavolta, di chiedere troppo al "giocattolino" VBA.
(d' altra parte questo m' hanno dato qui, e con questo mi devo
arrangiare) ...
Ma non si sa mai : io di natura sono ottimista :-)
chiacchiere inutili -end/
Esempio :
supponiamo di avere in maschera due combo : C1 e C2.
E quindi due procedure evento associate di tipo, diciamo,
AfterUpdate, per cui avremo :
C1_AfterUpdate( )
fai questo e quest' altro
end sub
C2_AfterUpdate( )
fai questo e quest' altro
end sub
Bene.
E' possibile chiamare queste procedure - evento ... Come dire ...
Con uno statement di tipo, grosso modo :
do while not controlli.eof
Nome_Controllo = controlli("Nome_Controllo_").value
CALL me.controls(nome_controllo)_AfterUpdate
controlli.movenext
loop
Non so francamente se mi sono spiegato.
Il VBA non supporta la chiamata di funzione per indirizzo,
a meno che non si tratti di una chiamata a qualche API in
call back. Come si puo' ovviare a questa limitazione ?
C'e' un trucco, un' escamotage che non sia EVAL ( ) ?
E' inaffidabile, e non funziona per le proc evento.
Grazie. Spero molto nel vostro aiuto.
Alessandro Cara
Cioe' sulla open una cosa del genere?
for each ctl in Controls
ctl.onafterupdate = "[Event Procedure]"(*)
next
N.B. non tutti i controls potrebbero avere l'afterupdate
oppure
una "Eval"?
(*) oppure una funzione di tua scelta
--
ac
radicale.002
wrote:
> Cioe' sulla open una cosa del genere?
>
> for each ctl in Controls
> ctl.onafterupdate = "[Event Procedure]"(*)
> next
SE PO FFFFA' ?!?!?!? GRANDIOSO !
Ma GRAZIE MILLE ! :-)
Pero' non ho compreso bene l' esempio :
Che ci devo scrivere tra parentesi quadre ?
Fammi un esempio *concreto*, ti prego.
Che ci vuole, una qualche linea di codice ...
> N.B. non tutti i controls potrebbero avere l'afterupdate
Certo, certo. Ma posso distinguerli facilmente
in base alla proprieta' controltype, come mi
insegni.
> oppure una "Eval"?
Meglio lasciarla perdere quella.
radicale.002
Si ma ... Mi chiedevo :
1)
lo statment
ctl.onafterupdate = "[Event Procedure]"
*scatena* effettivamente la "[Event Procedure]" ?
2)
Me lo dai l' esempio ? Ti prego !
Alessandro Cara
[cut]
>
> 2)
> Me lo dai l' esempio ? Ti prego !
la faq
A fronte di "[Event Procedure]" il sistema va a cercare (se non e' stato
modificato da personalizzazioni) la sub/funzione con
nomecontrollo_nomeevento
questo e' invece l'esempio con una funzione generica
ctl.onqualchecosa = "=funzioneblabla()"
Ed e' esattamente la cosa che potresti fare, in disegno, sul formato di
gestione delle proprieta'.
--
ac
radicale 003
wrote:
>A fronte di "[Event Procedure]" il sistema va a cercare (se non e' >stato
>modificato da personalizzazioni) la sub/funzione con
>nomecontrollo_nomeevento
Ah !
Io pensavo che la "[Event Procedure]" fosse il nome
della procedura da eseguire.
Invece e' il parametro. Scusa.
Ci provo. Ancora grazie, davvero molto gentile.
radicale.002
> Ci provo. Ancora grazie, davvero molto gentile.
No ...
Non va bene. Non e' possibile passare parametri alla
funzione, chiamandola in quel modo.
Oddio, e' vero che potrei predisporre i valori delle variabili
all' esterno e scrivere le funzioni in modo che se le vadano
a leggere la, ma e' un accrocco. Non mi piace. Io credo
molto nell' eleganza della programmazione.
Agiro' diversamente.
Comuque oh !
Grazie, grazie mille per l' interessamento. Davvero.
Alessandro Cara
Alcune funzioni evento ricevono parametri. Tali parametri sono passati
dal sistema, quale' il motivo che ti induce a forzarli?
Tutto cio', naturalmente, in base a come hai, mi sembra, posto il
problema. Se poi, come dice Karl, hai qualche codice "segreto" questo,
detto in modo aulico, son ben'altre braghe(*)
(*) sostituibile con piu' espliciti riferimenti
radicale.002
wrote:
> Non comprendo.
Si, ma e' colpa mia.
> Alcune funzioni evento ricevono parametri. Tali parametri sono passati
> dal sistema, quale' il motivo che ti induce a forzarli ?
Hai ragione, e ti chiedo scusa (cmq ho imparato una cosa nuova,
non sapevo si potessero chiamare le proc in quel modo)
Ripeto , e' colpa mia. All' inizio, ho creduto che bastasse chiamare
le proc evento scritte in maschera per "riutilizzarle" senza colpo
ferire.
Poi pero' analizzando il problema mi sono accorto che queste proc,
chiamate brutalmente, non erano idonee, perche' scritte per reagire
a comportamenti di un utente effettivo e non per essere utilizzate
come dire ... "batch", via.
Cioe' (come dire) facevano "troppo".
Allora ho capito che dovevo costruire delle proc ad hoc per lo
specifico
compito, ma a quel punto dovevo passargli dei parametri *miei*.
Non so se sono riuscito a spiegarmi.
> Tutto cio', naturalmente, in base a come hai, mi sembra, posto il
> problema. Se poi, come dice Karl, hai qualche codice "segreto" questo,
> detto in modo aulico, son ben'altre braghe(*)
> (*) sostituibile con piu' espliciti riferimenti- Nascondi testo citato
No no per carita' ... Nessun segreto. Ancora, mi dispiace se t' ho
dato la sensazione di aver perso tempo con me. Non e' affatto vero,
perche' quel modo di chiamare le proc mi risultera' molto utile.
Dico sul serio.
Alessandro Cara
> On 10 Lug, 10:19, Alessandro Cara <alessandro.c...@ay-1anetwork.it>
> wrote:
>
>> Non comprendo.
> Si, ma e' colpa mia.
>
>> Alcune funzioni evento ricevono parametri. Tali parametri sono passati
>> dal sistema, quale' il motivo che ti induce a forzarli ?
>
> Hai ragione, e ti chiedo scusa (cmq ho imparato una cosa nuova,
> non sapevo si potessero chiamare le proc in quel modo)
>
> Ripeto , e' colpa mia. All' inizio, ho creduto che bastasse chiamare
> le proc evento scritte in maschera per "riutilizzarle" senza colpo
> ferire.
Sono routine come tutte le altre. L'unica cosa e' che il sistema le
genera come sub di tipo privato et quindi come tutti i metodi privati
(perche' questo sono) sono visibili all'interno della classe (in questo
caso form) che li descrive.
>
> Poi pero' analizzando il problema mi sono accorto che queste proc,
> chiamate brutalmente, non erano idonee, perche' scritte per reagire
> a comportamenti di un utente effettivo e non per essere utilizzate
> come dire ... "batch", via.
Come si suol dire -di corsa- (of course).
Ma questo dipende dalla logica applicativa. Mi capita talvolta di dover
chiamare del codice che ho "appoggiato" su qualche evento.
Anche se, in virtu' della famosa eleganza di codice (a noi armani ci fa
del ricco autoerotismo), ho un certo ribrezzo a farlo e raccolgo il
codice in funzioni piu' autoesplicanti chiamate + o - direttamente.
>
> Cioe' (come dire) facevano "troppo".
> Allora ho capito che dovevo costruire delle proc ad hoc per lo
> specifico
> compito, ma a quel punto dovevo passargli dei parametri *miei*.
>
"e alura?" (mutuato da lingua extracomunitaria)
Puoi sempre chiamare una user function. L'esempio mi sembra di averlo
fatto.
> Non so se sono riuscito a spiegarmi.
>
>> Tutto cio', naturalmente, in base a come hai, mi sembra, posto il
>> problema. Se poi, come dice Karl, hai qualche codice "segreto" questo,
>> detto in modo aulico, son ben'altre braghe(*)
>> (*) sostituibile con piu' espliciti riferimenti- Nascondi testo citato
>
> No no per carita' ... Nessun segreto. Ancora, mi dispiace se t' ho
> dato la sensazione di aver perso tempo con me. Non e' affatto vero,
> perche' quel modo di chiamare le proc mi risultera' molto utile.
> Dico sul serio.
In questo momento ho parecchio tempo da perdere al contrario di te, mi
sembra.
radicale.002
wrote:
> Certo che si!
> Sono routine come tutte le altre. L'unica cosa e' che il sistema le
> genera come sub di tipo privato et quindi come tutti i metodi privati
> (perche' questo sono) sono visibili all'interno della classe (in questo
> caso form) che li descrive.
Ehm ... Non mi sono spiegato allora.
Lo so che sono routine come le altre, ma in particolare *queste*
sono state scritte per un utente che ha la maschera davanti,
capisci ? Ripeto : fanno troppo, e invece quelle che devo chiamare
via batch devono fare meno.
> Come si suol dire -di corsa- (of course).
> Ma questo dipende dalla logica applicativa. Mi capita talvolta di dover
> chiamare del codice che ho "appoggiato" su qualche evento.
> Anche se, in virtu' della famosa eleganza di codice (a noi armani ci fa
> del ricco autoerotismo), ho un certo ribrezzo a farlo e raccolgo il
> codice in funzioni piu' autoesplicanti chiamate + o - direttamente.
Appunto.
> "e alura?" (mutuato da lingua extracomunitaria)
> Puoi sempre chiamare una user function. L'esempio mi sembra di averlo
> fatto.
Si.
Ma chiamandola nel modo da te indicato non *posso* passargli i
parametri ... Se non accroccando come dicevo sopra.
O forse posso e semplicemente non ho capito ?
> In questo momento ho parecchio tempo da perdere
Ok
>al contrario di te, mi sembra.
Questa me la devi spiegare.
Alessandro Cara
[cut]
>> al contrario di te, mi sembra.
> Questa me la devi spiegare.
mentre il sottoscritto non sa piu' a che serial TV votarsi
perche' a questa non puoi passare parametri?
=funz(x,y)
Di fatto e' una Eval, che non comprendo perche' la "aborri"
radicale.002
wrote:
> Nel senso che mi sembri parecchio impegnato a scrivere una applicazione
> mentre il sottoscritto non sa piu' a che serial TV votarsi
Eh ! Capirai ... Pe' ste 4 cazzate che faccio.
Naa, tranquillo. Sempre a disposizione. :-)
> perche' a questa non puoi passare parametri?
> =funz(x,y)
> Di fatto e' una Eval, che non comprendo perche' la "aborri"
Ma non e' che la "aborro" ... Semmai e' lei che
"aborrisce" me. (LOL).
Ho sperimentato, ad esempio, che se f(x,y) restituisce
un recordset, l' eval *schioda* miseramente. E altre cosette
che non ricordo (c' ho combattuto qualche anno fa)
E poi, posso fare if (... =f(x,y) ) then ... ? Non credo.
O si ?
Se si, fammi un esempio CONCRETO,
mannaggia a te ! :D
(notare faccetta sorridente).
Alessandro Cara
[cut]
> E poi, posso fare if (... =f(x,y) ) then ... ? Non credo.
Non puoi legarla ad un evento di form poiche' il ritorno avviene su
access e non a caso il sistema genera delle sub e, come nel caso della
beforeupdate, poiche' e' permessa la segnalazione di "abort" dell'evento
il tutto viene mediato impostando il valore (false) sul parametro cancel
(passato per riferimento)
L'eventuale ritorno della funzione va gestito mediante una variabile
pubblica da interrogare quando serve.
Siamo pero' passati da un problema di parametri a un problema di ritorno
funzione.
Forse una descrizione analitica del problema potrebbe servire.
radicale.002
wrote:
> Se devi fare if fun(x) then
> Non puoi legarla ad un evento di form poiche' il ritorno avviene su
> access
Spiegami per bene questo concetto del "ritorno su access".
Che significa ?
>e non a caso il sistema genera delle sub e, come nel caso della
>beforeupdate, poiche' e' permessa la segnalazione di "abort" dell'evento
>il tutto viene mediato impostando il valore (false) sul parametro cancel
>(passato per riferimento)
Certo.
> L'eventuale ritorno della funzione va gestito mediante una variabile
> pubblica da interrogare quando serve.
Una variabile pubblica impstata dalla funzione stessa, immagino.
> Siamo pero' passati da un problema di parametri a un problema di ritorno
> funzione.
> Forse una descrizione analitica del problema potrebbe servire.
M' avevi chiesto perche' non mi piace l' eval.
Non mi piace perche' non e' generale. Fisse mie ...
Pero' (per favore) :
fammi un esempio concreto di chiamata a una funzione
chiamata con l' on ... Eccetera e fammi vedere come gli
passi i parametri.
Alessandro Cara
proprieta' : =setTag(Form)
e magari inserisci questa in un modulo
Public Function setTag(fm As Form)
fm.ActiveControl.Tag = "" & fm.ActiveControl.value
End Function
radicale.002
wrote:
> Prova a scrivere, su un qualsiasi controllo in evento nella form delle
> proprieta' : =setTag(Form)
Non capisco bene dove la dovrei scrivere, scusa.
> e magari inserisci questa in un modulo
>
> Public Function setTag(fm As Form)
> fm.ActiveControl.Tag = "" & fm.ActiveControl.value
> End Function
E in che punto gli passo i parametri ?
Alessandro Cara
> On 10 Lug, 14:27, Alessandro Cara <alessandro.c...@ay-1anetwork.it>
> wrote:
>
>> Prova a scrivere, su un qualsiasi controllo in evento nella form delle
>> proprieta' : =setTag(Form)
>
> Non capisco bene dove la dovrei scrivere, scusa.
Che so Tipo Form, sorgente dati, Presenza controllo di navigazione
Li ci sono anche gli eventi ed in genere si attiva [Routine Evento] be
invece di fare cio imposti =setTag(Form)
>
>> e magari inserisci questa in un modulo
>>
>> Public Function setTag(fm As Form)
>> fm.ActiveControl.Tag = "" & fm.ActiveControl.value
>> End Function
>
> E in che punto gli passo i parametri ?
scusami ma Form/fm in questo caso cos'e'?
Sai usarlo il debug vero?
>
radicale.002
wrote:
Aspetta aspetta che comincio a capire (forse) :
> Hai presente quando in disegno imposti le varie proprieta?
In disegno di cosa ? Di un combo, per esempio ?
> Che so Tipo Form, sorgente dati, Presenza controllo di navigazione
> Li ci sono anche gli eventi ed in genere si attiva [Routine Evento] be
> invece di fare cio imposti =setTag(Form)
Tipo, per esempio, se scrivo nella riga "dopo aggiornamento" la
stringa "=setTag(form)" (senza apici, ovviamente) ?
In questo caso , dici tu, dopo l' aggiornamento del combo, il
combo esegue la funzione setTag (Form) passandogli la
maschera come parametro ? E' questo che intendi ?
Eh ?
Ma non dovrei scrivere "=setTag(Me)"
Oppure form e' una parola chiave ?
> Public Function setTag(fm As Form)
fm.ActiveControl.Tag = "" & fm.ActiveControl.value
> End Function
Ok !
> scusami ma Form/fm in questo caso cos'e'?
Si si , mi si era impicciata la testa. :-)
> Sai usarlo il debug vero?
Si si, certo.
Attendo.
radicale.002
> Ma non dovrei scrivere "=setTag(Me)"
> Oppure form e' una parola chiave ?
Ah ... Un' altra cosa :
E se invece volessi passargli un recordset o una
stuttura, come faccio ?
Alessandro Cara
> On 10 Lug, 19:08, Alessandro Cara <alessandro.c...@ay-1anetwork.it>
> wrote:
>
> Aspetta aspetta che comincio a capire (forse) :
>
>> Hai presente quando in disegno imposti le varie proprieta?
> In disegno di cosa ? Di un combo, per esempio ?
>
>> Che so Tipo Form, sorgente dati, Presenza controllo di navigazione
>> Li ci sono anche gli eventi ed in genere si attiva [Routine Evento] be
>> invece di fare cio imposti =setTag(Form)
>
> Tipo, per esempio, se scrivo nella riga "dopo aggiornamento" la
> stringa "=setTag(form)" (senza apici, ovviamente) ?
ma esssendo una stringa l'assegnazione va delimitata da virgolette,
ovviamente
>
> In questo caso , dici tu, dopo l' aggiornamento del combo, il
> combo esegue la funzione setTag (Form) passandogli la
> maschera come parametro ? E' questo che intendi ?
> Eh ?
>
> Ma non dovrei scrivere "=setTag(Me)"
> Oppure form e' una parola chiave ?
"Form")
radicale.002
wrote:
> No. Va bene anche Me (se non ricordo male, forse access la trasforma in
> "Form")
Ok, a posto. Grazie. Mai vista sta tecnica.
M' hai insegnato veramente.
Mo' se me dici come faccio a passargli dei parametri generici
e non solo una form (recordset, strutture, stringhe, vettori ...)
c' hai er caffe' pagato.
Hai fatto 30, fai 31, no ? :-)))
Alessandro Cara
> On 10 Lug, 20:59, Alessandro Cara <alessandro.c...@ay-1anetwork.it>
> wrote:
>
>> No. Va bene anche Me (se non ricordo male, forse access la trasforma in
>> "Form")
>
> Ok, a posto. Grazie. Mai vista sta tecnica.
> M' hai insegnato veramente.
>
> Mo' se me dici come faccio a passargli dei parametri generici
> e non solo una form (recordset, strutture, stringhe, vettori ...)
> c' hai er caffe' pagato.
>
> Hai fatto 30, fai 31, no ? :-)))
>
>
>
essere di tipo globale. Normalmente non ho questo problema perche' sono
uso utilizzare una classe globale che ha la possibilita' di avere dentro
tutto quello che mi potrebbe servire. Passare un solo oggetto per
riferimento e' la cosa piu' veloce e duttile. Passale come faresti
normalmente se hai problemi "telefona casa"
--
ac
radicale.002
wrote:
> Se continui ad usarlo access potrebbe sorprenderti.
Gia'.
Chissa' quante cose che ci sono e ancora non so.
Mah.
> E' solo un problema di visibilita'. Temo che le tue variabili debbano
> essere di tipo globale. Normalmente non ho questo problema perche' sono
> uso utilizzare una classe globale che ha la possibilita' di avere dentro
> tutto quello che mi potrebbe servire. Passare un solo oggetto per
> riferimento e' la cosa piu' veloce e duttile. Passale come faresti
> normalmente se hai problemi "telefona casa"
Ok , grazie ancora e alla prossima, allora.