Newsgroup: it.comp.lang.visual-basic
Titolo: VB e il bug fantasma

Ciao a tutti,
sono uno sviluppatore DISPERATO che sta confezionando in VB6 (service pack
5) un'applicazione per l'archiviazione documentale e che, dopo essersi
gongolato dei risultati dell'esecuzione in ambiente di sviluppo, ha avuto la
malaugurata ventura di compilarla...
L'applicazione è costituita fondamentalmente da:
- eseguibile standard (interfaccia utente): referenzia il modello ad oggetti
dell'activeX dll;
- activeX dll (modello ad oggetti business e transazione dati).
Eseguendo i compilati si è verificato un crash. Vabbè, può succedere. Ho
inserito tra le righe del codice una rozza serie di chiamate msgbox a guisa
di punti d'interruzione (test-steps) per verificare passo passo il codice
compilato.
Quando però ho isolato l'istruzione oltre la quale si verificava l'errore
("Select Case Element.Attributes.Class") e ho collocato ulteriori test-steps
profondi negli oggetti che venivano richiamati in questa stessa istruzione
(Element, Attributes, Properties e Property), è successo l'incredibile:
eseguendo il compilato e giunto a quella stessa istruzione ("Select Case
Element.Attributes.Class"), l'esecuzione è proseguita correttamente nei
nuovi test-steps profondi (all'interno degli oggetti di classe Element,
Attributes, Properties e Property); lo stack è tornato poi a puntare
sull'istruzione incriminata ("Select Case Element.Attributes.Class") e l'ha
superata tranquillamente senza che si verificasse alcun errore!!!
Riassumendo:
- l'esecuzione non compilata (quindi all'interno dell'ambiente di sviluppo)
funziona senza problemi;
- l'esecuzione compilata ha due comportamenti opposti:
--- senza punti d'interruzione nel codice la dll va in crash;
--- con punti d'interruzione sul medesimo codice la dll funziona
correttamente!
E' assurdo!!!
Questo comportamento mi sta letteralmente facendo impazzire...
Preciso che il codice è stato scritto rispettando meticolosamente i principi
di programmazione orientata agli oggetti applicabili in VB6; in particolare,
l'incapsulamento di variabili è stato massimo (NON esistono variabili
pubbliche: tutte sono private a livello di modulo o di routine). Inoltre, il
codice non implementa nessuna operazione asincrona o subclassing. Utilizza
esclusivamente la libreria ADO 2.6.
Sono in uno stadio di pura afflizione senza via d'uscita che mi fa implorare
una vostra risposta.
Grazie
Stefano

 Questo comportamento mi sta letteralmente facendo impazzire...
Ti credo, ma non è necessariamente assurdo. E' sicuramente una palla trovare
il problema.
Può essere che i tempi diversi di esecuzione (tamponati/bloccati anche in
EXE con MsgBox) scatenino situazioni diverse (per esempio eventi che si
avvicendano in sequenze diverse).
Vedi anche se hai qualche DoEvents non proprio necessario e anche se
qualcuno deve esserci e invece manca.

 compilato.
[SNIP]
Crash in che senso? errore di runtime o erroraccio tipo GPF e affini?
Come tentativo, prova intanto a fare un'altra cosa simile ma che altera meno
il flusso standard del programma (l'interruzione in piu' dovuta ai MsgBox);
prova cioe' a scrivere i vari step in un file di log e verifica se il
comportamento e' lo stesso...
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 Questo comportamento mi sta letteralmente facendo impazzire...
.........
"Principi di fisica quantistica applicati al VB", sottotitolo:  "finchč si
guarda il bollitore l'acqua non bolle":
Probabilmente questo mio post non ti aiuterą molto, ma sappi che ti capisco
bene...
Tempo fa feci un programmino in VB costituito da EXE + OCX, che, una volta
compilato, quando terminava mi dava un bel GPF
dopo aver inutilmente cercato l'errore, armato di pazienza misi una serie di
msgbox "1", msgbox "2" per capire quale fosse la linea che causava il
problema.
Ma inaspettatamente in questa versione il mio programma funzionava bene e
non dava nessun errore. Visto che i tempi di sviluppo erano stringenti
tolsi i msgbox "1" - msgbox "N-1" e sostituii il msgbox "N" con msgbox
"Termine applicazione"... PERFETTO !!! :)
Il programma in questione ora viene utilizzato ancora e non ha mai dato
problemi di sorta.
Davide

 comportamento e' lo stesso...
Buona idea: provero' quanto prima.
Grazie!
Stefano

 qualcuno deve esserci e invece manca.
L'esecuzione, devo precisare, e' assolutamente sequenziale: anch'io ho avuto
il sospetto che potesse essere qualche evento malizioso, ma eliminando
quell'unico evento MoveComplete del recordset ADO la storia non e' cambiata.
Sembra qualcosa di sfuggente ed impalpabile...
Stefano

 "Termine applicazione"... PERFETTO !!! :)
Cos'e', una burla?
Spiegati meglio, per favore.
Stefano

 Spiegati meglio, per favore.
Forse intendeva:
... con msgbox "Operazione terminata!"
Trasformi il tuo msgbox di debug (che evita il verificarsi dell'errore) 
in un messaggio all'utente ... ;-)
Questo ovviamente puoi farlo solo se il punto in cui puoi inserire il 
msgbox che evita l'errore e' molto vicino (temporalmente) al punto in 
cui la procedura termina.
ciao
		maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!

 
Hai installato le ultime versioni dei service pack?
Per vb6 e' la sp5!


 Buona idea: provero' quanto prima.
Com'e' andata la prova?
Lokar.curioso
--
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt

 Com'e' andata la prova?
Cattive notizie ragazzi: il compilato a cui ho tolto gli step MsgBox e ho
aggiunto i logging a file e' morto ancora nello stesso crash! Possibile che
Microsoft abbia fatto strade cosi' insicure?
Voglio rientrare in Matrix! Mi sono stufato di mangiare proteine predigerite
e scrivere codice instabile.
Stefano

 Per vb6 e' la sp5!
Esattamente quella che sto usando!
E questo mi fa ancor di piu' imprecare.
Stefano

 cui la procedura termina.
Purtroppo non e' il mio caso: l'errore fatale si verifica nel bel mezzo di
un oggetto utilizzato nel corso di tutta la sessione d'esecuzione.
(che tristezza!)
Stefano

 e scrivere codice instabile.
http://whatisthematrix.warnerbros.com/rl_cmp/reloaded_trailer_320.html
Lokar


 funzioni, in modo da forzare l'attesa del valore di ritorno.
Questa mi piace molto!
In caso di problemi, ovvio.

 ha scritto nel messaggio
news:3d915...@news.dada.it...


 funzioni, in modo da forzare l'attesa del valore di ritorno.
Empiricamente curioso... ma non dovrebbero essere gia' trattate
sequenzialmente anche le invocazioni alle sub?
Fammi sapere!
Stefano

 .... e se invece dei msgbox, provi con un log su file per il debug ?
Come potrai constatare leggendo il sub-thread di Luca Dormio, anche questo
tentativo e' stato inutile...
Stefano

 malaugurata ventura di compilarla...
Ciao a tutti,
sono uno sviluppatore FELICE che sta confezionando in VB6 (service pack
5) un'applicazione per l'archiviazione documentale e che, dopo essersi
gongolato dei risultati dell'esecuzione in ambiente di sviluppo, ha avuto la
malaugurata ventura di compilarla...
...ma ha appena trovato la SOLUZIONE (e per questo sta godendo come un
riccio!) che, come tutti i rompicapi che si rispettino, e' molto piu'
semplice di quello che sembrava...
Compilazione nel buon vecchio p-code!!!
Questo suggerimento mi e' stato dato da Francesco Balena, celeberrimo
redattore di Infomedia e collaboratore dell'altrettanto celeberrimo sito
VB2theMax, da me contattato tramite mail pubblica. Lo ringrazio ancora!
Certo, piu' che una soluzione definitiva e' un paliativo... ma vedeste come
cammina sicuro sulle sue esili gambette non ottimizzate! Non inciampa mai.
Altroche' codice nativo: chi va piano va sano e va pure lontano!
Stefano
Fine del thread!
(e tutti vissero felici e contenti...)

 
Ciao.
Sperando che la cosa possa essere utile ti racconto una mia esperienza
dell'anno scorso con un problema simile, cioč un programma che
funzionava nell'ide e non compilato.
L'istruzione era dentro una with, come succede a te. E' bastato togliere
la with, indicando esplicitamente l'oggetto nelle righe incriminate e
tutto č andato a posto. Ovviamente un sacco di altre with in altre parti
del codice funzionavano senza problemi.
Non credo che il problema sia nel codice che hai scritto, ma nella
compilazione.
Sempre per esperienza prova a compilare cambiando il tipo di
ottimizzazioni, oppure generando il p-code invece che un compilato vero.
Se il comportamento cambia, cioč in alcuni casi si pianta e in altri no
hai a che fare con una bizzarria di VB e devi trovare una scorciatoia
tipo quella che ti ho descritto.
Hope this helps,
	Pepo

 sequenzialmente anche le invocazioni alle sub?
"Teoricamente" si. "Empiricamente" VB non aspetta! Ho riscontrato casi
in cui, viene assegnato da VB un valore ad una variabile "diciamo"
pubblica della DLL e subito dopo viene invocata una funzione presente in
tale DLL che fa uso della variabile... A volte l'esecuzione della
funzione avveniva prima che fosse fatta l'assegnazione generando errori
madornali!
Lokar
P.S. "La teoria e' quando si sa tutto e niente funziona. La pratica e'
quando tutto funziona e nessuna sa il perche'. In questo caso, abbiamo
messo insieme la teoria e la pratica: non c'e' niente che funziona... e
nessuno sa il perche'!" (A. Einstein)
