Newsgroup: it.comp.lang.visual-basic
Titolo: [PRB] Il compilato non va'.......

Ho un bel problemino....
Faccio il mio bel programma, ogni tanto lo testo, funziona anche nelle
situzioni simulate piu' critiche..... lo avvio anche con compilazione
completa ed e' Ok.......poi creo l'eguibile ,lo  faccio girare  e PUF !!!
bell'errore di protezione , non c'e' verso di far andare l'eseguibile mentre
in progettazione funziona perfettamente.
Sara' colpa della compilazione ?? lo compilo in p-code ma il risultato e'
sempre un bell'errore di protezione nel modulo user.exe piu' una serie di
cose per me incomprensibili.
A proposito.... c'e' nessuno che sa come interpretare quelle arcane
informazioni che vengono fornite su DETTAGLI quando compaiono questi errori
???
Io non so piu' che pesci prendere........anche perche' il programma e'
abbastanza corposo e scoprire l'istruzione che genera l'errore non mi sara'
facile..........
Grazie
Ciao
Ven.


Probabilmente la gestione degli errori di VB (On Error) in questo caso non
fa molto.
Potresti spargere di MsgBox il codice vicino al punto in cui avviene
l'errore, restringendo via via il campo di ricerca, finche' non trovi il
problema.
Comunque e' strano, le applicazioni VB non dovrebbero impiantarsi cosi'...
magari hai usato qualche funzione API?
--
Roal Zanazzi
z...@iol.it

 problema.
Infatti ho speso una nottata e prima di ogni istruzione VB ho inserito una
call ad una sub che mi scrive su un file :
Istruzione 1
Istruzione 2
istruzione 3
.................... ecc ecc ecc.
beccata l'istruzione che genera il GPF..... e' l'unload della form.......
cioe' dove scrivo :
unload me.
A questo punto sono giunto (erroneamente ??) alla conclusione che e' un
problema di allocazione memoria o sincronizzazione. Perche dico questo....
spiego brevemente [?] cosa fa la procedura :
Richiamo una DLL dove vengono processati una mole immensa di dati cosa che
provoca un tempo di elaborazione molto lungo. Nella form che chiama la dll
ho una bella progress Bar che indica naturalmente lo stato di avanzamento
dell'esecuzione della DLL. Inoltre vi e' un bel pulsante ANNULLA nel caso
l'utente si scassi di aspettare.
Per ottenere questo "scambio" interattivo e dinamico di informazioni tra la
form e la DLL ho usato questa tecnica.... (non cadete dalla sedia
.........;-)
1) Al richamo della DLL passo l'handle di una Text_Box invisibile della form
2) all'interno della DLL ogni 10.000 cicli con una SENDMESSAGE aggiorno
praticamente il contenuto di tale text_box :
SendMessage(address, %EM_REPLACESEL, 0, str$(zz))
dove address mi "punta" alla mia Text_box e dove zz rappresenta quanti dati
sono stati convalidati ad ogni blocco di 10.000.
Questo funziona perfettamente, infatti nelle mie prove rendendo visibile la
famosa Text_box della form vedo i relativi valori della var zz, inoltre con
tale valore e rispondendo all'evento Text1_Change (che si scatena ad ogni
sendmessage della dll) aggiorno la mia progress Bar.
Dico e puntualizzo che funziona perfettamente anche xche' se faccio girare
il tutto anche dal compilato ottengo l'esecuzione completa senza errori.
Il problema dove sta' ????
Premo il pulsante ANNULLA........
Alla pressione di tale pulsante ho una chiamata ad una ==>diversa<==  SUB
della stessa DLL del tipo :
call MyDllSub("*")
Nella DLL ricevo questo "*" e' lo passo ad una variabile dichiarata come
globale del tipo :
StopFunc = ValorePassato
sempre nella DLL ma nella SUB descritta sopra (quella insomma che mi
processa i dati) ho :
Sub Calcola(Address as Long) EXPORT
.
.
.
if StopFunc = "*" then
   zz = -1
   SendMessage(address, %EM_REPLACESEL, 0, str$(zz))    <== passo alla
text_box VB -1
   exit sub    <=== per chiudere l'esecuzione nella DLL
  else
    SendMessage(address, %EM_REPLACESEL, 0, str$(zz))  <=== stato di
avanzamento
end if
.
.
.
.
END SUB
e di controparte in VB ho :
Sub Text1_Change ()
if text1.text = "-1" then
   Doevents
   Doevents
   Doevents
   unload me
  set FElabora = Nothing
 else      <== in caso contrario in text1 ho il val. della var zz che mi da
lo stato di avanzamento
   istruzioni x la progress bar
endif
End Sub
ebbene in quel UNLOAD ME io ho il GPF !
per chiarezza aggiungo che se non "Stoppo" l'elaborazione" del calcolo ma lo
faccio girare fino alla fine, quando chiudo la Form in VB con :
Sub CmdEsci_Click()
        Unload me
         set FElabora = Nothing
End Sub
non ho nessun problema.
Non so' se mi sono spiegato, se siete caduti dalla vostra bella poltrona per
quanto avete letto o chissa' che.... ma per concludere, vi dico che il tutto
in VB3.0 funziona perfettamente da piu' di 5 anni in svariate installazioni
mentre ora che ho convertito il tutto in VB5.0 SP3 ho questo bel problema.
Inutile anche aggiungere che le varie chiamate alle API in questa
conversione VB3 ==> VB5 sono state rivedute e corrette adeguatamente.
Ciao
Ven.

end if
Prova a cambiare questo codice in questo modo ( usando La PostMessage() )
if StopFunc = "*" then
   zz = -1
   PostMessage(address, %EM_REPLACESEL, 0, str$(zz))    <== passo alla
text_box VB -1
   exit sub    <=== per chiudere l'esecuzione nella DLL
else
    SendMessage(address, %EM_REPLACESEL, 0, str$(zz))  <=== stato di
avanzamento
end if
Fai sapere se ha funzionato.
Salutoni
Ciao
By -MES-   Maronese Ettore
http://www.maronese.com/mes
(con OCX per stampare i recordset)
Sito Comune di programmatori Visual Basic
http://www.murialdo.it/it_lang_vb


------------
Francesco Beccari
frankb@I_HATE_SPAM_interplanet.it


L'idea non e' male e l'avevo gia' provata, l'unico problema (forse unico ?)
stava nel fatto che con la PostMessage l'applicazione VB rimane praticamente
bloccata fino alla fine dell'esecuzione della Sub nella DLL e la cosa mi e'
sembrata normale. Infatti la SendMessage attende che il messaggio sia
processato, la PostMessage lo invia e continua nell'elaborazione. Provero'
magari con la Postmessage e subito dopo a mettere qualcosa che simuli il
DoEvents di VB. Poi ti faccio sapere.
Cmq grazie per la risposta.
Ciao
Ven.

Ho perso un pezzo del thread... tuttavia:
una cosa BASTARDISSIMA che mi è successa (non mi ricordo se
con VB4-32 o VB5..) è che ho scritto un programma (tipo pippo.exe)
che usava una libreria (tipo pippo.DLL) e la cosa non funzionava...
Cambiando il nome alla DLL (o all'EXE) il problema si è risolto
(mi è successo un po' di tempo fa e quindi i dettagli non me li ricordo).
Comunque so che se l'EXE ed una DLL richiamata dall'EXE hanno
lo stesso nome, il programma all'interno dell'IDE di VB funziona, ma
una volta compilato come EXE stand alone non funziona più!.
Spero che la news ti possa servire.
Saluti, Massimo.


L'alternativa e' non chiudere il form al richiamo con SenMessage(-1), ma
alzare un flags (in VB) e, all'uscita della funzione della DLL, chiudere il
form.
Un'altro modo, sporcarello ma molto efficace, sempre in VB, e' di mettere un
timer nel form, enabled=false e intervall=1 (immediato), ed abilitarlo
(enabled=true) quando riceve SendMessage(-1). Poi nell'evento del Timer
scrivere Unload me. Questo posticipa l'unload ad un momento di _sicura_
calma, infatti l'evento timer viene scatenato quando windows non ha
soddisfatto TUTTI gli altri eventi, pure il WM_PAINT che ha una bassissima
priorita' ha una priorita' maggiore del timer.
Rifammi sapere ^__^


 processato, la PostMessage lo invia e continua nell'elaborazione.
[CLIP]
Dubito seriamente che tu possa chiudere la form col SendMessage.
Non ti so dire quale sia il motivo vero del crash, sicuramente sta in
qualche incastro strano, in qualche cosa che non viene eseguito nell'ordine
giusto o sotto il diretto controllo del VB. Forse richiami la DLL dal
medesimo form, e quando torna, il form e' stato deallocato e quindio si
inchioda, forse.
Per questo i miei consigli mirano a farti chiudere la finestra in differita.
Se proprio vuoi provarle tutte, prova anche queste:
- Richiama la DLL da un form diverso e se l'evento deve per forza essere
scatenato da quel form prova ad usare il trucco del timer, lo metti su
un'altro form e abiliti il timer, e nel timer richiami la DLL e si
auto-disabilita.
-Puoi provare ad ordinare ad una TextBox presente su UN'ALTRO form (es:
quello principale) di chiudere la famigerata finestra.
Ri-Salutoni


 wrote in message
7qep94$r7h$1...@aquila.tiscalinet.it...


 inchioda, forse.
Si.... credo che sia propro questo l'inghippo c'e' un maledetto problema di
sincronizzazione, ne parla anche DAN Appleman nel suo libro dove tratta la
SendMessage e la Postmessage.Il problema cmq l'ho risolto come tu suggerivi
giustamente, ossia alla pressione del tasto stop, notifico alla DLL di
chiudere ed accendo un flag in VB. Come ritorna il controllo alla mia
applicazione VB testo tale flag e se e' acceso chiudo la form. Funziona
senza nessun problema ora.
Grazie di nuovo e a buon rendere........
Ciao
Ven