[Visual Basic 6] Debug applicazioni

[Quentin80]

Ciao a tutti, ho una domanda per voi.
Io sviluppo sw con Visual Basic 6 (so che è vecchio ma è l'unico che abbiamo) e spesso mi capita di avere degli errori sui pc dove vado ad installare i pacchetti.
Volevo sapere se esiste un sw che mi permette di eseguire il debug del sw sui client senza dover per forza installarci VB6 e i file sorgenti del progetto.

Grazie

[MarcoGG]

Ciao a tutti, ho una domanda per voi.
Io sviluppo sw con Visual Basic 6 (so che è vecchio ma è l'unico che abbiamo) e spesso mi capita di avere degli errori sui pc dove vado ad installare i pacchetti.


Le cause di questi errori possono essere davvero tante, basti pensare all'utilizzo di DLL di sistema esterne, che, a seconda delle postazioni e relativi S.O. installati, possono essere di versioni molto differenti tra loro, o addirittura non esistere proprio. Oppure chiamate ad API Windows, pratica a cui in molti casi con VB6 si è praticamente costretti. Ho sentito spesso di chiamate API che ad esempio in WinXP 32bit funzionano perfettamente, ma poi passando a Vista o Win7, o comunque S.O. 64 bit danno problemi...
O ancora potrebbe trattarsi di semplici errori logici, e se non si è fatto un test approfondito di tutti i casi di utilizzo in fase di progettazione, saltano fuori solo quando gli utenti finali fanno qualcosa di particolare.
Il primo grande passo che potete fare, se già non l'avete fatto, è di aggiungere una bella dose di codice di controllo ( purtroppo in VB6 non c'è Try Catch come in VB.NET ) in tutti i punti in cui si prevede che qualcosa possa andare storto, e mostrare MsgBox con descrizioni significative sulla causa dell'intoppo.
Il che, purtroppo trattandosi di VB6, significa avere a che fare con i vari "On Error GoTo...".

[Quentin80]

Credo che il mio problema dipenda da un'impostazione del programma ma non so come fare con "on error go to".
Mi spiego... in un certo punto del programma uso una griglia "True dbgrid" e quando vado a scrivere i dati nel db SQL su alcuni pc mi da l'errore "Error 13. Type mismatch", ma non riuscendo a riprodurlo sulla stazione di sviluppo non riesco a capire dove cavolo si impasta il programma.
Per questo sono alla disperata ricerca di un debugger da installare sul client senza dover per forza installare tutto il Visual Studio

[MarcoGG]

Credo che il mio problema dipenda da un'impostazione del programma ma non so come fare con "on error go to".
Mi spiego... in un certo punto del programma uso una griglia "True dbgrid" e quando vado a scrivere i dati nel db SQL su alcuni pc mi da l'errore "Error 13. Type mismatch", ma non riuscendo a riprodurlo sulla stazione di sviluppo non riesco a capire dove cavolo si impasta il programma.
Per questo sono alla disperata ricerca di un debugger da installare sul client senza dover per forza installare tutto il Visual Studio

True DbGrid è un prodotto a sè, non fa parte di VB6. Se la causa del problema è lui, la vedo dura in debug.
Non penso esista un debugger così, capace anche di entrare nel merito di errori generati da librerie di terze parti...
Un'alternativa potrebbe essere di avere qualche macchina virtuale con VB6 installato e stesso S.O. dei Pc dove l'applicativo ha dato problemi.

[Quentin80]

Non so se con una VM riuscirei a risolvere il problema... purtroppo mi varia a seconda delle configurazioni.
Infatti su Windows Xp con SP3 non va, mentre su Xp con SP2 va solo su alcuni pc e su altri no.
Infine se installo Visual Basic sul pc per fare il debug, il problema sparisce.
Il bello è che i pc hanno tutte le dll e gli ocx necessari.
A questo punto credo che sia una dll che ha una versione più recente sui pc che non funzionano... mi sa che sarà una caccia al tesoro.
Al momento ho risolto installando e poi disinstallando VB6 dal client.

[MarcoGG]

Infine se installo Visual Basic sul pc per fare il debug, il problema sparisce.
Il bello è che i pc hanno tutte le dll e gli ocx necessari.
A questo punto credo che sia una dll che ha una versione più recente sui pc che non funzionano... mi sa che sarà una caccia al tesoro.
Al momento ho risolto installando e poi disinstallando VB6 dal client.

Benvenuto nel Dll Hell, :D .
Per questo hanno poi inventato l'embedding...
Hai pensato ad una migrazione su VB.NET ? Grazie al namespace Microsoft.VisualBasic potrebbe anche essere "indolore" ( dico -potrebbe- ).

[Quentin80]

Effettivamente io e il mio capo ci stavamo pensando anche perchè dovendo passare per forza a Windows 7 le applicazioni sviluppate con VB6 potrebbero avere dei problemi.
Il problema è che sarà un calvario dato che sono applicazioni abbastanza complesse e molto articolate (si sono molti menù e sottomenù) che si collegano anche con il gestionale aziendale.
Mah speriamo bene... cmq grazie per il supporto :)

[Quentin80]

Un'ultima domanda... esiste un sw in grado di convertire codice VB6 in codice di Visual Studio evitandomi di riscrivere da zero tutto?

[MarcoGG]

Un'ultima domanda... esiste un sw in grado di convertire codice VB6 in codice di Visual Studio evitandomi di riscrivere da zero tutto?

Bella domanda. :D
Rispondo sinteticamente così :

1. La miglior conversione del mondo è quella che può fare l'essere umano.

2. Inizierei con qualcosa di valido e disponibile già come componente di VB 2008 ( sicuramente nella versione Pro, ma credo proprio anche in quella Express, che è 100% Free ) : Il Visual Studio 2008 Upgrade Wizard.
Dai un'occhiata qui, per cominciare :
http://www.codeproject.com/KB/vb/VB6ToVBNET.aspx
La filosofia di utilizzo, in soldoni è : faccio fare a VS, e poi magari ci metto una pezza io...

3. Prodotti Free e ( soprattutto ) a pagamento ce ne sono sicuramente, in ogni caso considera che il codice .NET prodotto in uscita non è certo "oro colato", anzi...

4. Migrare soluzioni da VB6 a VB.NET ( o C# che sia ) garantendo al 100% funzionamento, prestazioni e quant'altro è un lavoro, nel senso che c'è chi ci lavora, e in alcuni casi può essere più oneroso che non buttare tutto e rifare da capo.

5. Il "vantaggio", passando da VB6 a VB.NET, è che comunque, come già accennavo, la presenza del namespace Microsoft.VisualBasic risolve in automatico molte situazioni spiacevoli. Detto questo, non accetterei MAI di gestire un array "alla VB6", all'interno di un progetto VB.NET... :p