Newsgroup: it.comp.lang.visual-basic
Titolo: Passare una ADODB.Connection come parametro

Salve a tutti.
Nel programma che sto facendo, apro una maschera per editare i valori
di un record scelto da una griglia.
Questa maschera è un form che fa parte di una dll.
Per ora passo alla dll la stringa di connessione al mio db, e creo ed apro
una nuova
Connection.
Ho provato a passare come parametro la connessione che uso nel mio client
invece della stringa, e accade che, se chiudo la suddetta connection nella
mia dll,
me la trovo chiusa anche nel client. Credo sia normale.
Mi intendo poco di passaggio per riferimento e per valore dei parametri, ma
ho provato
a passarla per valore (ByVal), cosa che dovrebbe impedire la "modifica"
della
variabile passata, quindi anche la sua chiusura.
Questo è il codice del client:
******
Set MyObj.LetADOConnection = cnConnectionClient    'cnConnection è la
connessione Client
******
Questo è il codice della classe
******
Public Property Set LetADOConnection(ByVal vNewValue As ADODB.Connection)
    Set cnConnection = vNewValue
End Property
******
cnConnection è dichiarata come Public in un modulo bas.
Sbaglio qualche cosa? Come dovrei fare per evitare che, chiudendo la
connessione
nella dll, venga chiusa anche nel client?
Inoltre è meglio passare come parametro la Connection o la stringa di
connessione (e quindi creare ed
aprire una nuova nella dll)?
Pongo questa domanda perchè per ora mostro la form in modalità vbModal.
In questo modo, posso aprire solo una maschera alla volta, creando quindi
solo
una Connection in più (oltre a quella nel client).
Vorrei però poter aprire + maschere, una per ogni record scelto dalla
griglia.
Ma in questo modo, se creassi ed aprissi una Connection per ogni istanza
creata, non appesantirei il tutto?
Altra domanda.
Quando istanzio il mio oggetto, gli passo l'ID del record da gestire:
*****Client*****
Private Sub grdAutori_DblClick()
    Call sChiamaModifica
End Sub
Private Sub sChiamaModifica()
Dim objInsMod As InsMod
        Set objInsMod = New InsMod
        objInsMod.LetAction = "Modificare"
        objInsMod.LetID = 15
        objInsMod.fShowMask Mask.AUTORI, New CallbackCls
End Sub
*****Cient*****
*****dll*****
Public Property Let LetID(ByVal vNewValue As Long)
    lngID = vNewValue
End Property
*****dll*****
lngID è dichiarato come Public in un modulo bas.
Se richiamo la routine sChiamaModifica più volte, accade che, per tutte le
istanze create,
l'ID sarà quello dell'ultimo record selezionato (cioè dell'ultima istanza
creata), con conseguenze
"mostruose": modifico, per esempio, sempre lo stesso record.
Inoltre, istanziando l'oggetto in una routine, poichè la visibilità del
suddetto è limitata
ad essa, quando esco da questa routine il mio oggetto viene distrutto,
provocando l'evento
ClassTerminate. Tuttavia la maschera rimane visualizzata e posso eseguire le
operazioni che
desidero (modifica, eliminazione seppur con il problema dell'ID), comprese
le notifiche tramite callback.
Come posso fare? E' naturale che l'oggetto venga distrutto, ma che la
maschera sia visibile,
così come l'oggetto connection all'interno del mio oggetto?
Usando poi il metodo callback, e passando alla dll una classe del client
(CallbackCls)
che implementa un'interfaccia della dll (InsModCBK), come posso distruggere
il riferimento
alla classe client, visto che l'evento ClassTerminate non riesco a gestirlo
come vorrei (vedi sopra),
e non posso bloccare l'esecuzione del codice nella classe dopo aver mostrato
la maschera, poichè
non la mostro più in modalità vbModal?
Centra qualcosa il modello di threading che devo adottare??? La mia dll
è a thread singolo, ma anche mettendo Apartment threading non ho ottenuto
risultati diversi.
La classe invece ha la proprietà istancing = MultiUse
E meno male che volevo cimentarmi nella OOP... cazzarola... :)
Grazie a tutti.
Saluti,
Guido

Guido, solo per un consiglio, se vuoi che ti leggano sii sintetico ;)
A presto,
Mangiafuoco


Solo un paio di precisazioni, dato che, umanamente, non ce l'ho fatta a
leggere tutto (Guerra e Pace č un tascabile al confronto... :-)  ).
Per quanto riguarda la connection, tieni presente che hai di fronte a te 2
alternative (sensate):
1) Crei la connection all'interno del programma chiamante e la passi alla
dll di interfaccia dati (ma non la fai chiudere alla dll, la chiudi dal
programma chiamante).
2) Passi alla dll la stringa e la fai aprire dalla dll ogni volta.
Ovvio: una connection aperta mantiene aperto un canale di rete con il tuo
server dati, ma se stiamo parlando di ambito Lan o al piů di Wan aziendale
(non Internet, sia chiaro!) la cosa semplifica la gestione e rende
decisamente piů efficiente il lavoro del tuo applicativo client-server.
Quindi, personalemente opto per la prima soluzione, al piů con una variante:
non costruisci 1 classe di gestione dati, ma 2: la prima come "gestore
generale" della connection e delle classi di interfaccia. La seconda
costituita appunto dalle classi di interfaccia tra il Form dell'applicativo
e i dati.  A quel punto il flusso diviene:
- Un applicativo di fron-end vb che si occupa dell'interfaccia utente
- Una classe di gestione generale che crea la connection e si occupa delle
init e destroy delle singole istanze di interfaccia
- Una classe di interfaccia che gestisce la comunicazione tra i dati puri e
l'applicativo utente.
Non so se sono stato chiaro, ma ho tanto sonno stasera...  :-)
ciao
ugo

 Non so se sono stato chiaro, ma ho tanto sonno stasera...  :-)
Sei stato chiarissimo. Vedrň di implementare quello che hai detto.
Grazie :)
Ciao, Guido.