Newsgroup: it.comp.lang.visual-basic
Titolo: Funzioni di callback invece degli eventi

Ciao.
In relazione al mio post precedente, vorrei provare a sostituire gli eventi
con cui due form comunicano, con delle funzioni di callback.
Ho cercato qualche esempio ma non ho trovato niente di comprensibile.
Avete qualche sito da consigliarmi oppure qualche riga di codice che
dimostri come due form possono comunicare tra loro utilizzando funzioni di
callback invece di eventi?
Grazie.
-- 
Skysurfer

Skysurfer ha scritto:

Ho letto il tuo post precedente ma non ci ho capito molto.
Personalmente credo che se crei riferimenti circolari (in VB come in 
qualsiasi altro linguaggio) c'è qualcosa che non va nella logica 
dell'applicazione, che dovrebbe essere un albero nelle chiamate delle 
classi e non un cerchio.
Detto questo le funzioni di callback altro non sono che eventi: la 
classe riceve un messaggio e lo tramuta nella chiamata all'evento 
relativo, oppure (e questo più si avvicina alla definizione di funzione 
di callback) una funzione ne chiama un'altra conoscendone l'indirizzo in 
memoria.
Questo in VB si fa un po' più semplicemente facendo direttamente una 
Call della funzione.
Se proprio vuoi impazzire complicandoti la vita, cerca nei post passati 
con google AddressOf e CallWindowProc oppure qualcosa tipo "chiamare una 
funzione dato l'indirizzo".
Ciao

 Ho letto il tuo post precedente ma non ci ho capito molto.
Il problema principale č quello di poter richiamare uno stesso form da piů
punti dell'applicazione.
Sul mio FormA ho una lista di autorizzazioni (di un certo tipo, diciamo di
tipo B) legate ad un utente. Cliccando su un button devo aprire il FormB che
mi visualizza il dettaglio dell'autorizzazione (di tipo B) selezionata. Il
fatto č che sul FormB ho una lista di autorizzazioni di tipo A e cliccando
su un button dovrei aprire il FormA visualizzando i dettagli
dell'autorizzazione di tipo A selezionata.
Tutto funzionerebbe bene se non avessi bisogno di notificare al FormA quando
nel FormB viene modificato un dato dell'autorizzazione scelta, in modo che
la lista nel FormA venga aggiornata....  e viceversa.
Per fare questo uso gli eventi, ma incappo nel problema che ho detto
all'inizio.
Grazie e ciao
-- 
Skysurfer

 classi e non un cerchio.
concordo. in particolare, nel caso del problema di skysurfer, sarebbe
risolvibile facendo in modo che la form mdi padre facesse da ponte tra le
due. Intendo dire: è la form main che gestisce gli eventi della figlia e si
preoccupa di aggiornare i campi dell' altra.
hth
--
Salutoni
Sergio

 la lista nel FormA venga aggiornata....  e viceversa.
Non so se ho capito bene l'esigenza (e comunque un avviso di riferimenti
circolari e' un problema di logica, non di metodo), ma se tu nella FormA
inserisci una funzione, ad esempio "AggiornaLista", che faccia il refresh
della tua lista (e qualsiasi altra operazione), dalla form B la puoi
richiamare con:
  FormA.AggiornaLista
E' questo che intendevi?
-- 
Ciao!
   -DocDoc-
--- Per scrivermi: 
do...@despammed.com
Sei anche tu stanco dei messaggi spam? Usa Terminator, il programma
anti-spam italiano FREEWARE! 
http://www.sertel.net/terminator/

 E' questo che intendevi?
Si, penso che cosě possa andare.
Il fatto č che FormB puň essere richiamato da qualsiasi altro form in giro
per l'applicazione, quindi non č detto che quando salvo i dati io debba
sempre fare il Refresh della lista su FormA. Puň darsi che lo debba fare su
FormC o su FormX, oppure su nessun Form, se il FormB č stato aperto da menů.
Ciao
-- 
Skysurfer

 FormC o su FormX, oppure su nessun Form, se il FormB č stato aperto da
menů.
Se sai qual'e' la form che devi aggiornare, farai FormC.AggiornaLista
piuttosto che FormX.AggiornaLista.
Se la cosa va parametrizzata dalla form chiamante puoi fare qualcosa (non
l'ho sperimentato quindi non so darti per certo che funzioni), ossia nella
FormB aggiungi:
Dim Chiamante As Form
Poi quando crei la FormB puoi fare qualcosa dal tipo:
Load FormB
Set FormB.Chiamante = Me
FormB.Show
A quel punto dalla FormB puoi richiamare il metodo "AggiornaLista" del
chiamante facendo:
Chiamante.AggiornaLista
Prova e fammi sapere...


 Prova e fammi sapere...
Si.. l'avevo fatto così e funziona.
Adesso sto provando a passare come proprietà direttamente la lista da
aggiornare (che ha già un suo metodo Refresh) invece del Form.
E richiamo il Refresh della lista utilizzando il CallByName.
Sembra funzionare...
Speriamo bene.
Grazie a tutti per l'aiuto.
Ciao
-- 
Skysurfer

 punti dell'applicazione.
[SNIP]
Ti evidenzio una cosa detta da Zanna
"le funzioni di callback altro non sono che eventi"
stante che le altre soluzioni proposte vanno ugualmente bene, quanto sopra
vuol dire che puoi implementare un tuo meccanismo di callback senza
scomodare ne' puntatori a funzioni ne' altri sistemi "esotici", ma
semplicemente definendo una piccola classe:
'Ipotetica classe cCallback
Public Event UnCallback(p1, p2)
Public Event UnAltroCallback()
Public Sub RaiseUnCallback(p1, p2)
    RaiseEvent UnCallback(p1, p2)
End Sub
Public Sub RaiseUnAltroCallback()
    RaiseEvent UnAltroCallback
End Sub
Fatto questo, aggiungi una property pubblica alla tua form "riciclabile"
(FormB) di tipo cCallback, e nelle form chiamanti una variabile
Private WithEvents Callback As cCallback
e il codice di gestione degli eventi che servono; quando queste avranno
necessita' di ricevere una notifica da FormB la chiameranno con:
Set Callback = FormB.Callback 'ora possiamo catturare gli eventi scatenati
da B
FormB.Show
mentre FormB a sua volta non fara' altro che chiamare i metodi RaiseXXX al
momento opportuno
Nota che, a differenza delle altre soluzioni, sei hai una applicazione MDI o
comunque basata su piu' form non modali, questo sistema ti permette di
inviare notifiche a piu' finestre contemporaneamente a "costo zero"
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 Grazie a tutti per l'aiuto.
prima di incappare in altri problemi, dichiara la lista come Object, questo
ti da meno complicazioni nella gestione dei tipi di vb ( che a volte fa le
bizze )
anche io uso questo stratagemma per i chiamanti aggungendo pero' il
settaggio a nothing in chiusura e il testing alla sua valorizzazione , ti
faccio un esempio partendo da quello dei post precedenti :
'----------------------
Load FormB
Set FormB.Chiamante = Me
FormB.Show
'----------------------
diciamo che inglobo queste istruzioni in una funzione stessa della formB
tipo :
'----------------------
sub InitQualcosa( myList as object)
    'testo che il chiamante non sia gia' settato
    if myList.tag <> vbnullstring then exit sub ' o qualsiasi altra
proprieta' che ti rimane comoda
    'faccio le operazioni di setup del form come reset di liste ecc ...
     me.show  'vabbe' metti quello che vuoi ecc...
 end sub
'----------------------
la chiami da dove vuoi con :
formB.InitQualcosa me.listbox1 ' o qualsiasi altro controllo
- cosi il load e' implicito,
- se e' caricato gia' la func non viene eseguita (potresti inserire anche
una risposta)
- la show e' superflua ma abondare non fa mai male ^_-
- tutto imvho
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/