Newsgroup: it.comp.lang.visual-basic
Titolo: End che manda in crash

Vi ricordate quella discussione sull'end che termina il programma in modo
potenzialmente pericoloso?
Mi è successo.
Un programma con l'End nell'unload di frmMain
"QUESTO PROGRAMMA HA ESEGUITO UNA OPERAZIONE NON VALIDA"
Insomma, quando affrontammo la discussione a nessuno l'End aveva mai dato
problemi....
Mai dire mai...-----

Programma da otto anni in Visual Basic e non mi è mai successo una cosa del
genere...sai il motivo di questo??
Non l'ho mai usata da sola....!
L'istruzione End in realtà non termina completamente l'applicazione, ecco
perchè può andare in crash...è stata sempre sconsigliata, ma se prima
dell'end utilizzi unload nomeform, vedrai che funzionerà tutto.
--------------------------------
Inviato via 
http://usenet.libero.it

 Mi è successo.
*Gigio insabbia questo post....*
Allora che si fa ? Usciamo ? Un giro in centro ? ^_-
'Nnaggia che sfiga , cmq come detto da alterx :
Prima "unload all " e poi END !
E' + una mania che altro , come dire :
'Per favore scarica tutto
    unload frm*
'hai finito a scarica che mo scarico io tie'
    END

 L'istruzione End in realtà non termina completamente l'applicazione,
Strano, dovrebbe...
Ed é proprio per quello...
Hai usato API per subclassing/callback di sistema? In tal caso avresti il
sistema operativo che continua a puntare alla memoria del tuo programma
anche dopo che viene terminato (se non rilasci completamente con le apposite
API)...
            Ciao
                                    Allanon
--
- SPAMKILLER
 L'indirizzo delle risposte é 
itlangv...@michele.sytes.net
 LASCIATE il NOSPAM fa parte dell'indirizzo :-)
  Per superare le impostazioni di protezione antispam scrivete
  nel testo del messaggio la scritta "SPAMKILLER"
Scusate il disturbo, ma non posso più di pubblicità

     END
Ovviamente era quello che facevo io.
:-)

 perchè può andare in crash...
A me risulta il contrario
Cito da MSDN
L'istruzione End rappresenta un metodo per forzare l'interruzione del
programma. Per interrompere normalmente un programma Visual Basic, è
necessario scaricare tutti i form. Il programma verrà chiuso quando non vi
sono altri programmi con riferimenti attivi agli oggetti creati da moduli di
classe pubblici del programma e quando non vi è più codice in esecuzione.
Inutile dire che ovviamente scarico tutti i form prima dell'End.
Comunque mi è bastato toglierlo per risolver eil problema


Che service pack hai di visual basic?
A me č capitato quando lavoravo con il VB5 il problema dovrebbe essere stato
risolto con il VB6 Spk3
Ti dico dovrebbe perchč da allora non me l'ha fatto piů
Ciao


David Ruscelli (Office) ha scritto:

Bene, mai dire mai, ma a me non è mai successo.
Piuttosto, da quando, ho preveventivamente inserito (pur mantenenedo l'End)
l'Unload delle varie forme dell'insieme Forms, ho scoperto che questo spesso
e volentieri, ma non sistematicamente, ne riporta alcune per nulla load-ate
o, comunque, regolarmente unload-ate, come se ci fosse un ritardo
nell'aggiornamento dell'insieme stesso. Ho risolto facendo l'Unload solo per
le form con Visible=True e, come dicevo, con l'End finale.
Aggiungerei (sono sempre malfidente sulle affermazioni di M$) che non credo
che l'End faccia quel che si dice, non sempre, almeno. Non ho prove ed è
solo un'ipotesi, ma temo che se l'End viene eseguito quando c'è qualche
evento/operazione che parte (come un Timer che si attiva), il sistema si
incastri da sè e, per non saper nè leggere, nè scrivere, produca quei
simpatici messaggi, come dire "io non so risolvere i miei intrecci, cavoli
tuoi, arrangiati". Ovviamente riprovi e tutto funziona. Sino alla prossima
volta.

e, come dicevo, con l'End finale.
Se scarichi bene e' inutile. Io non lo uso da anni e ti garantisco che
non mi rimane "appeso" niente (crash a parte ;-)
-- 
ciao, hal

 Non e' necessario, anzi, dannoso ;-)
A parte che mi risolve quei casi che dicevo, perchè un "If f.visible
then..." (dove f è un elemento che l'insieme mi restituisce) sarebbe
dannoso?

dannoso?
Perche' se f.Visible == FALSE allora non la scarichi :-(
-- 
ciao, hal

 Perche' se f.Visible == FALSE allora non la scarichi :-(
Verissimo, ma io, come ti dicevo, non la devo scaricare, perchè non c'è.
Se lo faccio ottengo un errore. Ancora e solo perchè non c'è.

 Ancora e solo perchè non c'è.
Se fosse vero che tale form non c'e', impostando .Visible allora
verrebbe caricato e quindi scaricato dal comando di Unload.
Ripeto, a costo di risultare antipatico: il problema e' nel codice.
Insisto perche' sono stato chiamato spesso al capezzale di programmi
che non volevano morire ed il problema stava nel codice. Il guaio e'
che spesso e' difficilissimo trovare l'inghippo.
Di solito pero' si tratta di codice piazzato nello scaricamento del
form che cerca di accedere a proprieta' intrinseche e/o controlli di
altri form (pratica da evitare con cura in tale evento) oppure di
riferimenti circolari.
In questi casi un log sugli eventi Initialize e Terminate puo' fare
miracoli.
-- 
ciao, hal

 che spesso e' difficilissimo trovare l'inghippo.
OK, non penso che tu lo faccia per "bastian contrario". Che vantaggi
avresti?
Però permettimi di insistere, con certo per aver ragione a tutti i costi, ma
per le ricerche che a suo tempo avevo fatto dando, in primis, la colpa al
mio codice: Perchè se tolgo l'End, e persino l'esplicito Unload (ovvero il
blocchetto di istruzioni che hai scritto) il programma termina regolarmente
e nulla resta "appeso"?
Io penso, non insisto (però mi sembra un'ipotesi plausibile, se ne son viste
tante...), che l'insieme Forms non venga aggiornato in tempo reale, quindi
se anche un regolare (naturale o richiesto) Unload di un form
dell'applicativo viene attivato ed eseguito regolarmente (persino concluso),
il form è di fatto inesistente, ma l'insieme Forms ancora lo cita. Immagina
che subito dopo quell'Unload si esegua il codice che hai scritto. E'
possibile (secondo la mia ipotesi) che il ciclo restituisca un f (uno degli
Each) che è nell'insieme, ma non corrisponde a un form ancora presente,
quindi l'istruzione Unload f genera l'errore. Naturalmente, non in modo
sistematico, ma questo è ... "by design".

 Però permettimi di insistere, NON certo per aver ragione a tutti i
costi...

 :-)
Azz , ma allora non c'e' proprio modo di capire cosa rimane "appeso" anche
quando tutte le form sono stati scaricati  ?

 miracoli.
le soluzioni + semplici sono sempre quelle + difficili da trovare ! ^_^
Grazie della preziosa info , credo che mi sara' molto utile anche se l'end
ancora non mi ha dato nessun problema !
un satuto da EFUG.Gigio2k(*)
*EFUG = End-Friends User Grup

quindi l'istruzione Unload f genera l'errore.
Mi viene da pensare che l' Unload di un form chiami l'unload di altro
form che, qualora quest'ultimo si trovi immediatamente dopo
nell'insieme Forms, invalidi il riferimento. Cio' e' possibile perche'
il ciclo For legge il proprio limite solo all'inizio del loop.
Probabilmente puoi definitivamente risolvere cosi':
While Forms.Count
	Unload Forms(Forms.Count)
Wend
In questo modo ad ogni giro viene riletto il valore di Count che
puo' allegramente decrementare di n anziche' di 1 senza fare una
piega.
Prova e sappimi dire ;-)
-- 
ciao, hal

 Prova e sappimi dire ;-)
Mi par di capire, particolarmente per l'ipotesi (piů che realistica) che hai
fatto, che anche tu non escluda qualche potenziale pasticcetto nella
gestione interna dell'insieme Forms. In ogni caso il codice prima scritto io
lo eseguo solo e soltanto quando tutte le form sono state scaricate,
l'operatore ha chiuso tutte le finestre e sta chiudendo la principale (non
nel senso di MDI, che non uso) e io intendo chiudere l'intero applicativo
mettendo quelle istruzioni alla fine dell'evento Unload dell'ultima form e
prima del mio End "di sicurezza".
Quando tu dici "ad ogni giro viene riletto...", non escludo che possa essere
risolutivo per i saltuari problemi che ho riscontrato, ma, ancora, ipotizza
che quell'insieme venga gestito un po' alla carlona dal sistema e/o da VB.
Infatti, se tutto funzionasse a dovere, in quel punto e momento, che motivo
ci puň essere per cui ... Each Forms debba/possa essere diverso da
Forms.Count visto che non sta accadendo piů assolutamente nulla?
A meno che, appunto, l'insieme venga gestito "in ritardo". All'inizio del
ciclo ha un limite massimo, congelato a mo' di contatore per il ciclo
stesso, e, mentre lo si scorre, gli effetti di un Unload "ritardato" si
riflettano sui singoli elementi dell'insieme, sino ad incappare in quello
che "c'č, ma non ha piů una corrispondenza".
Comunque, proverň, magari cercando di "riprodurre" il problema con le
istruzioni attuali (la vedo dura perchč a suo tempo non c'ero riuscito) e
poi a ripeterlo con la tua proposta.

gestione interna dell'insieme Forms.
Cerco di spiegarmi meglio, analizzando il seguente codice:
10: Dim f As Form
20: For Each f In Forms
30:	Unload f
40: Next f
Alla riga 20 vb costruisce una collection di Forms.
Supponiamo che contenga i form A, B, C e D.
Viene quindi assegnato impostato in f il riferimento verso A.
Alla riga 30 comandi lo scaricamento di f (che punta ad A).
Supponiamo che A contenga l'istruzione 
	Unload B
e che venga eseguita correttamente distruggendo B.
Il form A conclude quindi il proprio scaricamento.
Il loop passa alla riga 40 e risale alla 20 spostando il puntatore f
al successivo elemento di Forms che e' (o era?) B.
L'istruzione For non esegue il refresh della collection Forms,
cosi' come non rileggerebbe l' upperbound di un array, ad esempio.
f adesso punta ad un form (il B) che non esiste piu'!
Cosa ne pensi?
-- 
ciao, hal

 Cosa ne pensi?
Hal, penso che sei stato chiarissimo, ma io non ho una beneamata form
aperta/load-ata quando avvio quel ciclo... che sta nell'unload dell'ultima
form che l'operatore ha chiuso, quindi, anche se quello che hai scritto è
assolutamente giusto, non corrisponde alla realtà che ho tentato di
descrivere, ovvero io non mi aspetto che avvenga alcun unload e, nel tuo
esempio, alcun "unload dell'unload". Di form non ne ho manco una, sono già
state tutte unload-ate. Io penso che lui, l'insieme Forms, non ne abbia
ancora preso atto. Tutto qui. Rivedi la parte finale del mio post
precedente.

 quando tutte le form sono stati scaricati  ?
Sembrerebbe comunque un problema del S.O
su win95 il problema si verifica su win98 non si verifica

 su win95 il problema si verifica su win98 non si verifica
umm umm , non vorrei sparare cavolate come al solito ma ... non sara' come
sosteneva lupo un problema di "tempo" di aggiornamento ?
cioe' io credo che se si attua il metodo
foe each form ...
    unload form...
next
END
io credo che mettendo un ciclo con una 50 di doevents la situazione
dovrebbe/potrebbe migliorare !
Non vedo l'ora che mi dia problemi l'end cosi faccio un po di prove !

 quando tutte le form sono stati scaricati  ?
Spesso si tratta di oggetti con riferimenti ciclici...
Se si sono create delle classi che in qualche maniera (diretta o indiretta)
si fanno riferimento l'un l'altra...
Tipo gli oggetti di tipo A hanno un riferimento ad una collection che li
contiene tutti...
I programmi COM non riescono a risolvere questi casi...


 Ancora e solo perchè non c'è.
Quello che vuole dire hal e' che *non e'* con la proprieta' Visible che vedi
se un form e' scaricato, anzi, verificando il valore di tale proprieta'
(ovvero, accedendo ad una proprieta' qualunque di un form _gia'_ scaricato)
_carichi nuovamente_ il form in memoria. E' un comportamento "by-design" dei
form.
Il modo giusto di verificare se un form e' scaricato e':
    If Not frm Is Nothing Then
        Unload frm
    End If
hth,
Lokar
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
UGIdotNET - 
http://www.ugidotnet.org

     End If
Questo mi sta bene e proverň, grazie.
Per il resto credo di essermi espresso chiaramente nei vari post, che mi si
creda o no, a me č successo.