Newsgroup: it.comp.lang.visual-basic
Titolo: Unload di un programma.

Mi succede una cosa strana. Se mi fallisce una connessione a sql server,
e quindi faccio l'unload sulla form di login, in realtà il programma rimane
appeso (task manager)
Se tutto è ok, invece, quindi mi loggo e poi chiudo il tutto, il programma
si chiude.
La cosa strana è che dentro la form di login, distruggo tutti gli oggetti.
Ho provato a fare un pò di debug, ma inutilmente, non riesco a capire
cosa possa rimanere aperto e/o attivo. L'unica soluzione che ho -
temporaneamente spero - è nell'ultima istruzione dell'unload dichiarare
un bell END ... così che sega tutto e chiude. Ma le soluzioni sporche
non mi sono mai piaciute.
C'è un qualche modo - oltre gli watch e le local variable per vedere
cosa sia attivo??
--
Saluti
Andrea Moro

La cosa strana è che dentro la form di login, distruggo tutti gli oggetti.
Allora e' molto probabile che esista almeno una di questre cose:
1. riferimenti circolari;
2. variabili globali usate un po' da tutti;
3. accesso a controlli da codice esterno alle form che li contiene;
-- 
ciao, hal

 3. accesso a controlli da codice esterno alle form che li contiene;
Mumble ... l'unica form che carico è la prima - quella di login ...
quindi escluderei l'ipotesi una seconda form che istanzia la prima.
Variabili globali si ... ce ne sono ... quelle utilizzate dal form di login
sulle quali scrive i parametri letti dal file di configurazione. ...  Ma
la faccenda si chiude li.
Forse riferimenti circolari ... ma non capisco bene come si creino
in vb ... di conseguenza non saprei cosa andare a cercare.
Cosa puoi dirmi al riguardo?
--
Saluti
Andrea Moro

Capito  il problema ... non i riferimenti circolari. Chiamavo un
bel frmmain.controllo.proprietą = z
Che sono questi i riferimenti circolari??
--
Saluti
Andrea Moro

Come non detto ... mi ero di menticato di togliere l'end para tutto.
--
Saluti
Andrea Moro

Lascia perdere ... ho mangiato troppo uovo di ciccolato :P
Era un frmmain che non avevo effettivamente tolto ... lui
caricava l'oggetto ... l'unload del form login chiaramente non
toglieva di mezzo anche il frmmain, cosa che accadeva invece
con l'unload di fine programma (ad autenticazione avvenuta)
Grazie lo stesso.
--
Saluti
Andrea Moro

con l'unload di fine programma (ad autenticazione avvenuta)
L'importante e' che tu non abbia risolto con End: pensa che io non lo
uso mai ed e' una buona cartina di tornasole per sapere se ho
scaricato tutto oppure no. 
Inoltre seguo anche un'altra regola: se una funzione crea un oggetto,
allora la stessa funzione si preoccupa di distruggerlo.
-- 
ciao, hal

 allora la stessa funzione si preoccupa di distruggerlo.
Di norma si, tutte le funzioni istanziano e distruggono oggetti.
Capita tuttavia a volte che istanzio un oggetto in eventi di vb o di terze
parti che, per non sprecare memoria, allor quando sò che servono poco
più tardi in un ciclo forzato che deve per forza andare in quel modo,
piuttosto che distruggere e ricreare l'oggetto, lascio vivo quello già
usato.
Casi rari ... ma penso che risparmiare qualche ciclo macchina sia sempre
utile.
--
Saluti
Andrea Moro

 allora la stessa funzione si preoccupa di distruggerlo.
E per il pattern Factory? ;-)
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

E per il pattern Factory? ;-)
Be', qualche eccezione c'e' ;-)
-- 
ciao, hal

> E per il pattern Factory? ;-)
Sarebbe??
--
Saluti
Andrea Moro

 Sarebbe??
In parole semplici (e limitate) è un metodo per rimediare alla mancanza
di costruttori con parametri in VB.
Cerco di spiegarmi meglio:
supponiamo di avere un oggetto di classe Pippo e di doverlo
inizializzare all'atto della creazione. In altri linguaggi (tra cui
VB.NET
) è possibile ricorrere al costruttore della classe:
Dim a as Pippo = new Pippo(parametri_di_inizializzazione)
In VB questo non è possibile. L'inico modo è ricorrere ad un metodo di
inizializzazione (spesso chiamato Init):
Dim a as Pippo
set a = new Pippo
a.Init(parametri_di_inizializzazione)
Questo sistema però può causare problemi, in quanto è possibile
dimenticarsi di chiamare Init o chiamarla più di una volta, con
risultati imprevedibili.
Per evitare questi problemi si può ricorrere al pattern Factory:
si mette l'implementazione della classe Pippo in una dll, si rende la
classe Public Not Creatable, si rende il metodo Init Friend in modo che
non sia visibile (e quindi utilizzabile) al di fuori della dll stessa,
si definisce una classe Factory (Public MultiUse o, io preferisco,
Global MultiUse), con un metodo:
public function New_Pippo(parametri_di_inizializzazione) as Pippo.
    dim tmp as Pippo
    set tmp = new Pippo
    tmp.Init(parametri_di_inizializzazione)
    set New_Pippo = tmp
end function
In questo modo il codice iniziale diventa:
Dim a as Pippo
Set a = New_Pippo(parametri_di_inizializzazione)
In pratica abbiamo "creato" un costruttore con parametri.
Spero di essere stato chiaro.


 Spero di essere stato chiaro.
tnk per la spiegazione !
Ma scusate non e' piu' corretto invocare appunto ogni metodo come
l' init separatamente ed esplicitamente ? So che come dici giustamente puo'
portare a sbagliare o a dimenticarsene, ma e' un errore del programmatore o
no ? Vabbe' io le classi in vb6 non le ho mai studiate , per me (pascaliano)
il metodo corretto dovrebbe essere :
Istanziamento
    inizializzazione + parametri
        utilizzo
    terminazione
distruzione + scarico
invece con sto "pattern Factory" si riduce tutto a
Istanziamento + inizializzazione + parametri
    utilizzo
poi ?  la terminazione e lo scarico come avviene ?
Grazie !
-- 
<Gigio2K>
Sito Comune
Nokia -> I.T.H.N. -> 
http://www.ithn.it/
VB -> I.C.L.VB -> 
http://www.it-lang-vb.net/

 poi ?  la terminazione e lo scarico come avviene ?
Questo non l'ho capito molto bene: il Pascal (non l'OP del Delphi) *non*
mi risulta avere oggetti...
Comunque, utilizzando il pattern Factory le cose non cambiano affatto,
in quanto tutto funziona come se l'oggetto fosse creato localmente.


Molto grazie. Un giorno ... forse lo userò :)
Diciamo pure che mi avrebbe - forse - fatto comodo
per questo progetto che sto scrivendo.
Dove ho praticamente scritto un'applicazione three tier.
Vb che si fa i caxxi suoi mostrandomi form e dati.
Una cariola di dll che si preoccupano di leggere/scrivere i dati
e restituirli dentro proprietà della classe stessa
SQL Server che mi fa da rdbs.
Beh le dll in realtà avrebbero bisogno di alcuni parametri
che imposto secchi appena l'istanziazione dell'oggetto dll,
tuttavia sono parametri variabili e non di vitale importanza
per la loro vita - nel senso che l'oggetto si crea ... e non
dipende da quei valori se non dal momento in cui deve
iniziare il dialogo con il db.
E come ogni buon programmatore ci ho schiaffato dentro
tanti bei controlli sulla presenza/assenza di paramentri
che mi scatenano un evento ErrorRaised ...
Vabè il resto frega poco ... era solo per dire.
--
Saluti
Andrea Moro

 che mi scatenano un evento ErrorRaised ...
Vedi, sono veramente poche le cose di cui si può fare a meno in un 
linguaggio di programmazione. In teoria bastano un'istruzione di 
salto ed una condizionale (if e goto) per fare tutto ciò che si fa
con linguaggi ben più completi e complessi.
Figuriamoci quindi se non si può fare a meno di costruttori con
parametri...
Solo che avere a disposizione un linguaggio più completo ti semplifica
la vita e diminuisce le possibilità di errore. E lo stesso discorso si
applica in questo caso. Tutti i controlli sulla presenza/assenza di
parametri che hai dovuto aggiungere per evitare errori sarebbero stati
superflui utilizzando il pattern Factory... e meno codice si scrive,
minori sono le possibilità di errore...
Ma, come scritto sopra, questo non significa che non se ne possa fare a
meno... è solo più rischioso e "faticoso".
