Newsgroup: it.comp.lang.visual-basic
Titolo: Debug e comportamenti strani....

Salve ragazzi....
Sto realizzando un progetto composto da diverse Dll.... e  da qualche giorno
dopo alcune semplici modifiche (ho rinominato e ricompilato alcune classi)
non riesco più ad eseguire un debug del progetto in modo efficiente....
Mi Spiego meglio:
    mi trovo nella Dll A ---> arrivo all'istruzione che mi richiama un
metodo pubblico della Dll B.
Qui si presenta il problema:
    premendo F8 (in fase di Debug) non entra nel codice della Dll B ma mi
restituisce subito il risultato
    della computazione senza uscire dalla Dll A!!!!
Io ho bisogno di fare un Trace Della routine nella Dll B ... perchè non me
lo fà fare?
Il Problema ha a che fare con il modello Appartment threading?
Oppure devo seguire una procedura specifica....
Il fatto è,  che in precedenza il Debug riuscivo a farlo... ora non capisco
dove è il problema...
Grazie a tutti per l'aiuto!.

     della computazione senza uscire dalla Dll A!!!!
Se la DLL è fra i riferimenti, è possibile che venga eseguita quella che,
essendo compilata, non ti da' il debug. Prova a toglierla dai riferimenti e
a inserire il modulo sorgente (cls) nel progetto. Quando tutto è a posto,
chiaramente, sarà fra i riferimenti e il codice "vivrà per conto suo", ai
soli fini della compilazione per produrre la DLL

 a inserire il modulo sorgente (cls) nel progetto.
Meglio ancora
apri due istanze di VB una con il progetto A, l'altra con il progetto B;
manda in esecuzione B, quindi apri la finestra riferimenti di A e seleziona
la voce corrispondente a B, assicurandoti che sia mostrato in basso il
percorso del vbp, non della dll.
Ora esegui normalmente il debug, il flusso del programma passera' da un
istanza all'altra
Ciao
--
Luca Dormio - 
luca....@tin.it
________________________________
"Marty, non stai ragionando in maniera quadridimensionale"
Dr. Emmett L. Brown

 ha scritto nel messaggio
news:ajagqr$19mb7l$1...@ID-138791.news.dfncis.de...


 non riesco più ad eseguire un debug del progetto in modo efficiente....
Il problema si presenta quando rompi la compatibilità con la vecchia dll.
Per le DLL è molto più comodo fare un gruppo di progetti, per gli ActiveX
exe è d'obbligo usare due istanze diverse di VB, ma il concetto non cambia.
Windows associa un CLSID a ogni ActiveX, VB si riferisce a questo CLSID per
sapere quale oggetto trattare.
Se la classe con il CLSID è in debug VB si appoggerà a questa (poichè è a
tutti gli effetti in esecuzione), altrimenti lancerà quella compilata.
Rompendo la compatibilità si cambia CLSID, quindi si cambia il riferimento
del progetto.
Le soluzioni sono varie, puoi ad esempio impostare la compatibilità binaria
della dll, e comunque ogni volta che cambi compatibilità devi
-ricompilare la DLL.
-aggiornare il riferimento al progetto principale.
Ciao
--
y = f(
http://neodatatype.interfree.it/index.html
)

 ha scritto nel messaggio
news:TOr69.209536$Jj7.4...@news1.tin.it...


 Vi ringrazio ancora una Volta!
Però (chiedo scusa), anche se una DLL (come tale, compilata, non come modulo
sorgente) è correttamente integrata nel progetto, mica ti consente il debug
passo-passo.
O mi sono perso qualcosa? Ditemeloooooooooooooo!

 O mi sono perso qualcosa? Ditemeloooooooooooooo!
Dunque, lo dico terra terra (perchč non saprei esprimermi meglio :P )
Prendiamo un gruppo di progetti: Project1.vbp e MyDll.vbp
Project1.vbp referenzia MyDll.dll, perň MyDll.vbp č compatibile con la sua
dll (cioč ha lo stesso CLSID).
Quando si avvia Project1 (progetto di avvio) VB si "accorge" che ha
sottomano il codice di MyDll e fa partire prima questa, istanziano in
memoria il codice di cui si dispone del sorgente.
Da qui a eseguirne il debug č facile :)


 Da qui a eseguirne il debug è facile :)
Chiaro: Il codice sorgente, da qualche parte nel gruppo di progetti, c'è e
quindi viene "visto" ed eseguito anche passo-passo.