Introduzione

Il Visual Basic e' uno schifo.
Se volete giocarci un po' e farci il programmino per far vedere agli amici che sapete programmare, va bene. Ma se dovete affrontare un progetto complesso o importante, cambiate decisamente rotta. C'e' il Delphi, c'e' il C++ standard... Fatevi un favore, lasciate perdere il VB.

Se invece siete come me, e per guadagnarvi il pane dovete proprio usare il VB, allora accettate i consigli che seguono.

Buona lettura.

Motivazioni

Perche' il VB non mi piace? Non e' che non mi piaccia. E' che non e' ben tipizzato. E questo e' un problema molto grave.
Assegnare o confrontare variabili di natura diversa non genera errori di compilazione. Allora il team di sviluppo, dove magari sono presenti due o tre elementi inesperti, dissemina 'imprecisioni' per tutto il codice, che non verranno rivelate in compilazione, e spesso nemmeno in test, ma prima o poi metteranno sotto il naso del cliente una bella palla rossa con una X bianca.

I sostenitori del VB mi dicono: "Guarda che il VB supporta il late binding".
E' una stupidaggine, si puo' parlare di late binding per esempio per le variabili Variant, ma se assegno una stringa ad un intero, e' una conversione nascosta e truffaldina, non un onesto late binding.

Ho anche letto dei libri sul VB perche' credevo che il mio rifiuto derivasse da una scarsa conoscenza dell'ambiente. Invece l'approfondimento ha confermato in pieno le mie idee. Specialmente un libro della Microsoft Press, che si arrampicava sugli specchi per cercare di dimostrare che il VB e' un linguaggio orientato agli oggetti. Mi ha fatto talmente ridere...
Ancora qualcuno mi ha detto: "Non dare la colpa al VB, sei tu che non sei capace a programmare". Non sono certo un genio, ma quelli "bravi a programmare" in VB sono quelli che ne sanno aggirare le limitazioni, invocando API e usando trucchetti contorti. Ho visto su un sito uno VBscript che inviava per FTP un file e lo recuperava di nuovo per capire se il trasferimento era andato bene. Io invece ho preferito usare le API della Wininet.dll.

Ma poi, andiamo, non ha un make, ricompila sempre tutto, non ha warning, se non premi CTRL-F5 non ti dice neanche gli errori.
E' proprio un giocattolo.
Le classi non hanno costruttore e non supporta l'overloading. Ridicolo.

E poi una cosa che mi manda in bestia: definisci una form di nome MyForm.frm, no? Dopodiche' puoi scrivere
MyForm.Show
oppure puoi dichiarare:
Dim f as MyForm
Ma allora MyForm cosa #*! e'?

Questo non vuol dire che uno bravo non ci tiri fuori qualcosa di buono. L'editor cEdit (vedi sotto) e' veramente ben scritto.
Io stesso ho fatto delle automazioni in VBScript che richiamano oggetti COM scritti in VB di cui vado fiero.
Tuttavia un termine di paragone ce l'ho: ho usato ampiamente C++ e Perl, e non ho mai avuto problemi. Invece con l'accoppiata VB-VBScript, spesso ho problemi che appaiono e scompaiono, per esempio "Automation Error", "Type mismatch", "Permission denied", un COM che funziona da VB ma non da VBScript, un altro che su alcune macchine si registra e su altre no.
Insomma: fai un prodotto, lo istalli su 100 macchine; su 10 non ti funziona e non sai perche'.

Obbiettivi

Ho cercato nel mondo del software libero delle utility che mi potessero rendere un po' piu' sopportabile lo sviluppo in VB, e ho trovato delle cose veramente fantastiche. Non costano nulla e funzionano bene. Le metto tutte qui, cosi' le potete provare.

I consigli che seguono sono spesso riferiti a un gruppo di lavoro, cioe' a piu' programmatori che lavorano ad uno stesso progetto e sugli stessi sorgenti.

CVS
http://www.cvshome.com

Sapete cosa e' una repository? E' un sistema che fa un magazzino di sorgenti di una o piu' persone, le mantiene in ordine, vi archivia tutte le modifiche e sta attento che il team non faccia casino.
Detto in parole povere, un gruppo di persone puo' lavorare sugli stessi sorgenti, anche via Internet e anche modificando gli stessi file, e vi assicuro che non si fa casino.
La repository si puo' usare anche quando si programma da soli, io la uso anche per i siti web.
Secondo me oggigiorno programmare senza repository e' come andare in giro con i calzoni ma senza mutande.

Io ho usato due repository: CVS (Concurrent Version System), che e' libero, e Visual Source Safe della Microsoft. Sono entrambe ottime, ma CVS e' migliore.

La versione che vi consiglio e' WinCVS. Leggetevi BENE il manuale. Come CVSROOT usate una cartella locale o, se siete in un gruppo di sviluppo, una cartella condivisa (magari mappata come G:). Se avete un server Linux potere istallare il CVS come server da inetd o da ssh. E' meglio, perche' poi potete metterci sopra cvsweb.cgi che e' utilissimo. Esiste anche una versione server per NT, ma nel sito ne sconsigliano l'uso.

Poi fate TANTI esperimenti su un progetto stupido di prova. Imparate a usarlo bene. Vi divertirete un sacco.
La cosa ganza e' che potete lavorare in rete o anche staccati dalla rete. Potete mettere tutti i sorgenti su un portatile, andarvene in giro a lavorare per tre o quattro giorni, e poi tornare e riunificare il lavoro fatto da voi con quello fatto dal resto del team rimasto in sede.

Fate cosi': importate nella repository, i file *.vbp e *.frx come file binari. Lo so, i .vbp sono file di testo, ma datemi retta. Invece i *.bas, i *.cls e i *.frm importateli come file di testo. I *.vbw non importateli. Importate anche bitmap, icone, xml, readme e tutto quello che serve allo sviluppo del programma

Potete modificare tutto quello che volete nel codice sorgente. Invece l'aspetto grafico delle form mettetevi daccordo e fate in modo che ci lavori solo una persona per volta.

Se due persone modificano ESATTAMENTE la stessa riga di codice si ha un conflitto (vedi manuale del CVS). Questo conflitto si risolve normalmente mettendo a posto il codice editandolo dove ci sono i simboli “>>>>>>” e “<<<<<<<”. Se invece il conflitto riguarda la parte che non si vede di un *.frm, allora il VB non riesce a caricare la form e da' un errore. Niente panico, aprite il file in conflitto col notepad e vedrete che e' tutto molto facile.

Tutte le mattine fate un update di tutto, mentre la sera, se possibile fate un commit di tutto. Lavorate a piccoli passi di programmazione e appena un passettino e' finito e testato, fate il commit.

Lavorate nell' ottica che la repository e' la vera culla del software. La versione BUONA del vostro prodotto deve essere quella nella repository, non quella che avete sul vostro computer.

Una cosa importante: fate gli eseguibili da dare ai tester e da passare in produzione DA UNA SOLA MACCHINA. Non importa quale macchina, basta che sia unica. Programmate da quale macchina volete, ma poi fate il commit, andate alla macchina prescelta e fate update. Infine fate l'eseguibile.

cEdit
http://cedit.sourceforge.net

Un'altra brutta storia che ho vissuto e' quella di aver scritto una serie di oggetti COM, che funzionavano benissimo richiamati da VB, mentre da VBScript davano un simpatico “Type Mismatch”. Tutti i casting e l'uso estremo di variant o di object sono stati vani! A peggiorare la situazione c'era che per scrivere il codice VBScript usavamo il notepad, che non ha la sintassi colorata. Io usavo Emacs, col supporto VB, ma i miei colleghi non volevano usarlo.

Un giorno ho trovato la soluzione: cEdit, un editor libero che funziona benissimo, ti indenta per bene e ti colora tutte le parole.

Aveva due piccoli problemi, ma essendo software libero li ho corretti e ho mandato le correzioni al team di cEdit. Ganzo.

VBDox
http://vbdox.sourceforge.net

Fate le Sub o le classi, e poi non vi ricordate piu' come funzionano, vero? O peggio, non avete mai il tempo di scrivere un manualino dell'oggetto che avete realizzato e tutti vi vengono a chiedere le cose.

Ok, VBDox vi realizza una documentazione tecnica valida e usabile a partire dai sorgenti. Funziona bene, ma funziona anche meglio se fate un piccolo sforzo. Prima di ogni variabile, funzione o sub, Public, solo Public, mettete un commento come segue:

''
' Funzione per calcolare le tasse
'
' @param imp Importo del reddito
' @param iva Percentuale IVA
' @return Importo da pagare all'erario
' @remarks La funzione esegue il calcolo, e tiene conto dell'IRPEF.
Public Function CalcolaTasse(imp as Double, iva as Integer) as Double

Questo commento verra' inserito nella documentazione prodotta. Il manuale e' solo una pagina, ed e' solo su web. Ma non c'e' bisogno di altro. E' il programma piu' semplice sulla faccia della terra. Clikki e opla'! Una bella documentazione gratis.

Inno Setup 2
http://www.jrsoftware.org/isinfo.htm

Ah, Inno Setup! Che grande utility!
Inno Setup, crea i file di istallazione. Lo fa anche Visual Studio, daccordo, ma Inno Setup vi offre alcune cose in piu'.

• Un aspetto grafico professionale e personalizzabile.
• Il controllo completo di quello che succede prima, durante e dopo l'istallazione.
• L'automatizzazione di quello che fate di solito.

CFtpCom.cls

Una delle piu' grosse sole che ha tirato la Microsoft e' MSINET.OCX.
Non funziona quasi mai. Ho cercato nei newsgroup e ho visto che il problema e' universale. Non lo usa nessuno. C'e' anche una patch su MSDN, ma risolve solo il problema della licenza. In ogni caso ho smesso da molto tempo di pretendere che i prodotti Microsoft funzionino.
Allora ho scritto questa classe che aggangia la WININET.DLL per fare gli ftp. Non e' certo un capolavoro, ma funziona sempre e' puo' essere utile come base per scrivere quello che vi serve.