Newsgroup: it.comp.lang.visual-basic
Titolo: Microsoft Interop Forms Toolkit 2.0

Ciao a tutti,
qualcuno di voi ha utilizzato Microsoft Interop Forms Toolkit 2.0, per
gradualmente fare il porting di un'applicazione da VB6 a .NET ?
Io ho un'applicazione in VB6 che funziona ormai dal 2002, che
aggiorno/sviluppo/modifico giorno dopo giorno in base alle richieste
quotidiane del cliente (sviluppo non agile ma "agilissimo") ma lavoro
contemporaneamente anche in VB2008 su altri progetti (sia per lo stesso
cliente che per altri), ambiente che ora preferisco (sarà più pesante,
richiede più risorse ma ormai il cliente ha pc nuovi ed io ritengo l'IDE di
VS2008 molto superiore rispetto al datato VS6).
Teoricamente potrei implementare le nuove funzioni in .Net, includerle nel
progetto VB6 e pian piano convertire nei tempi morti il resto, ma mi
piacerebbe avere un feedback da chi eventualmente avesse percorso questa
strada prima di me.
Ciao
PaF

 PaF
mia esperienza del genere:
Programma Vb6 oramai funzionante da qualche anno presso il 
cliente...periodicamente mi chiede qualcosa "in più" in sintonia con lo 
sviluppo della sua attività!
Il programma non è un  gestionale contabile (altrimenti il ciente non decide 
nulla: la contabilità è quella!...se varia è perchè escono nuove 
disposizioni del ministero! ...non per volontà del cliente).
Io ho scartato l'idea del porting...troppe cose nuove in dotNet!
Per dirne:
...io, tu, noi tutti...abbiamo la nostra collezione di funzioni...che 
mettiamo in un modulo (o più di uno) .bas (i più fighetti in una dll!...ma 
come si dice "se non è zuppa...è pan bagnato!")
Schiaffarla pari pari in un progetto dotnet ha pochissimo senso!
-) Perchè dotNet sfrutta un approccio ad oggetti...e quindi il programma ha 
senso "ripensarlo" in tale ottica
-) Perchè quello che tu hai pensato in Vb6...si fà o in modo diverso...o in 
modo migliore ...in 
vb.net
 (ad esempio inserire e gestire trayicon e 
traybar)
-) Perchè considerando tutto ...alla fine NON risparmi tempo...ed è solo una 
pigrizia mentale affidarsi ad una "scatola nera" senza sapere cosa fa nel 
dettaglio...ma per sapere cosa fà nel dettaglio dovresti essere esperto di 
dotnet...e se lo sei fai prima a riscriverlo da te!
Io quindi cosa ho fatto?
Per i vecchi programmi vb6 continuo a fornire assistenza e sviluppo...
i nuovi li realizzo in dotnet...
SE mi conviene economicamente...perchè ne vendo di più...perchè posso 
aumentare il canone di assistenza...erchè il cliente mi commissiona anche 
altro...etc etc
Se mi conviene....realizzo una NUOVA versione ex novo in dotNet 
(generalmente in 
vb.net
)...
non mi ci metto neanche a vedere cosa di vecchio posso importare!
Spesso anche l'analisi è in gran parte da buttare...almeno la parte che 
pianifica i componenti lo è! ...maledetto OOP (eh eh eh!)
-----------------------------
Mio Blog
http://www.martek.it/dblog/default.asp
Mia città
http://wodka40hall.myminicity.com/
***
Best Shit of 2008: DOOMSDAY!
http://www.martek.it/dblog/articolo.asp?articolo=120
 

 pianifica i componenti lo è! ...maledetto OOP (eh eh eh!)
Nel mio caso no, il progetto è architettato già con classi, oggetti etc
(vengo da anni di C++, ok in VB6 non ho l'ereditarietà ma il resto del
codice slegato dalla UI sarebbe già quasi pronto) anzi la mia libreria .Net
riprende le idee già codificate in VB6. Ti faccio un esempio, l'accesso ai
dati:
In VB6 ho usato il caro e vecchio RDO (neanche ADO) incapsulato in un
oggetto che espone più o meno le sue stesse proprietà e metodi (es.
MovePrev, MoveNext, etc). In .NET ho inglobato dataset, datatable,
datareader etc in un oggetto che espone le stesse iniziali proprietà e
metodi dell'RDO (MovePrev, MoveNext, MoveFirst, etc), pur permettendomi poi
di accedere anche ai datatable e datarow direttamente (per le cose più .Net
based)
Il risultato è che molto del codice VB6 slegato dall'interfaccia utente lo
copio e incollo in VB.Net senza modifiche.
Il grosso problema per me è proprio la conversione dei form VB6, sviluppati
con array di controlli :-/
In questo caso si tratta di ricostruirli da zero, cambiando anche l'UI (da
MDI classico e dimensione fissa a schermo intero, sfruttando il fatto che i
monitor da 800x600 sono passati ad almeno 1024x768)
Ciao
PaF

 [cut]
ti faccio allora io un altro esempio....
butta via 
ado.net
!
oramai 
ado.net
 è per i vecchi "vb6-isti" come me...che hanno seguito la 
trafila net 1.0 1.1 etc etc(in realtà 
ado.net
 ti serve ancora...è una 
provocazione!)
Io sono impazzito...letteralmente...per un anno intero della mia 
vita...dietro ai ricercatori dell'università di Pisa...
dipartimento di linguistica...in un progetto che doveva catalogare e 
analizzare dei manoscritti latini....
in pratica ogni 15 giorni c'era una riunione e mi cambiavano SEMPRE 
qualcosa....o nel database....o nelle funzioni...o nei metodi elaborativi
E il progetto ereditava un vecchio progetto di altri...ed era in DAO + 
Access...ed a un certo punto dell'alaborazione dovette diventare 
"trasportabile" (non multiutente...che è diverso!)...l'archivio veniova 
sparato ad un docente australiano che inseriva i dati di sua competenza....e 
poi a uno di ratisbona che inseriva i suoi...etc etc....
UNA COSA DA URLO!...era qualche anno fà!
Avessi avuto dotNet...o anche la possibilità di trasportarlo in Java( a quei 
tempi dotnet manco era in progetto!)!!!
Ma ora che c'è dotNet:
Avrei strutturato "il core" con delle interfaccie esposte...e un sistema di 
plugin per modificare "al volo" la mia applicazione!
dotNet ti permette di aggiungere o togliere "a caldo" dei plugin...senza 
ricompilare!
Avrei usato LINQ per non impazzire nella marea di SQL....e Entity Framework 
una volta digerito LINQ
Perchè per problemi dinamici che crescono con il tempo...e con il tempo 
variano....usare gli ORM va benisismo ...anche se la curva di apprendimento 
è più ripida!
E tornando alla tua risposta:
in dotNet è conveniente pensare a "strati"
Se mi parli di interfaccia....quella è la parte più pallosa!
Non ti conviene parametrizzarla....anche perchè il cliente non lo 
accontenteresti mai completamente....ti serve una form? fanculo...fagliela a 
mano e fatti pagare il disturbo.
Però si tratta solo di lavoro "vile" ...da programmatore junior ...da 
schiavetto...
La logica non viene toccata....
Usare NET dentro vb6 mi fa accapponare la pelle!
Usare ADO.net come ADO mi fa rizzare perfino il derma inferiore!!!
perchè non hai nessun vantaggio...anzi solo svantaggi!...tanto vale 
continuare a usare vb6!
Hai visto questo articolo?
tanto per dare un idea...
http://www.vbnet.it/articoli/94/Plugins_Reflection_e_interfaces/
...ed è un articolo di più di un anno fa!
Saluti!
-- 


 continuare a usare vb6!
Non mi sono spiegato bene: aver rimappato ADO.Net in modo "old style" mi
permette di fare il porting di porzioni di codice VB6 slegato dalla UI
senza grossi problemi per il presente, però questo non implica che poi io
non possa sfruttare le novità del framework per il futuro (che poi tanto
futuro non è). 
Per esempio cambiando una sola proprietà della mia classe di accesso ai
dati il software può collegarsi ad un web service (anche remoto e via proxy
server) invece che al server database, cosa che con VB6 sarebbe stata un
poco più complicata.
Con un altra proprietà posso scegliere quale provider nativo utilizzare -
SQL Server, ODBC, OleDb, Postgres o Oracle -  questo perché ho incapsulato
i vari SQLCommand, OracleCommand etc in una ulteriore classe (un lavoraccio
ma ne è valsa la pena) mentre tutto il resto del mondo rimane immutato.
LINQ per ora non l'ho guardato, il giorno ha solo 24 ore :-)
Ciao 
PaF

 PaF
ok....ognuno sceglie le strade che preferisce...l'importante è arrivare a 
destinazione!
Bye man!
:o)
